Branches Pros and standard use

This is thought of in the context of ClearCase, and more precisely of a new branching strategy. It is surely valid in a broader scope, but I'll not try to justify it here.

Whatever version of an element you pick, there is only one next version. It becomes a shared resource before it even exists: anything affecting it changes the global state of the system.

• Checking out unreserved is irrelevant here: it only postpones the problem.

Branches lift this concern: there may be as many branches as needed spawned from the version.

One could conceive an SCM system which would not have a low-level notion of a successor at all. ClearCase however is not such a system. In any case, the notion of successor is handy, at least from the point of view of any developer, i.e. within a private branch. In other cases (on other levels), the notion of successor may have to be supported, and thus restored, but not necessarily in the same direct and low level way.

A private branch is thus private in the sense that it maps to one single editor's context, which focuses only on one version: the latest produced. Otherwise, it is public: anybody else should be able to see what's going on there, only not to compete with producing a successor (on the same branch). Let's drop the adjective private: there are no other types of branches.

So far, we got to the following (trivial and quite conventional) pattern of config spec (for an editor —passive use needs only one label -based line):

  element * CHECKEDOUT
  element * .../branch/LATEST
  element * LABEL -mkbranch branch
  element * /main/0 -mkbranch branch

• Whatever you check out, you want to select it.
• You write exclusively to branches of your own branch type (here: branch), so whatever you produced will be in such a branch and should override any further specification
• What you didn't modify yet, you pick from a version you identified already or agreed upon. It is always possible to have one single label stand for this identification: if it doesn't exist, apply it yourself! This may however be cumbersome in practice (work), so you may trade for several labels, and thus several lines in your config spec. This is however only a tradeoff, and brings the possibility that different labels would conflict, in which case the order of the lines will matter, which is not desirable.
• What is neither identified nor agreed upon, is probably new: avoid surprises (as much as possible) by picking an empty initial version of it.
• Whichever way you select a version, if you need to modify it, do it in your own branch (back to the above rule).
• Note that unless you select a version you modified, and do it thus from your own branch, you don't need to care upon where (on what branch), it sits, as long as you pick it from a label. Even if you want to closely follow the work of a collaborator, and thus pick version from her branch, do it with labels, i.e. have her drop or move a label telling you that the version is for your consumption, or label it yourself, showing her what you use.
  You could of course use a branch based rule, but this brings further problems
• Always creating a branch of a local type protects you against mastership conflicts in a MultiSite context.
• It may however produce long chains of cascading branches, and this is a problem which needs to be addressed. However, not by by merging back to a (even relative) main branch.

-- MarcGirod - 21 Sep 2007