Is it possible to provide permission to rebase for a specific person only?
Currently i can see clearcase can only "any user allow rebase" option.
If possible please let me know how can I change the stream to allow permission to rebase for a specific person.
The easiest way is to cleartool lock -nusers aUser a stream, but that will limit any command (not just rebase) to that person.
cleartool lock -nusers aUser stream:astream#/vobs/apvob
The more precise option is to make a pre-op trigger on rebase (with cleartool mktrtype), which test the user and stream and allows or denied the rebase based on those two parameters.
cleartool mktrtype -ucmobject -all -preop rebase_start -execunix 'yourScript' -execwin 'ccperl yourScript.pl"' UCM_BLOCK_REBASE
See for instance this "Role-based preoperation trigger script" (a bit too complex for your case, but which can give some idea about a possible implementation of the preop trigger script).
Related
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?".
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.
I have a file test.cpp somebody added a few lines of code i don't know when but i'm assuming it was in a specific range of time that i know.I want to find the activity that was used to deliever this changes, i found a lot of versions of this element in the version tree of this element, but all the activities that i was able to see were as a result of a rebase, i need to find the source activity that was in charge of adding this few lines of code.
Is there any way to do that ?
For each deliver activity (that you can see in the version tree), you can list the contributing activities with
cleartool lsact -contrib activity:anact#/apvob # on unix #/vobs/apvob
See "Finding which developer activities were delivered in a specific delivery"
Then you need to describe each activity found, to see if your file is in it.
cleartool descr -l activity:anact#/avob
Obviously, you also can use a cleartool annotate, in order to see the versions in that file: see "How to use ClearCase Annotate".
If you see one line which interest you, check its version n# 'x' and use cleartool descr -l file#/main/.../x to find its corresponding activity.
I have applied baseline for a component via cleartool. (we are using clearcase UCM).
I mistakenly put the wrong baseline name and i am unable to apply another one as it says no changes were done.
How to rename the baseline name in UCM ? (I tried via GUI but not finding a way).
If cleartool rmname can be used, can some one put an example how to do that? i did not find one
As mentioned in "Renaming a Baseline does not change the label type name", you can rename a baseline through the CLI) but you need to rename the assiciated lbtype as well, for ClearCase 7.0 and before (7.1 and 8, you can just rename the baseline, it should take care of the lbtype. If not, see below).
cleartool rename baseline:<old baseline name>#\<component vob tag> baseline:<new baseline name>#\<component vob tag>
Check if the lbtype is renamed by doing a:
cleartool descr -l baseline:<new baseline name>#\<component vob tag>.
ClearCase does not rename the lbtype automatically when a baseline is renamed because the lbtype is used as a version selector in every view that is attached to a stream using this baseline (as illustrated in [IBM technote swg1IC41518][2]).
If a UCM baseline lbtype is also renamed, it is necessary to run 'cleartool chstream -gen stream:<stream#pvob>' for every stream using this baseline.
It is then necessary to run 'cleartool setcs -stream' within every view associated to the stream.
Since it cannot be guaranteed that every view is available to the system that is renaming a UCM lbtype, this cannot be automated.
cleartool rename lbtype:<old baseline name>#\<component vob tag> lbtype:<new baseline name>#\<component vob tag>
In short, it is possible but not trivial to rename a baseline for CC7.0 and before: it is an UCM object which is assosiated (through an hyperlink) to the lbtype used to create the label on all the elements which have changed (incremental baseline), or all the elements of the component (even those which haven't changed since the last baseline: full baseline, see "What is the difference between Full baseline and Incremental baseline in Clearcase UCM?")
You need to rename both (baseline and lbtype).
It is an acceptable practice since its content doesn't change.
However, you would need to propagate and communicate the new baseline name along your release management process.
I am trying to programatically determine if a VOB is mounted in clearcase.
Specifically, I want to run a command and parse the output.
However, I can't seem to find this information in cleartool describe.
cleartool lsvob \theVob
should be enough
If there is a star (*): it is mounted
* \thevob
If there is not: it is not yet mounted.
See command lsvob.
:_
By default, lsvob lists all VOBs registered in the current network region, whether or not they are mounted (active).
The default output line can include up to six fields, as shown in this example:
* /vobs/src /net/host2/usr/vobstore/src_vob public (ucmvob, replicated)
The output fields report:
Whether the VOB is mounted (*)
The VOB tag
The VOB storage directory path name
Whether the VOB is public or private (see the mkvob reference page)
Whether the VOB is a UCM project VOB (ucmvob)
Whether the VOB is replicated (replicated)
I've found if you have a view already running, a simple "if exists" \view\\VOB works. Sometimes (if for example you're trying to use the CAL, things can be a tad slow at times)
I.E.
Perl
if (-d "\\view\onaclov\TESTVOB")
{
#do something now
}
Batch
if not exists \\view\onaclov\TESTVOB <insert mount command here>
The above will check for a particular folder, if it doesn't exist, you can do a mount vob command.
VB.NET
If System.Io.Directory.Exists("\\view\onaclov\TESTVOB") then
'Blah
end if
Just some additional insight. (you don't always have to use the Clearcase/Quest tools to do what you need)