1

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.

user2705120
  • 249
  • 5
  • 12

2 Answers2

0

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 except dev1 (that way you are sure dev1 can only work on devstream1),
  • lock devstream2 for all except dev2 (that way you are sure dev2 can only work on devstream2),
  • lock intstream for all except you and dev1 (that way only dev1 can deliver to intstream)

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.

VonC
  • 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
0

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

hack
  • 146
  • 5