Pitfalls for development of using attributes to select versions
You may be tempted to add a CHECKEDOUT rule to the config spec described
in View that uses attributes to select versions.
This addition turns the QA configuration into the following development configuration:
(0)
element * CHECKEDOUT
(1)
element –file src/* /main/major/{QAOK=="Yes"}
(2)
element * /main/LATEST
It may seem desirable to use attributes, or other kinds of metadata, in addition to (or instead
of) branches to control version selection in a development view. But such schemes introduce
complications. Suppose that the config spec above selects version /main/major/2
of element .../src/cmd.c (see the following
figure). Figure 1: Checking out a branch of an element
Performing a checkout in this view checks out version /main/major/3,
not version /main/major/2, and generates the following
message:
cleartool: Warning: Version checked out is different from version
previously selected by view.
Checked out "cmd.c" from version "/main/major/3".
This behavior reflects the DevOps Code ClearCase® restriction
that new versions can be created only at the end of a branch. Although such
operations are possible, they are potentially confusing to other team members.
And, in this situation, it is almost certainly not what the developer who
checks out the element wants to happen.
You can avoid the problem by making the following indicated changes in
the config spec:
(0)
element * CHECKEDOUT
(0a)
element * /main/major/temp/LATEST
(1)
element –file src/* /main/major/{QAOK=="Yes"} –mkbranch temp
(2)
element * /main/LATEST
The modified config spec creates another branching level at the version
that the attribute selects.
