view release on metacpan or  search on metacpan

extra/Examples.pod  view on Meta::CPAN

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 -c 'Restore old config' -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 previously.

=head2 ARCHIVING BRANCHES AND LABELS

=head3 Archive to label

Currently, our config spec selects the version of I<foo> with our
I<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.

This step has admittedly only a temporary effect, and thus doesn't
change much: it is only a publication but not yet a delivery. It may
help us to narrow down the change set on which we are actively working
without losing sight that we did not yet deliver our prior results.

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.

=head3 Checking out after archiving

 $ 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 -c 'after archiving' -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
I<lsgenealogy> tool, as this of the version history.

=head3 Delivery

We could deliver directly from branches, assuming all the changes
would still be in branches of the same type. If this is not the case,
we'd rather consolidate our results first, using labels.
We may start with a I<home merge> (aka I<rebase>):

 $ ct findmerge . -fve BL -merge

Assuming this confirmed that no delivery had taken place which we
wouldn't have already taken into consideration, we can now label and
archive the branches, skipping for now the outputs of the commands:

 $ ct mklbtype -c Consolidation -inc TTT
 $ ct mklabel -over tt TTT
 $ ct mkbrtype -nc -arc tt

Now the delivery, from the TTT labels:

 $ ct mklbtype -nc -inc BL
 $ ct mklabel -over TTT BL
 $ ct mklbtype -nc -arc TTT
 Renamed label type from "TTT" to "TTT-001".
 Created label type "TTT".
 Renamed label type from "TTT" to "TTT_0".
 Locked label type "TTT_0".
 Locked label type "TTT-001".
 Locked label type "TTT_1.00".
 $ ct lock lbtype:BL

Two interesting points here (beyond the process itself):

=over 2

=item * The fact that we could unlock, and lock back the I<BL> type,
although we do not own it: this is an extension of the wrapper (the
events are duly logged) to allow group members (configurable) to
lock/unlock each other's types

=item * The way archiving label types differed from archiving branch types:

=over 2

=item * As for branch types, the label type is renamed I<away> from
matching anything via the config spec

=item * Again similarily, a new type is created but contrarily to the
case of branch types, this one is not left in the open, but I<hidden>
away.

=back

=back

The new hidden type keeps track of the state of the family (what would
the next increment be), and it would be resurrected by a next
I<mklbtype -fam> command.