I am experiencing a problem with Clearcase. What happened was the following:
I had a file ValidationScripts.js, and wanted to create another file in the same directory, MiscScripts.js. However, instead of creating a new file, I accidentally renamed ValidationScripts.js to MiscScripts.js. I tried to recreate the ValidationScripts.js file using merge, and now I am stuck with the same file, but with two different names: ValidationScripts.js and MiscScripts.js. So, whenever I try to change to contents of ValidationScripts.js, they are also reflected on MiscScripts.js.
Is there any way to fix this?
TIA.
It isn't completely clear what you did, but what you should have done is this, assuming that the file MiscScripts.js already existed as a plain (view private) text file, and that 'ct' is an alias for cleartool:
cd /vobs/yourvob/directory
ct co -c 'Add MiscScripts.js' .
ct mkelem -c 'Miscellaneous JavaScript Script Fragments' MiscScripts.js
ct ci -nc .
ct ci -nc MiscScripts.js
Now we have to try and guess what you actually did.
I will assume you checked out the directory. You then said:
instead of creating a new file, I accidentally renamed ValidationScripts.js to MiscScripts.js
There are two possibilities:
mv ValidationScripts.js MiscScripts.js
ct mv ValidationScripts.js MiscScripts.js
To fix case 1, you should simply have run:
mv MiscScripts.js ValidationScripts.js
To fix case 2, you should either cancel the directory checkout or undo the move:
Either
ct unco -rm .
Or
ct mv MiscScripts.js ValidationScripts.js
You then go on to say:
I tried to recreate the ValidationScripts.js file using merge, and now I am stuck with the same file, but with two different names: ValidationScripts.js and MiscScripts.js.
And this has me puzzled...I can't see how merge would help. The latter comment sounds as if you did something like:
ct ln MiscScripts.js ValidationScripts.js
Without knowing exactly what you've done, it is a little difficult to know what to recommend. Key issues are:
Did you use ct mkelem to create a new file?
If you did, then we have to worry about not creating a lost entry in the VOB's lost+found directory.
If you did not, then life is simpler.
Did you checkin the directory yet?
If not, do not do so.
If you did, then we will need to work out how to get you back to the previous revision (but we no longer have to worry about lost+found files.
Did you checkin MiscScripts.js yet?
How much this matters depends in part on the answers to the prior questions.
To add to Jonathan's answer, you need to check the history (cleartool lsvtree -graph) of the parent directory of ValidationScripts.js: you will see what has been added/removed in said directory.
A simple 'cleartool ls' in that directory can also show you if there is a symlink between ValidationScripts.js and MiscScripts.js.
That would be like you tried to restored a deleted file, as described in "Restore an element that has been rmnamed", but made the wrong 'cleartool ln'.
Related
Let's say there is a file called myfile.java. I checked it out and I was working on it. Before checking it in, I have lost my hard drive and I had to get a new hard drive.
Next time that I want to check out the file, it says that I can not check out. It was already checked out in the old view which has gone. I have to mention that I am using the option "re-use development stream option".
Is there anything I can do to be able to checkout the file once again?
You can completely unregister your old view in the vob of that file: that will remove the "checkout" status associated to that file.
cleartool mount \myVob
cd m:\mynewView\myVob
cleartool rmview -force -uuid old_view_uuid
To find the uuid of your old view, try a:
cleartool descr -l vob:\myVob
And look for a view storage path including your old view name in it.
I try to add a file in a branch to source control by doing this:
ct mkelem -ci -nc
and I get this error:
File already exists in "other_branch" branch.
Resolution: Since this file already exisit in ClearCase you will have to, selectively, merge this file from other_branch branch to your current branch/view.
Well, other_branch is completely obsolete and I would like to use the current branch file im trying to merge 100% as is. Is there a way to communicate this to clearcase on the commandline? Like ct mkelem -force (or -replaceAnyOtherFileWithThisName) -ci -nc?
There is not many solutions, beside removing completely that element (which can be dangerous in general, except in your case, this is about an obsolete branch).
cleartool rmelem
But a "safer" route would be to try an merge that obsolete branch, ignoring all changes except the addition of that file.
That way, you don't have to 'mkelem' the same file again, you can reuse the one existing (and changing its content completely).
I'm currently compiling different PHP versions and want to delete some rubbish folders.
I got a folder called "php-5.4.7-src" which i want to delete but when I do
$ rm -Rf php-5.4.7-src
there always pops up
rm: cannot remove directory php-5.4.7-src/ext/standard/tests/general_functions: File exists
rm: cannot remove directory php-5.4.7-src/ext/standard/tests: File exists
rm: cannot remove directory php-5.4.7-src/ext/standard: File exists
rm: cannot remove directory php-5.4.7-src/ext: File exists
rm: cannot remove directory php-5.4.7-src: File exists
So I did
$ find .
and
$ find . -type f
and there just pop up the folders above, no files exist.
I am also owner of all folders and I tried to delete them as root too.
How can I delete files which do not exist?
I realize that this does not answer your question but just a small matter of style that may save you headaches in the future. If you ever have to move your scripts to another flavour of UNIX there's a chance they will break. The traditional flag for doing a recursive delete is -r, not -R. Saves you having to push the shift key too :)
Now on to what may answer your question. I know you said you checked for running processes but that is the only way that an inode can be kept open, and only an open inode will keep a hierarchy from being removed. There are other processes such as updated that frequently run on systems that may have been crawling through your directories at the time. One thing you may try is to execute sync to ensure that all pending writes have been flushed.
Something is holding the directory open. You may also want to try lsof +D php-5.4.7-src to see exactly what.
I have a question about clearcase, someone helped me on some issue in clearcase, he used a command as follow: echo " " > xxx.log and
cleartool co -nc filename
what does this mean?
When you have a file which is "checkedout but removed", as described in ct ls:
The element was checked out in this view, but the view-private file was subsequently removed.
You may have deleted the file.
A solution to restore that file is to checkout it again, but if you do that directly, ClearCase would complain about being unable to access said file (because it isn't physically there anymore).
Hence the:
echo " " > afile
You need to have some content in that file in order to make a cleartool command on it.
So even if its content is a bogus one, it at least allows you to proceed.
Then, you can checkout it again (-nc means without comment, but it also means "takes the previous comments used on the current checked out version)
cleartool checkout -nc afile
Another way to restore it is to uncheckout the file:
cleartool unco afile
That will also restore its content.
The first command writes a space to xxx.log; echo is a shell command and has nothing to do with clearcase. The second command checks out filename without comments. These two commands seem to be pretty unrelated, unless there something else you haven't told us.
Just a tip:
'echo' might to used to clear xxx.log file.
co - stands for check out filename,
nc - stands for no comments
Might be helpful: http://www.yolinux.com/TUTORIALS/ClearcaseCommands.html
I want to check out a directory , let's say /vobs/myvob/src/ to add a new file in this directory. But by mistake rather than checked out /vobs/myvob/src I checked out /vobs/myvob/scr/ and even worse checked in it. Then directory scr has a new version : scr#mybranch/1 (let's say I'm working on branch mybranch)
After realized that I've made a mistake, I remove the newly created version by:
ct rmver scr#myranch/1
then use ct ls parent_dir_of_scr to do the double check and I found although scr#mybranch/1 disappeared, scr#mybranch/0 is still there .
Not 100% sure but I'm afraid I should not try to remove that version in the same way , cus it might let clearcase remove a version in main as well.
So my question is how should I do a totally "clean up" in this situation .
Need your help . thanks in advance .
First, as mentioned in How do I roll back a file checked in to Clearcase?, the one command to never ever do is rmver.
Even if in your case it could be appropriate, this is simply too dangerous, for it removes the version and all its associated metadata (hyperlinks, labels and so on).
Then, you mention:
rather than checked out /vobs/myvob/src I checked out /vobs/myvob/scr/...
... well /vobs/myvob/src is quite similar to /vobs/myvob/src here. I do not see any differences between the "two" directories.
If you want to add a file to a directory through the CLI cleartool, you will need to:
checkout /vobs/myvob/src (parent directory)
mkelem the file to add
checkin the parent directory
Finally, the "version 0" you see is only a "declarative" version to act as a starting point for branches.
That is why the other answers suggest you to rmbranch (remove the branch) for that element. It only serves the purpose of cleaning the lsvtree (version tree).
"cleartool rmbranch -force $element"
as mentioned in the ten best scripts.
Even if you remove version 1 of a file on your branch, your branch will remain (with version 0). If you really want to do a clean-up you can remove the branch (ct rmbranch your_branch) for the file -- it won't remove the version from mainline.
If you want to completely remove a version of an object (file or directory) from Clearcase control, I suggest you to use the following command:
cleartool rmver –xbranch –xlabel –xattr –xhlink test.txt##\main\3
Command options are described on this snip2code post.