Using config spec time rules

If you use a UCM view, your config spec is generated by DevOps Code 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. For example, if a rule contains a remote branch type and a synchronization takes place during a build, omake (or clearmake) uses the latest version of the remote files that were checked in before the time lock. If, however, an incompatible change has already taken place, ClearCase allows you to block out the recently created versions.

A typical ClearCase 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 it on the dedicated branch.

This incremental integration strategy is often very effective. But suppose that the recently checked-in version of another user 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.