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 Checking out a branch of an element).
Figure 1: Checking out a branch of an element

A version tree of the major branch has versions 0 through 3 and a version with stripes. Version 2 has the annotation Version that is selected by config spec. The striped version has the annotation Version that is checked out.

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 HCL VersionVault 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.