3.11 Continuing to Work During a Build

As your build progresses, other developers continue to work on their files and may check in new versions of elements that your build uses. If your build takes an hour to complete, you do not want build scripts executed early in the build to use version 6 of a header file, and scripts executed later to use version 7 or 8.

To prevent such inconsistencies, any version whose selection is based on a LATEST config spec rule is locked out if it is checked in after the instant that omake (or clearmake) was invoked. The moment that the omake (or clearmake) build session begins is the build reference time.

The same reference time is reported in each configuration record produced during the build session, even if the session lasts hours (or days):

Z:\avob> cleartool catcr hello.obj
Target hello.obj built by drp.dvt
Host "fermi" running Windows NT 3.5 (807)
Reference Time 26-Feb-99.16:53:58, this audit started 26-Feb-99.16:54:10 ...

NOTE: The reference time is the build reference time, when the overall omake (or clearmake) build session began. The this audit started time is when the execution of the individual build script began.

When determining whether an object was created before or after the build reference time, omake (or clearmake) adjusts for clock skew, the inevitable small differences among the system clocks on different hosts. For more on build sessions, see Build Sessions, Subsessions, and Hierarchical Builds.

CAUTION: A build's coordinated reference time applies to elements only, providing protection from changes made after the build began. You are not protected from changes to view-private objects and non-MVFS objects. For example, if you begin a build and then change a checked-out file used in the build, a failure may result. Therefore, do not work on the same project in a view where a build is in progress.