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 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: ##:TypeFamilies: incremental (a list of label types, or at least of vobs in which to find them will be necessary). There will also be an additional flag to mklbtype: -family, and a new predefined hyperlink type: OnTopOf, 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 OnTopOf 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