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).
Related
I'm trying to recursively delete some versions/files from a specific branch.
find delivers the right files. Now it would be up to rmver to remove the version but this gives me an error. I'm struggling with the syntax.
cleartool> find Component\Test -element "brtype(P_Testing_device)" -exec "rmver -f \"%CLEARCASE_PN%##\main\G_Testing_device\P_Testing_device\LATEST\""
cleartool: Error: Extra arguments: "%CLEARCASE_PN%##\main\G_Testing_device\P_Testing_device\LATEST\"
What's wrong with that?
How would you recursively delete versions from a Branch?
First don't if you can avoid it. rmver, as I explain in "How do I undo a checkin in ClearCase remote client", is very dangerous.
If you have hyperlinks attached to the versions you are removing (definitively from ClearCase), like merge links (deliver or rebase links of your are using UCM), you risk ending up with many "dangling hyperlinks", which is not good.
Second, I would try first:
find Component\Test -element "brtype(P_Testing_device)" -exec 'rmver -f "%CLEARCASE_PN%##\main\G_Testing_device\P_Testing_device\LATEST"'
To rule yout any issue with weak vs. strong quoting (as in "CLEARCASE_XPN not parsed as variable in clearcase command")
If that doesn't work, I would recommend finding all the right versions and putting them into a file, then piping the content of that file to a cleartool rmver.
A much safer route is to cleartool lock -obs the branch, making it non-modifiable and invisible for the future version trees.
In my current working environment, I make use of eclipsed files extensively for testing purposes. When it comes time to formalize things, I have a script which generates a diff by comparing the file with a backup saved by my eclipse script.
I'd like to be able to work without the backup of the original file; is there any way I can retrieve the current version of the file that I can pass to diff? Even though the file is view-private, I see I can enter foo##/ and see a list of versions, but I'm not sure how to find which version is the latest. Everything I've tried using cleartool ls or describe with the file name tells me that it's not a VOB object (which is true, although cleartool ls does show it as eclipsed, so it must know, somehow, that there is an element there)
Thanks
Eclipsed file means dynamic view.
The simplest solution would to make a second dynamic view based on the same config spec.
Considering how cheap and quick those views are, this isn't an issue.
On that second dynamic view, you can do a
cleartool descr -fmt "%Xn" /path/to/element
In order to get the extended pathname of the file (see fmt_ccase for more on the %Xn syntax).
I currently have a jacked-up delivery from a child stream to a parent in ClearCase. If I try to undo the delivery it tells me I can't because the "integration activity has checkins" or "checked in versions".
If I try to resume the delivery it says it encountered an error attempting to checkout or merge an element, but doesn't specifically tell me which one.
So I'm looking for a way to either:
Manually stop the delivery (undo all checkouts in the parent stream?)
Find out what element is causing the delivery problem (is it same as the one causing the undo problem)
or Find out what element is causing the undo problem and find a way to undo the checkin (I don't know how to do this. I tried to delete a version in the version tree, but I don't have permission).
For 3/ "Find out what element is causing the undo problem", this is easy (but not recommended): you need to remove all the checked-in versions done during the complete phase of the deliver.
And that is by far the most dangerous solution, especially if any type of activity (other checkins, baselines, ...) has been done on the destination Stream (the stream to which you are delivering file, ie the Stream with the view you are using to deliver to)
You can see those checked-in file by describing the deliver activity (which always starts with deliverbl.xxx)
cleartool descr -l activity:deliverbl.xxx#\myPVob
1/ and 2/ are linked.
A good solution to easily detect the issue is to resume the deliver graphically: open the ClearCase project Explorer (clearprojexp), right-click on the source Stream and select deliver (Baseline or Activities, to default or alternate target: it doesn't matter).
ClearCase will detect that a deliver is in progress and will propose to resume.
All you need to do is check all the files with a red circle and white cross (not the files with a yellow warning sign, those are not blocking the deliver).
Once you have one of those files, right-click on it, and select "display element merge": you will have a more precise error message that you can copy-paste.
If those files are in lost+found directory, all you need to do is to edit the config spec of the view used for the deliver, and add a non-selection rule to avoid selecting anything from lost+found:
cd /path/to/your/view
cleartool edcs
#add at the start of the config spec
element /myVob/lost+found/... -none
Then resume again your deliver, and you will see that those 'lost+found' files become ignored (with a warning non-blocking status attached to them).
If those files aren't in lost+found and are failing the deliver because of "Not a vob object <directory name>", the first check to do is to go to the parent directory of said files in a shell session and type cleartool ls: you will see their status.
In this case, the OP Ian reports them as hijacked, so it was simply about undoing their hijacked status.
He reports also having to delete (rmname) some binary files, although my answer to the question "Clearcase UCM is trying to merge pdf files" is pointing to an alternative solution (copy merge).
My recommendation: in that particular state (deliver with checkins already there), try hard to complete the deliver, not to cancel it.
In Clearcase, I want to copy (fork, split) a file while preserving its history. Something like svn cp old.txt new.txt. How do I do it?
It isn't possible do fork a file in ClearCase.
If you refactor your code and split a file in two, one of them will appear as a new file and you will loose the information about who coded it. The annotate command will say the author of the lines are who splited it.
UCM or not, you cannot duplicate easily the full history of a file.
The best way to isolate an history is still to create a branch in order to make new versions to that file without impacting the same file in the original branch.
Thinking 'svn cp' should be available in ClearCase might come from the fact that, in SVN, branches are directories, and a tool like cc2svn will actually replicate ClearCase branches using 'svn cp'.
But since, with ClearCase, branches are first-class citizen, it is best to reason in term of branch than in term of copy/fork.
From the main page of cc2svn:
There is a difference in creating the branches in ClearCase and SVN:
SVN copies all files from parent branch to the target like: svn cp branches/main branches/dev_branch
ClearCase creates the actual branch for file upon checkout operation only.
Pretty simply done
Check out parent folder
Move element you wish to duplicate to appropriate location (not within the checked out parent folder)
Undo Checkout of parent folder
All the files get returned to the original folder with history and also the duplicate ones remain in the new location with the history too. Now each file can be checked out and changed individually
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.