11.6 Views to Monitor Project Status

The config specs presented here are useful for views used for research and monitoring project status.

View That Uses Attributes to Select Versions

Suppose that the QA team also works on the major branch. Individual developers are responsible for making sure that their modules pass a QA check. The QA team builds and tests the application, using the most recent versions that have passed the check.

The QA team can work in a view that uses this config spec:

To make this scheme work, you must create an attribute type, QAOK. Whenever a new version that passes the QA check is checked in on the major branch, an instance of QAOK with the value Yes is attached to that version. (This can be done manually or with a ClearCase trigger.)

If an element in the \src directory has been edited on the major branch, this view selects the branch's most recent version that has been marked as passing the QA check (Rule 1). If no version has been so marked or if no major branch has been created, the most recent version on the main branch is used (Rule 2).

NOTE: Rule 1 on this config spec does not provide a match if an element has a major branch, but no version on the branch has a QAOK attribute. This command can locate the branches that do not have this attribute:

cleartool find . -branch "{brtype(major) && ! attype_sub(QAOK)}" -print

The attype_sub primitive searches for attributes on an element's versions and branches, as well as on the element itself.

This scheme allows the QA team to monitor the progress of the rest of the group. The development config spec always selects the most recent version on the major branch, but the QA config spec may select an intermediate version (Figure 41).

Figure 41 Development Config Spec vs. QA Config Spec

Pitfalls of Using This Configuration for Development

You may be tempted to add a CHECKEDOUT rule to the above config spec, turning the QA configuration into a development configuration:

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 (Figure 42).

Figure 42 Checking Out a Branch of an Element

Performing a checkout in this view checks out version \main\major\3, not version \main\major\2:

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 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 this problem by modifying the config spec and creating another branching level at the version that the attribute selects. This is the new config spec:

View That Shows Changes of One Developer

This config spec makes it easy to examine all changes a developer has made since a certain milestone:

A particular date, April 25, is used as the milestone. The configuration is a snapshot of the main line of development at that date (Rule 2), overlaid with all changes that user jackson has made on the main branch since then (Rule 1).

The output of the cleartool ls command distinguishes jackson's files from the others: each entry includes an annotation as to which configuration rule applies to the selected version.

This is a research view, not a development view. The selected set of files may not be consistent: some of jackson's changes may rely on changes made by others, and those other changes are excluded from this view. Thus, this config spec omits the standard CHECKEDOUT and \main\LATEST rules.

Historical View Defined by a Version Label

This config spec defines a historical configuration:

This view always selects the set of versions labeled R1.0. In this scenario, all these versions are on the main branch of their elements. If the R1.0 label type is one-per-element, not one-per-branch, this config spec selects the R1.0 version on a subbranch. (For more information, see the mklbtype reference page.)

The -nocheckout qualifier prevents any element from being checked out in this view. (It also prevents creation of new elements, because the parent directory element must be checked out.) Thus, there is no need for the CHECKEDOUT configuration rule.

NOTE: The set of versions selected by this view can change, because version labels can be moved and deleted. For example, using the command mklabel -replace to move R1.0 from version 5 of an element to version 7 changes which version appears in the view. Similarly, using rmlabel suppresses the specified elements from the view. (The cleartool ls command lists them with a [no version selected] annotation.) If the label type is locked with the lock command, the configuration cannot change.

You can use this configuration to rebuild Release 1.0, verifying that all source elements have been labeled properly. You can also use it to browse the old release.

Historical View Defined by a Time Rule

This config spec defines a frozen configuration in a slightly different way than the previous one:

This configuration selects the version that was the most recent on the main branch on September 4 at 2 A.M. Subsequent checkouts and checkins cannot change which versions satisfy this criterion; only deletion commands such as rmver or rmelem can change the configuration. The -nocheckout qualifier prevents anyone from checking out or creating elements.

This configuration can be used to view a set of versions that existed at a particular point in time. If modifications must be made to this source base, you must modify the config spec to "unfreeze" the configuration.