Can someone to point me to lock a file only on a specific branch in clearcase? Note that i want the same file to be modified in all other branches that other teams working on...
Locking the branches as appropriate might help.But it does not sound like a good idea. Please share your thoughts.
You can lock a specific branch instance.
cleartool lock co.exe##/main/foo
Locks that branch instance and will block anyone from modifying that branch while allowing all other instances -- like ci.exe##/main/foo/2 to be checked out and used.
Depending on your view setup, you may have to use lsvtree or cleartool find to find all the branch instances.
This wouldn't be a simple clearool lock, as it would lock the element for all branches.
A simple approach would be a cleartool checkout -reserved, but that owuld prevent checking on other branches as well.
That leaves you with a preop checkout trigger, using the trigger environment variables CLEARCASE_BRTYPE :
cleartool mktrtype -c "Prevent checkout on a branch" -element -all -preop checkout -execwin "ccperl \\shared\path\to\triggers\lock_on_branch.bat" LOCK_ON_BRANCH
The script will use:
CLEARCASE_XPN
(All operations; element triggers only) Same as CLEARCASE_ID_STR, but prepended with CLEARCASE_PN and CLEARCASE_XN_SFX values, to form a complete VOB-extended path name of the object involved in the operation.
CLEARCASE_BRTYPE
(All operations that can be restricted by branch type) Branch type involved in the operation that caused the trigger to fire. In a rename operation, the old name of the renamed branch type object.
Related
Background
I have a directory element in clearcase that has a version tree as shown below:
VIEW_NAME --> Version 0 --> Version 1
I am trying to remove Version 1 of the directory so that the version tree looks like this:
VIEW_NAME --> Version 0
Problem
I have tried to use rmver to accomplish what I want. However, I am not allowed to invoke rmelem at all, which rmver uses as part of the command. I know this because I have faced the following error:
ERROR: User myusername cannot use rmelem. Use rmname instead.
cleartool: Warning: Trigger "TRG_NO_RMELEM" has refused to let rmver proceed
cleartool: Error: Unable to remove versions of ".".
Attempted Solution
I have ran a search through the man pages of rmver and rmbranch for a possible option to use a rmname version of either command, however there is nothing in either man page. This lack of an rmname like functionality in either command has lead me to ask the question:
Question
Is there a version of the rmver command that uses rmname as part of its core execution instead of rmelem?
No: rmver would never use rmname.
As mentioned here
Removing an element name from its parent directory (cleartool rmname) does not affect the element itself, but two other types of a removal operation do irrevocably affect an element. Be very conservative when performing these operations (rmver, rmelem)
Since:
rmver deletes both the version object in the VOB database along with associated metadata and the corresponding data container in a source storage pool.
There is always a rmelem involved (not for the version itself) but other metadata elements associated to the version that need to be removed.
If you really needs to remove that version, you might consider disabling temporarily the trigger, following "How to disable a trigger in a VOB or determine if an existing trigger is already disabled".
Something like:
cleartool lock -obsolete trtype:<trigger type name>
I administer a SCM environment with ClearCase, that has a lot of VOBS.
Many of these VOBS are not used since a long time ago. I would like to know whether it is possible to determine the last modification time on these vobs.
Another doubt is: if I only unregister these VOBS, the CPU and Memory consumption will decrease in the VOB Server?
In theory, to put these vobs online again, I will only have to run a register command, right?
Is there any other approach that you guys could recommend to me to manage this scenario (VOBs not being used for a long time)?
Many of these VOBS are not used since a long time ago. I would like to know whether it is possible to determine the last modification time on these vobs.
You can try and use cleartool lshis -all on a vob tag.
I had a script which filtered the last events with:
cleartool lshis -fmt "%Xn\t%Sd\t%e\t%h\t%u \n" -since 01-Oct-2010 -all <vobname>| grep -v lock | head -1 | grep -o '20[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
Another doubt is: if I only unregister these VOBS, the CPU and Memory consumption will decrease in the VOB Server?
Yes, because there wouldn't be anymore vob_server process associated with that vob.
In theory, to put these vobs online again, I will only have to run a register command, right?
Yes, although I prefer unregister/rmtag (as in "Removing ClearCase vobs") before registering and mktagging.
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 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.
Could anyone explain what is a Evil Twin and Subtractive merge in Clearcase?
Evil Twin
An Evil Twin is an element that you have removed (using rmname) and want to re-add, but it's 'evil twin' exists in previous versions of the directory.
You have to remember that each element had a unique ID, so you are attempting to add an element with the same name - but with a different UID. This is not allowed.
The best way to deal with an Evil Twin is to relink the newest version you can find of the existing element to the new version of the directory. You can then make a new version of the element and replace the data within it.
Subtractive Merge
A subtractive merge is the opposite of a selective merge.
A selective merge (the default, bog standard merge) adds the changes from another element version into your checked-out version.
A subtractive merge attempts to remove the changes made in a different version from the version you have checked out - because it's a bad version, you've made mistakes in it etc.
IBM has a nice article on substractive merge.
A subtractive merge can be performed to exclude or bypass bad versions on a branch without actually removing the bad versions.
Cleartool merge using the -delete option will allow a user to merge from the last known good version to a new version on the same branch which excludes the work done in the versions identified as bad versions.
This merge must be performed from the command line, it does not create a merge arrow, the arrow can be created manually.
This will work for file as well as directory
But you need to realize that merge is about a file or a directory, not about a directory "and everything in it".
To merge recursively, take a look at findmerge.
You can want to merge only directories (since they are always merged first, to determine the actual list of files to merge!), as in this IBM article
% cleartool setview major_vu% cleartool findmerge /vobs/vob1 /vobs/libvob2 –type d \
–fversion /main/LATEST –merge
you may also do the merge from the LATEST version of a branch or from a tag:
findmerge . –fversion /main/rel2_bugfix/LATEST –print
findmerge . –ftag rel2_bugfix_view –whynot –print
Note: the -print is always a good idea before replacing it by '-merge -gmerge', in order to get a preview of what will be merged. But if directories are involved, it will only print that 'directory X' needs to be merged, not the exact list of files.
For evil twins, check out the IBM article. Case sensitive issues can be a real pain to deal with and create some evil twins without you realizing it...