cleacase, cleartool, print branch comment - clearcase

I need to print the comment (I'm on unix) used when creating a branch and all I found so far is:
cleartool describe -fmt '%c' brtype:<branch_name>
this is working, but only when I am in some mounted view (pwd)
There is a possibility to print this comment from anywhere, since the view can be NOT active (un-mounted)?

Mounted or unmounted means dynamic view.
But a branch isn't related to a view, it is related to its vob in which it is defined.
That means you actually can execute that command from anywhere, if you are using the fully qualified named of that branch:
cleartool describe -fmt '%c' brtype:<branch_name>#\vob
(with #\vob the vob in which you have defined the brtype -- branch type -- of the branch.
In UCM, it would be the pvob)

Related

Is there a version of rmver that uses "rmname" instead of "rmelem" as part of its invocation?

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>

ClearCase UCM: Access and change config spec from script

In our continuous integration we use ClearCase UCM. We occasionally need to access the sources from the recommended baseline (which not necessarily equals the newest baseline). Note: All baselines are full.
I figured out how to access the sources belonging to the recommend baseline manually, by entering cleartool edcs in the command line within the dynamic view and adding the line element * MyRecommendedBaseline below # Select checked out versions, saving and closing the text-file.
Unfortunately I don't know how to do this from a script. One way I could think about is read the contents of the config_spec into a stream, add the line, save it to a new text file and use "cleartool setcs newcs.txt".
But apart from being cumbersome I'm not exactly sure if this is possible. Anyone knows a simple way to do this?
You can script listing the recommended baselines of a given stream: see "How can I list the recommended base line in ClearCase"
On Windows:
cleartool descr -fmt "%[rec_bls]CXp" stream:streamName#\aPVob
On Unix:
cleartool descr -fmt "%[rec_bls]CXp" stream:streamName#/vobs/aPVob
From there, you can generate a new file with simple rules:
element * MyRecommendedBaseline1
element * MyRecommendedBaseline2
...
And you can setcs that file to a dedicate base-CC dynamic view (not an existing UCM view).
As Brian Cowan points out in the comments, this only works because those baselines, as the OP mentions, are full baselines (not incremental or not-labeled, like deliverbl are).
See also "What is the difference between Full baseline and Incremental baseline in Clearcase UCM?".

ClearCase - How lock a file only on a specific branch

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.

How can I bypass a clearcase "file already exists" error?

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).

clearcase latest version of a file on a particular branch

I know the filename of a clearcase versioned file. How can i find the latest version of this file on a particular branch ? It should not pick any child branches. Also the parent branch names may not be know always.
Thanks.
If you are using a dynamic view, you can directly access the LATEST version of a given branch by using the extended path:
cat file##/main/branch/subbranch/LATEST
If you don't know the exact branch path (parent branches) this version is stored in, you can modify your dynamic view and add first the selection rule
element /path/to/file .../subbranch/LATEST
That will select the LATEST version of subbranch within the dynamic view.
Or you can do a cleartool find, in order to see the full extended path for that file:
cleartool find . -name "yourFile" -ver "version(.../subbranch/LATEST)
You will be able to cat (or type in Windows) directly the result (which will be the full extended path)
The diea behind the cat or the cleartool find is to be able to use the syntax .../subbranch/LATEST.
That syntax with the three dots means: '.../subbranch' whatever branches followed by /subbranch.

Resources