Config spec in ClearCase

all picture all · Apr 14, 2013 · Viewed 14.8k times · Source

I have tiny question about ClearCase. Help me please! When does config spec start to work? When I click CHECK OUT or CHECK IN ? I have test.c and I have config spec

element * CHECKEDOUT
element * .../branch_1/LATEST
element * /main/LATEST -mkbranch branch_1

then I modify test.c, then I change config spec:

element * CHECKEDOUT
element * .../branch_2/LATEST
element * /main/LATEST -mkbranch branch_2

Then I Check in test.c and I have: created /main/branch_1/1. BUT WHY???

Answer

VonC picture VonC · Apr 14, 2013

The config spec will apply the rules on each update and on checkout, and on checkin (but not as you think it would).

On checkin, the new version will be created in the branch it has been checked out (here branch_1).
That new version might not be selected by the new config spec, BUT the branch in which it has been checked out is NOT changed by said new config spec.

Changing branch1 in branch2 while test.c is already checked out (in branch1) doesn't change anything. It will be checked in in branch_1.

Now that you will create a version on branch1 on checkin for test.c (even with your second config spec), you need to realize that all future checkout/checkins will take place on that same branch for test.c, because:

  • the rule element * branch_1/LATEST will keep the new versions on that branch
  • the rule element * /main/LATEST -mkbranch branch_2 is only valid for version checked out from main (and test.c is no longer on /main, it is on branch1: /main/branch1)

This config spec would make sure that all new versions (after the first checkin of test.c on branch1) are done on branch2:

element * CHECKEDOUT
element * .../branch_2/LATEST
element * ../branch_1/LATEST  -mkbranch branch_2
element * /main/LATEST -mkbranch branch_2

The order of the rules is important, because the first one that can be applied "wins" (i.e. the pothers are ignored).
See this concrete example of config spec in "Config Spec to display labeled files from 2 branches".


Note that after the first checkin of test.c, you will get a new version created on branch1, as explained before.

Yet your second config spec will select /main/1, not /main/branch1/1.

That is because of an incorrect rule in your second config spec:

element * branch_1/LATEST

This one would select the right version:

element * .../branch_1/LATEST

But if your second config spec has no rule regarding branch1, test.c will still be selected as /main/1: there is no version created on branch2, so element * /main/LATEST is the only rule that can be applied.