Can someone guide me to deal with this in the right and best way? I have two active dev branches where-in the same code base is being modified and one integration branch in a base clearcase environment. But i wanted to prevent code promotion from branch 2 to integration branch and allow merge only from branch 1 to integration branch. Please advise.
2 Answers
If there are different users delivering from dev streams to integration streams, you could (using cleartool lock -nusers ... stream:aStream@\vobs\apvob
):
- lock
devstream1
for all exceptdev1
(that way you are suredev1
can only work ondevstream1
), - lock
devstream2
for all exceptdev2
(that way you are suredev2
can only work ondevstream2
), - lock
intstream
for all except you anddev1
(that way onlydev1
can deliver tointstream
)
What if I or dev1 mistakenly promoted code from devstream2 to intstream
Then you would need a preop deliver_start
trigger (with mktrtype
).
That trigger would control the OIDs of the streams in the trigger since these are immutable: cleartool describe -fmt %On <stream-name>
If one of them is the one for devstream2
, the trigger would exit in error, denying the deliver.

- 1,262,500
- 529
- 4,410
- 5,250
-
Thanks for your response. I have a question with your response and that's what i'm exactly trying address. What if I or dev1 mistakenly promoted code from devstream2 to intstream. – user2705120 Oct 14 '15 at 19:47
-
@user2705120 I have edited the answer to address your comment. – VonC Oct 14 '15 at 20:00
Since it sounds like your using Base ClearCase, you can use a preop 'checkin' trigger. The script the trigger executes would look to see if the checked out version about to be checked in has any incoming Merge hyperlink(s). If it does, the script can verify that the "from" end of the hyperlink is coming from branch1 and exit with a 0 status if so. If it's coming from any other branch, the script will print a descriptive error message and exit with a non-zero status (thus preventing the checkin).
When creating the trigger type, you can limit the scope of the trigger to the integration branch (which I'll call 'my_int_branch' in the example below) which helps with performance. The command line might look something like this:
% cleartool mktrtype -element -all -preop checkin -brtype my_int_branch -exec path_to_allow_branch1_merge_script allow_branch1_merge
In the script, you can get the Merge hyperlink(s) attached to the checked out version with something like:
cleartool describe -fmt '%[hlink:Merge]p\n' $CLEARCASE_PN
If there are any incoming Merge hyperlinks, you'll get one line per hyperlink looking something like this:
"Merge@2877@/vobs/myvob" <- "/vobs/myvob/mydir/file.c@@/main/branch1/3"
The script then just has to verify that the outer branch of the "from" version is "branch1".

- 146
- 5