I have a question regarding ClearCase. From the documentation of the mkelem command I read:
The mkelem command creates one or more new elements. By default, a new element can be created in a directory only if that directory element is checked out. mkelem appends an appropriate line to the directory's checkout comment.
Why is this the case? And, as it says by default, how do I change this default option? I couldn't find anything about this in the doc.
It is the case because the element to be created needs to be registered in the list of elements maintained by the parent folder.
Since that list is about to change (because you are adding a new element), the parent folder needs to be checked out in order for its list to evolve.
Then a check in will record that changes (if you undo checkout the parent folder, then the element added to source control would end up in the vob/lost+found folder, as it wouldn't be referenced by any directory version)
Note that if you have many element to add to source control (many mkelem to make, meaning potentially many parent folders to check out), you can still use clearfsimport instead, as I explain in "how to run mkelem command in command prompt" or "How to add a directory tree to a ClearCase repository?"
Related
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 am trying to delete a file in ClearCase. When I attempt to delete it I get a message that the element has checkouts. When I do a version tree on the file I see that the file is checked out by another user, in another view, on a different branch.
How do I delete this file? In addition why doesn't ClearCase let me delete this file?
You can delete it through the command line and cleartool, by forcing its delete (option which isn't available with the GUI)
cleartool rmname -force theFile
Don't forget to checkout the parent directory first, then to checkin that same parent directory, in order for everyone to see that you have dereferenced that file within said directory.
See cleartool rmname:
–f/orce:
Forces the removal of the name when there is at least one checkout of the element.
When used with –nco, suppresses the prompt for confirmation.
That will work even when you had this before:
, as explained in the technote "About cleartool rmname and checkouts".
What I know is, using rmelem to remove the folder first, and this will cause all of its child elements to be moved to lost+found.
Then, go into lost+found, and repeatedly execute rmelem * until all of the elements are removed.
Is there a better way?
The technote about lost+found is quite clear:
if you rmelem a directory, all its content will indeed be moved to lost+found, where it will has to lost+found. The technote adds:
Note: If a directory element is deleted from lost+found with rmelem, its contents will be moved to lost+found in the same manner described in the first section above.
That is why I always try to rmelem files first, then directories, in order to avoid a trip (or several trips) in lost+found.
Except I very rarely rmelem anything, as the same technote warns:
Use rmelem carefully when deleting elements or symbolic links from the lost+found directory.
While the content of lost+found typically consists of unwanted elements and symbolic links, in some circumstances it can contain elements that are cataloged elsewhere in the VOB (that is, not orphaned) that are associated by symbolic or hard links.
For this reason, do not run rmelem recursively in lost+found without first verifying it contents.
If you need to save an element that is currently in lost+found, catalog it in a versioned directory using mv as explained in the previous section
Actually, with ClearCase UCM, it is almost impossible to rmelem any element with some history, because of all the hyperlink you would compromised (related to baselines mainly).
I have a Folder in ClearCase that contains a large list of Reports.
I have checked all the Reports out because I need to make a sweeping change.
I have changed a set of the Reports and now want to deploy this set.
I probably should have checked the Report files out one at a time and then deployed each as I finished.
But, since I did not do that, is there a way to inspect the ClearCase folder that contains the List of checked out Reports to see which ones have changed and which ones have not?
You could ask cleartool for a diff with the previous version:
cleartool lsco -r -cvi -fmt "diff -options \"-hea\" -pred \"%n\"\n" | cleartool | grep ">>>"
That would give you the list of currently checked-out modified files.
Note: remove the '-r' option if you only want the check-out files of the current directory (and not its sub-directories)
In ClearCase (or Explorer if you have integration enabled), right-click the base of the tree, and choose "Find Modified Files". This will return a list of ALL files that have been modified, and that are part of the repo (i.e. it will not return list of private files).
If you want to know all files - checked out, modified, and private - the only way I know of is to use cleartool from within the view:
cleartool ls -r
If you want more (or less) info about the files, check the docs for the -fmt option (which doesn't work with ls, but does work with describe), and you can create a command that will give you exactly what you want (it'll take some experimenting until you get the hang of it).
NOTE: "Find Modified Files" is only available within the gui from the base of the view tree; Elsewhere your only option is "Find Checked Out Files" (confusing, to say the least).
You can set up a second view with an identical config spec as the view with the checked out files. Once you have the second view set up you can compare the same directory in each view with a difference tool (like WinDiff). This will list all the files that have been changed.
It's not native to ClearCase but it should give the results you are looking for.
I also found a solution. I selected my ClearCase folder and clicked on "Find Checkouts". This showed my huge list of Report files that were checked out. I then selected them all and selected "Check In". I left the "Check in if identical to previous version" option unchecked. I then selected "OK" to check in. All the modifeid files checked in and the un-modified files remained checked out. This gave me my delta of modified files vs un-modified files.