Sketching an Implementation of Incremental Types

Rationale and design for this idea, in the context of label types. I think of using it to branch types as well, but the urgency is as explained, for labels.
I noticed only now that something very close to this (for fixed labels only, but with the necessary config spec magic) is in use as part of UCM!

I published a cleartool wrapper, which will support the following (in addition to the somewhat related ##:BranchOff: root functionality). Working on this in a Google code site.

The user will have the possibility to set a view attribute such as: ##:IncrementalLabels: XX@/vob/tag (a label type, in one vob). In UCM, the issue of vob context is solved with explicit prefixing, with a syntax involving the vobuuid to work interoperably. I'll leave it to applying incremental label of one type over whatever resource is needed, thus I don't need a prefix. Anyway, interleaving different hierachies would not work.
There will also be an additional flag to mklbtype: -family, and a new predefined hyperlink type: PrevInc, which will be injected into vobs as needed.

Creating a new -family label (for now) type will actually create 2 types: a floating one, as requested, and a fixed 'shadow' one, using the name of the previous as a prefix, and a running number, in a sortable format (maybe just _000) as postfix. The floating label type will have an PrevInc hyperlink pointing to the latter.

Enabling incremental type families in one's view will drive the following:

• Using the floating label in one's config spec will be as per default
• Moving it however will also drop instances of the topmost fixed label type
• Locking the floating type will lock the fixed one as well, unlocking it will create a new type, linked to the previous, and which will replace it in as the top the floating.
• Using a fixed type of a family in one's config spec will generate an ordered list of rules using the instances of the linked list of fixed types.

The purpose is to ensure that:

• Moving the floating label leaves a track which can be used to reproduce a configuration of the past
• Applying labels is cheap, because incremental.

Some administrative functions (e.g. on mklbtype -rep) may be considered, in order to remove unused fixed types, or to combine ones.

-- MarcGirod - 10 Oct 2007