Labeling patterns

Branching (and merging) has traditionally be a sexy topic in SCM. Maybe because the known patterns are wrongly considered to apply across the huge variety (and diversity) of tools. Labeling on the contrary is considered a more humble, less controversial, topic. It is possibly even more tool dependent. Let's consider it withing the context of (base) ClearCase, and more specifically in this of a new branching strategy.

Within ClearCase, the role of labels is essentially to be used in config specs.

From this perspective, one can distinguish two cases of config specs:

Pure reproduction, i.e. passive use. This is best served with one-line config specs using exclusively one label, such as:
```
   element * BOND_0.07
   
```
Developer's environment: I am recommending that there as well, most of the config spec rules would be based on labels.

One can however easily notice that whereas in the first case, the label needed is obviously fixed, and never to be moved (its role is to record an event: shipment, delivery, testing...), this is not so in the second case. Let's first get rid of case one by saying that the obvious way to apply the first kind of labels in ClearCase is by using mklabel -con on an appropriate derived object. This leaves a lot of details unspecified, but let's make those beyond the scope of this page, and focus on the issues brought by the second scenario.

From the developer's point of view, labels are first and foremost a communication tool.

You apply labels to offer your changes for others to use them (test them, and give you feed-back), or to inform others of what you actually consume of their production. The latter may in fact be satisfied with fixed labels as depicted above, as soon as you do produce something recordable. You'll need to use the same kind of floating labels as for the former purpose, if what you need to inform others of are intentions. These labels are more often convenience labels, floating and thus moved. One may want to lock them, but mostly in order to generate a history event that won't be scrubbed within a week, so that one knows who moved them when (at least, last time).

Because of the syntax of config specs, there is a major concern, and it is the order of the rules, i.e. of the resolution of conflicts between labels.

Of course, and in any case, you build up and update floating labels with fixed ones, but typically not one-to-one.

-- MarcGirod - 24 Sep 2007