CODEWITHSUNDEEP
clearcase
Tudor Timi
Tudor Timi

Reputation: 7573

ClearCase config spec for nested branching

We have a VOB where code development is mostly done in the main branch. At a certain point in time, it's time to work on some new features that are closely related to each other. For this, we created a new branch, some_feature_set. Multiple developers work on this feature set. Each developer works in an own branch and once a certain sub-feature is deemed finished, it gets merged back into some_feature_set. Once the feature set is fully implemented, the plan is to merge it into main.

To achieve this, we use config specs like this one:

element * CHECKEDOUT
element * /main/some_feature_set/some_sub_feature/LATEST
element * /main/some_feature_set/LATEST -mkbranch some_sub_feature
element * /main/LATEST -mkbranch some_feature_set

Since work for some_sub_feature is intended to be merged into some_feature_set, our idea was to already branch from some_feature_set before creating the task branch.

Our organization uses dynamic views (and we can't change this). In order to protect ourselves from changes that other developers make to the main and some_feature_set branches which might break ongoing work in the sub-feature branch, we use timestamps. A config spec would therefore look like this:

element * CHECKEDOUT
element * /main/some_feature_set/some_sub_feature/LATEST
mkbranch some_sub_feature
  element * /main/some_feature_set/LATEST -time <some_time>
  mkbranch some_feature_set
    element * /main/LATEST -time <some_time>
  end mkbranch
end mkbranch

This causes issues when checking out a file from main. ClearCase will branch it to some_feature_set, but since there is no rule to select the newly created version, it will try to branch again and issue an error that the branch exists. This we can fix by adding more rules to the config spec:

element * CHECKEDOUT
element * /main/some_feature_set/some_sub_feature/LATEST
mkbranch some_sub_feature
  element * /main/some_feature_set/LATEST -time <some_time>
  element * /main/some_feature_set/0
  mkbranch some_feature_set
    element * /main/LATEST -time <some_time>
    element * /main/0
  end mkbranch
end mkbranch

This way we don't get any issues when checking out files or adding new files to ClearCase. The issue we do get, though, is that when another developer wants to do some work for the some_feature_set branch for a file that only had the main branch and checks this file out, the version selected by the view will change.

Let's say, for example, that with the config spec listed above, version /main/4 gets selected for some_file in my view. Work continues in parallel and version /main/5 is created by a different developer. The time rule in the config spec will still select version /main/4. At some later point in time, yet another developer has to do some work for some_feature_set and sets up an own view with a similar config spec but with a newer timestamp, such that some_file gets version /main/5 selected. This developer has to make some changes to some_file and checks it out. This immediately creates versions /main/some_feature_set/0 and /main/some_feature_set/some_other_sub_feature/0. Because /main/some_feature_set/0 now exists, my view selects it. It's contents are the same as /main/5 and not /main/4 as was the case before the other developer checked out the file.

Is there anything that can be done to prevent the issue described above from happening?

Upvotes: 3

Views: 1067

Answers (1)

VonC
VonC

Reputation: 1323553

First, one branch per developer for developing the same feature is not the best practice. I have long advocated against that (since 2009).

But if you must, and want sub-branches, it is far more effective to create them from label, instead of relying on time.
And it is best to not force the branch path (it becomes too finicky, as your question illustrates)

I have uses time-based selection rules in "ClearCase : Loading Older Version of a specific Directory?".
But you will see the rule for new element is both simpler and appear sony once:

element * /main/0 -mkbranch myBranch

You need to specify, for a new element, that you want it created directly in the right branch.

Which is why branch-based selection rules use generally the ellipsis notation ..., as in .../myBranch. See "Details of config spec in base ClearCase".

The general idea is: you should not care from which branch a new branch is created as long as its starting version is the right one (ie, the one with the right immutable label).

Upvotes: 1

Related Questions