I am working on a view created from the main code repository on a Solaris server. I have modified a part of the code on my view and now I wish to update the code in my view to have the latest code from the repository. However when I do
cleartool update .
from the current directory to update all the files in the current directory, some(not all) of the files do not get updated and the message I get is
Keeping hijacked object <filePath> - base no longer known.
I am very sure that I have not modified the directory structure in my view nor has it been modified on the server repository. One hack that I discovered is to move the files that could not be updated to a different filename(essentially meaning that files with original filename no longer exist on my view) and then run the update command. But I do not want to work this out one by one for all the files. This also means I will have to perform the merge myself.
Has someone encountered this problem before? Any advice will be highly appreciated.
Thanks in advance.
You should try a "cleartool update -overwrite" (see cleartool update), as it should force the update of all files, hijacked or not.
But this message, according to the IBM technote swg1PK94061, is the result of:
When you rename a directory in a snapshot view, updating the view will cause files in the to become hijacked.
Problem conclusion
Closing this APAR as No Plans To Fix (NPTF) because:
(a) to the simple workaround of deleting the local copy of renamed directories which will mitigate the snapshot view update problem and
(b) because of this issue's low relative priority with higher impact defects
So simply delete (or move) the directory you have rename, relaunch you update, and said directory (and its updated content) will be restored.
Thanks for your comment VonC. I did check out the link you mentioned, but I did not find it much useful as I had not renamed any directory. After spending the whole day yesterday, I figured out that I had modified some of the files previously without checking them out first. This made me to modify them forecfully as they were in read-only mode as they were not checked-out. This resulted in those files to become hijacked, and hence when I tried to update my view to look at all the modifications in the repository, it was unable to merge my modified file with that on the server as those files were modified without being checked out so the cleartool update was made to believe that the file is not modified(since it was not checked out) but actually it was. That was the fuss!! :)
Related
I have a question. Accidentally I removed my .vimrc file but macvim is still open and all the settings are stored. Is there a way to load it?
I've never used it myself, but you could give the mkexrc command a try.
:mk :mkexrc
:mk[exrc] [file] Write current key mappings and changed options to
[file] (default ".exrc" in the current directory),
unless it already exists.
If you use plugins, you might want to look at your plugin manager's documentation to see if you can get a list of loaded plugin, which would get you halfway to recreating your plugin list.
If your question is how to restore perfect copy of .vimrc only using running vim, I do not know the answer. If your question is how to restore most of your lost .vimrc, please consider following options:
But, firstly, look at the trash :-) (quite obvious, it is not the case, is it?)
There should be also .gvimrc in your home directory. Usually people share the same settings between terminal and graphic versions of macvim, with maybe some minor exceptions, like the size of the window etc. So, if you have .gvimrc you can most probably restore your .vimrc.
The other option can be examining your command history using q: command. If you tried commands before you put them to .vimrc and the history is long enough, you can copy&paste them and thus restore .vimrc.
I'm trying fossil for the first time, and messed it up within minutes. I created a repository, then apparently ran commands in the wrong folders etc., eventually deleted the test repository, in order to restart. (Somewhere I had read that fossil was "self contained", so I thought, deleting a repository file would be ok. What is the correct way to delete a fossil repository?)
Now, with almost every command I try (incl. "all rebuild"), I get the error "not a valid repository" with the deleted repository name.
What now?
According to this post:
The "not a valid repository" error only arises
when Fossil tries to measure the size of the repository file and sees that
either the file does not exist or else that the size of the file is less
than 1024 bytes. It does this by calling stat() on the file and looking at
the stat.st_size field.
it seems likely that you have a missing or truncated Fossil file. Make sure you've actually deleted the repository file, and that your filesystem has actually released the file handles. Fossil stores some respository information in ~/.fossil, so you may need to remove that too.
rm ~/.fossil
In egregious cases, you may want reboot after deleting this file, just to be sure you're working with a clean slate.
If you're still having problems, try creating a new repository file in a different directory. For example:
cd /tmp
fossil init foo.fsl
fossil open foo.fsl
fossil close
If all that goes smoothly, you'll have to hunt down whatever remnants of the repository are lurking. As long as the file handles are closed, there's no reason you shouldn't be able to delete foo.fsl (or whatever) and call it good.
I have just experienced the exact same problem on Windows. I too seem to have found a solution. Here is what I did. I cannot guarantee that it is a universal solution or even a good one. In:
C:\Users\mywindowsusername\AppData\Local
There was a file named _fossil and a directory/folder named VirtualStore. I deleted both. This seems to have removed all traces of the repository. Note that the repository was still in the "open" state, as with your case.
Edit: After experimenting further, it would appear that VirtualStore is a temporary directory that will disappear after committing (a .fossil file will then appear inside the targeted directory).
My mistake was to create a repository at the root and clone: fossil proceeded to clone the entire C drive. Probably a common newbie mistake.
I've been trying to create a union file system for a college project. One of its features that differentiates it from unionfs is the fact that there are no copy-ups. This means that if a file is located in a certain branch, it will remain there even if it is written to.
But my current problem with that is the fact that .goutputstream-XXXXX are created, renamed, and deleted whenever a write operation occurs. This is actually OK if the file being written to is in the highest priority branch (i.e. the default branch where files can be created), but makes my kernel crash if I try to write to a file in a lower branch.
How do I deal with this? How can I rig it so that all .goutputstream-XXXXX files are written to only one location? These .goutputstream-XXXXX files seem to be intricately connected to the files they correspond too, and seem to work only the same directory as the file being written to.
I also noticed that .goutputstream-XXXXX files appear when a directory is read. What are they for, anyway?
There has been a bug submitted to the ubuntu launchpad in which the creation of .goutputstream-xxxxx files is discussed.
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/984785
From what i see now, these files are created when shutting down without preceding logout, but several other sources may occur, like evince or maybe gedit.
maybe lightdm has something to do with the creation of these files.
which distribution did you use?
maybe changing the distribution would help.
.goutputstream-XXXXX created by gedit and there is no simple way (menu or settings) to relocate them.
recently, i upgraded to Flex Hero 4.5 and created a new workspace. Then, i imported a project from the former workspace and started working. when i tried to upload the project from the new workspace to codereview, i got the error message: could not guess version control system. Are you in a working copy directory? How does one resolve this issue?
thanks
I have read somewhere that i need to checkout my svn but i thought that you only checkout when you want to get a folder/file from the svn.
Sounds like you've got a bit of a mess unfortunately. Hopefully you're not in the habit of doing a ton of changes without checking in. I would suggest you:
Back up your latest changes to a safe location
Check out the project from SVN into your new workspace (which is what you should have done initially) - creating a brand new project folder
Merge the changes you've made into the now-correctly-versioned copy of your project (you could do this by just copying files from the "latest"/project backup folder overwriting the SVN versioned files, but if you do--do NOT overwrite any .svn folders). You could also use a tool such as WinMerge or WinDiff to find differences between the two projects (of course ignoring .svn folders).
If you have a small number of changes it shouldn't be bad, but if there's a lot, you might want to follow SolarBear's branch suggestion, if WinMerge isn't going to cut it.
If I understand correctly your latest comment, you did a svn export on your code. The export command, as the doc mentions, creates a "clean" directory tree, i.e. without the .svn directory. So basically, these are files not controlled by SVN; also, you lose all the history of your files. The best way would have been, I think, to do a checkout in your new workspace and then work from there. It could take some time, but it's much easier to manage afterwards.
One possible way to make this work would be to checkout a clean copy your code somewhere safe and then merge your changes into this clean copy. However, if your trunk or branch changed a lot in the meantime, this could be very, very tedious. I could then suggest to branch your trunk, checkout that new branch, slowly merge your changes into that branch and when you're done and everything's working OK, merge the branch back into the trunk.
Our code is in SVN. We develop using Visual Studio and the AnkhSVN plugin.
Having used VSS before SVN I was used to the idea of locking files so other users know not to edit it while you are (in fact I thought this was the main point of source control, to prevent lost data from these conflicts).
I've been told this rarely happens and cases where you can't work because another dev is locking you out are more frequent (which sounds like a principle that might only apply to a certain subset of dev projects). But anyway, SVN is better and we're using it.
So when I do edit a file, and go to check it in, and find out the other user has edited it too, what do I actually do?
Surely there's a better way than saving a copy of my file, reverting changes, updating it from server, then merging my changes back in with winmerge? When I right-click the file and click 'merge' I'm told I should update first, so that's obviously not what I need.
.
Update: partial answer
OK, it sounds like I just hit update, then SVN merges non-conflicting changes automatically, and should let AnkhSVN know about any conflicting changes to allow some kind of resolution. Does anyone know how this works in AnkhSVN - what I'd actually do?
(if not I'll try it myself, accept the current top answer and update this question with the second half for posterity).
Actually, that's exactly what you need.
Edit: Clarification, what you need to do is just hit that update. You don't need to make a separate copy, revert, etc. Updating from the repository will merge those changes with your own.
When you do the update, where you have local changes to a file that has also been changed in the repository, SVN will merge the file in the repository with your local file, preserving both sets of changes.
In effect, it should do what you would do with Winmerge automatically.
If the changes are conflicting, typically that they occur within the same lines, there will be a merge conflict, which has to be resolved. Not knowing AnkhSvn, I don't know what it will do in this case, but it should have some means of fixing things. Usually it involves looking over 3 files (your local file, the repository file, and the result of a successful merge) where you pick each part you want to keep from the two changed versions of the file.
After you've updated your local copy, merged and fixed any conflicts, you commit as usual.
It´s not an direct answer to your question, but I would recommened to use SVN-Monitor in addition to AnkhSVN or any other Subversion client like TortoiseSVN.
With it you can watch your repository and will be notified by changes in your repository. So you can see what other devs did in the repository and probably see if your commit will conflict with other checkins or if you can update your local copy without any effect/conflict