3.12 Using Config Spec Time Rules

NOTE: If you use a UCM view, your config spec is generated by ClearCase. Do not add time rules to your config spec.

Using the reference time facility described in Continuing to Work During a Build, omake (or clearmake) blocks out potentially incompatible source-level changes that take place after your build begins. But sometimes, the incompatible change has already taken place. ClearCase allows you to block out recently created versions.

A typical ClearCase team-development strategy is for each team member to work in a separate view, but to have all the views use the same config spec. In this way, the entire team works on the same branch. As long as a source file remains checked out, its changes are isolated to a single view; when a developer checks in a new version, the entire team sees the new version on the dedicated branch.

This incremental integration strategy is often very effective. But suppose that another user's recently checked-in version causes your builds to start failing. Through an exchange of e-mail, you trace the problem to header file project_base.h, checked in at 11:18 A.M. today. You, and other team members, can reconfigure your views to roll back that one element to a safe version:

element project_base.h ...\onyx_port\LATEST -time 5-Mar.11:00

If many interdependent files have been revised, you can roll back the view for all checked-in elements:

element * ...\onyx_port\LATEST -time 5-Mar.11:00

For a complete description of time rules, see the config_spec reference page.

Inappropriate Use of Time Rules

Your view interprets time rules with respect to the create version event record written by the checkin command. The checkin is read from the system clock on the VOB server host. If that clock is out of sync with the clock on the view server host, your attempt to roll back the clock may fail. Thus, don't strive for extreme precision with time rules: select a time that is well before the actual cutoff time (for example, a full hour before, or in the middle of the night).

Do not use time rules to freeze a view to the current time immediately before you start a build. Allow omake's (or clearmake's) reference time facility to perform this service. Here's an inappropriate use scenario:

1. You check in version 12 of util.c at 7:05 P.M. on your host. You do not know that clock skew on the VOB host causes the time 7:23 P.M. to be entered in the create version event record.

2. To freeze your view, you change your config spec to include this rule:

element * \main\LATEST -time 19:05

3. You issue an omake (or a clearmake) command immediately (at 7:06 P.M.) to build a program that uses util.c. When selecting a version of this element to use in the build, your view consults the event history of util.c and rejects version 12, because the 7:23 P.M. time stamp is too late for the -time configuration rule.