NAME

Examples

USING THE BRANCHOFF:ROOT MODEL

The Config Spec

##:BranchOff: root
element * CHECKEDOUT
element * .../tt/LATEST
mkbranch tt
element * TTT
element * BL
element /main/0

Most of this is standard. Let's read it bottom up:

/main/0: handle new elements, not bearing any label yet
BL: a common baseline
TTT: our own label--more on it later
mkbranch tt: a directive applying to the 3 previous (which follow it)
.../tt/LATEST: catch our versions, before we labeled them
CHECKEDOUT: catch our versions, before we checked them in
##:BranchOff: root: an extension of this wrapper

One of our goals will be to make this config spec as stable as possible, i.e. to manage changes by means not requiring us to modify it. A good reason for that is that it is not versioned.

A second goal is to systematically branch out for making new versions (unless already on a tt branch). The rationale is that this is always possible, independent from mastership or checkout state.

A third goal is to avoid cascading, thus to always branch from the root branch (usually main. This must be explicitly enabled, and is thus governed by our strange setting on line 1.

First Use: Nothing Special

$ ct mkbrtype -nc tt
Created branch type "tt".
$ ct co -nc .
Created branch "tt" from "." version "/main/0".
Checked out "." from version "/main/tt/0".
$ ct mkdir -nc a
Created directory element "a".
Created branch "tt" from "a" version "/main/0".
Checked out "a" from version "/main/tt/0".
$ ct mkelem -nc -ci a/foo
Created element "a/foo" (type "text_file").
Created branch "tt" from "a/foo" version "/main/0".
Checked in "a/foo" version "/main/tt/1".
$ ct ci -nc a
Checked in "a" version "/main/tt/1".

APPLYING INCREMENTAL LABELS

Create a family label type

$ ct mklbtype -nc -fam TTT
Created label type "TTT_1.00".
Created label type "TTT".
Created attribute type "RmTTT".

Note that this creates:

a floating type: TTT
an equivalent fixed type: TTT_1.00
an attribute type dedicated to the family (see: rmlabel below)

Apply the base labels

$ ct mklabel -rec TTT .
Created label "TTT_1.00" on "." version "/main/tt/1".
Created label "TTT" on "." version "/main/tt/1".
Created label "TTT_1.00" on "a" version "/main/tt/1".
Created label "TTT" on "a" version "/main/tt/1".
Created label "TTT_1.00" on "a/foo" version "/main/tt/1".
Created label "TTT" on "a/foo" version "/main/tt/1".

The labels are applied in pairs: fixed, and floating. The first application is thus significantly slower than usual (~4 times)

Lock the label types

$ ct lock lbtype:TTT
Locked label type "TTT".
Locked label type "TTT_1.00".

This is not mandatory of course, but it is a good idea, and it is supported. The fixed type should not be moved anymore, so why not locking it?

The floating label will get unlocked as needed, but locking it communicates its state to others, and leaves a timestamp (the latest one is not scrubbed).

Increment the label type

$ ct mklbtype -nc -inc TTT
Unlocked label type "TTT".
Unlocked label type "TTT_1.00".
Created label type "TTT_1.01".
Locked label type "TTT_1.00".

A new incremental fixed label is created. It gets linked to the previous, which is thus unlocked, and locked back.

Make a change, and label incrementally

$ ct co -nc a/foo
Checked out "a/foo" from version "/main/tt/1".
$ ct ci -nc -ide a/foo
Checked in "a/foo" version "/main/tt/2".
$ ct mklabel -over tt TTT .
Created label "TTT_1.01" on "a/foo" version "/main/tt/2".
Moved label "TTT" on "a/foo" from version "/main/tt/1" to "/main/tt/2".

We use the -over tt option as a way to optimize the labeling speed. Note that it also restricts the application to checked-in versions.

Labeling recursively would display the same incremental behaviour, possibly applying labels to checked-out versions.

Check the results so far

$ ct lsgen a/foo a
a/foo@@/main/tt/2 (TTT, TTT_1.01)
 a/foo@@/main/tt/1 (TTT_1.00)
a@@/main/tt/1 (TTT, TTT_1.00)

We examine two objects, with the lsgenealogy command.

This one navigates Merge hyperlink to present the recent history of contribution to the selected versions.

We note that the floating label designates a (full) baseline, whereas the fixed labels are sparse and designate thus the successive change sets.

Increment again, to remove a label

$ ct mklbtype -nc -inc TTT
Created label type "TTT_1.02".
$ ct rmlabel TTT a/foo
Removed label "TTT" from "a/foo" version "/main/tt/2".

What we want to demonstrate now is a way to restore a past configuration. For this we shall still create one version and apply one more increment, in order to build up enough of history.

$ ct co -nc a/foo
Checked out "a/foo" from version "/main/tt/2".
$ ct ci -nc -ide a/foo
Checked in "a/foo" version "/main/tt/3".
$ ct mklbtype -nc -inc TTT
Created label type "TTT_1.03".
$ ct mklabel -over tt TTT .
Created label "TTT_1.03" on "a/foo" version "/main/tt/3".
Created label "TTT" on "./a/foo" version "/main/tt/3".

Note that the floating label was created, not moved, since we had removed it.

ARCHIVING BRANCHES AFTER LABELING

Archive to deliver

Currently, our config spec selects the version of foo with our tt branch, i.e. doesn't use our labels. Let's change this:

$ ct ls a/foo
a/foo@@/main/tt/3                                        Rule: .../tt/LATEST
$ ct mkbrtype -nc -arc tt
Renamed branch type from "tt" to "tt-001".
Created branch type "tt".
$ ct ls a/foo
a/foo@@/main/tt-001/3                                    Rule: TTT [-mkbranch tt]

Now we are using our label, placing ourselves in the same situation as anybody else who would want to share our code in a collaborative manner. Only now did we perform a (still only intermediate) delivery!

Note how we didn't need to change our config spec, but only to reinterpret it.

Note finally how our config spec preserved the continuity of the selection.

Checking out after delivery

$ ct co -nc a/foo
Created branch "tt" from "a/foo" version "/main/0".
Checked out "a/foo" from version "/main/tt/0".
$ ct ci -nc -ide a/foo
Checked in "a/foo" version "/main/tt/1".
$ ct lsgen a/foo
a/foo@@/main/tt/1
 a/foo@@/main/tt-001/3 (TTT, TTT_1.03)
  a/foo@@/main/tt-001/2 (TTT_1.01)
   a/foo@@/main/tt-001/1 (TTT_1.00)

Now, we really experimented our cascade prevention, i.e. branching off root. The continuity of the data is preserved, as well, using the lsgenealogy tool, this of the version history.

REPRODUCING A PAST CONFIGURATION

Set a view equivalent to TTT at 1.01

$ ct mkview -tag ttTTT -stg -auto
...
$ ct catcs > /tmp/cs
$ perl -pi -le 'print q(##:IncrementalLabels: TTT_1.01@/vob/test) if $.==1' /tmp/cs
$ ct setcs -tag ttTTT /tmp/cs
$ ct setview ttTTT
$ ct ls -d a/foo a
a/foo@@/main/tt-001/2            Rule: {lbtype(TTT_1.01)&&!attr_sub(RmTTT,<=,1.01)}
a@@/main/tt-001/1                Rule: {lbtype(TTT_1.00)&&!attr_sub(RmTTT,<=,1.01)}

We added to the config spec before setting it a directive instructing to compute from the label type family a set of rules equivalent to the TTT floating label, as its equivalent fixed type was TTT_1.01.

We checked that these rules selected the correct versions of our two reference elements (the foo file, and the a directory).

The directive was actually converted as a inclusion of a new file:

$ ct catcs | head -1
include /cc/views/mg/ttTTT.vws/TTT_1.01
$ cat /cc/views/mg/ttTTT.vws/TTT_1.01
element * "{lbtype(TTT_1.01)&&!attr_sub(RmTTT,<=,1.01)}"
element * "{lbtype(TTT_1.00)&&!attr_sub(RmTTT,<=,1.01)}"

Set views equivalent to 1.02 and 1.03 stages of TTT

$ perl -pi -e 's/TTT_1.01/TTT_1.02/ if $.==1' /tmp/cs
$ ct setcs -tag ttTTT /tmp/cs
$ ct setview ttTTT
$ ct ls -d a/foo a
a/foo@@/main/tt/1                Rule: .../tt/LATEST
a@@/main/tt-001/1                Rule: {lbtype(TTT_1.00)&&!attr_sub(RmTTT,<=,1.02)}

The first selection is unfortunate and reminds us that we must remove the rules based on tt branches and TTT labels from config specs equivalent to fixed baselines!

$ perl -ni -e 'print unless m%(/tt/LATEST|TTT)$%' /tmp/cs
$ ct setcs /tmp/cs
$ ct ls -d a/foo a
a/foo@@/main/0                   Rule: /main/0 [-mkbranch tt]
a@@/main/tt-001/1                Rule: {lbtype(TTT_1.00)&&!attr_sub(RmTTT,<=,1.02)}
$ perl -pi -e 's/TTT_1.02/TTT_1.03/ if $.==1' /tmp/cs
$ ct setcs /tmp/cs
$ ct ls -d a/foo a
a/foo@@/main/tt-001/3            Rule: {lbtype(TTT_1.03)&&!attr_sub(RmTTT,<=,1.03)}
a@@/main/tt-001/1                Rule: {lbtype(TTT_1.00)&&!attr_sub(RmTTT,<=,1.03)}

We can now see the meaning of RmTTT, and see how attributes of this type were added to the different versions of the tree:

$ ct lsvtree -s a/foo | perl -ple 's/(.*)/des -fmt "\%Vn \%Nl \%Na\\n" $1/' | ct
/main
/main/0
/main/tt-001
/main/tt-001/1 TTT_1.00 RmTTT=1.02
/main/tt-001/2 TTT_1.01 RmTTT=1.02
/main/tt-001/3 TTT TTT_1.03
/main/tt
/main/tt/1

This command shows the versions, with the labels, and the attributes they bear.

To install ClearCase::Wrapper::MGi, copy and paste the appropriate command in to your terminal.

cpanm

cpanm ClearCase::Wrapper::MGi

CPAN shell

perl -MCPAN -e shell
install ClearCase::Wrapper::MGi

For more information on module installation, please visit the detailed CPAN module installation guide.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	Go to GitHub issues (only if GitHub is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)