3

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?

Tudor Timi
  • 7,453
  • 1
  • 24
  • 53

1 Answers1

1

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

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • My wording was probably wrong. Where I said 'some_feature' I meant some family big family of sub-features and where I said 'some_task' I meant one of these 'sub_features'. I understand that workflows should be work-oriented and not developer-oriented. I'll update my question. – Tudor Timi Aug 07 '17 at 09:00
  • @TudorTimi I agree, but my answer still stands. Using ... is preferable. – VonC Aug 07 '17 at 09:01
  • Regarding from timestampt vs. from label, we don't have any labels since we don't define any intermediate milestones. Currently we only have timestamps. It would be interesting to talk about labeling for purposes other than releasing. I'll have to open a new question about this. – Tudor Timi Aug 07 '17 at 09:01
  • @TudorTimi Out of curiosity, why do you still have ClearCase in 2017? – VonC Aug 07 '17 at 09:02
  • I'm working in hardware development and our design flows are still centered around base ClearCase (without any sort of workflow). Basically everybody checks into /main/LATEST, steps on each other's toes and uses ClearCase merely for backup. – Tudor Timi Aug 07 '17 at 09:04
  • @TudorTimi OK. I was wondering if the code base was so big hat a standard modern VCS like Git was not appropriate. – VonC Aug 07 '17 at 09:05
  • The issue isn't just the code base, it's the whole design flow (what in software terms would be called the build setup). Think of it like having N levels of compilers, each generating input for the next one down the chain. The input for each "compiler" also needs to be edited by hand. There is a lot of process in place to make sure that what each "compiler" produces is used by the next one down the chain. Part of this flow is the data management support. – Tudor Timi Aug 07 '17 at 09:09
  • @TudorTimi interesting problem! Legacy process is indeed a good reason for that kind of tool to remain in place. – VonC Aug 07 '17 at 09:11
  • I'll probably be asking more questions about this kind of stuff. Thanks for the answer! It's great to be able to tap into knowledge from much more experienced people. – Tudor Timi Aug 07 '17 at 09:18