|
|
The following sections describe the kinds of DOs and their lifecycles.
During a regular build, ClearCase build tools create shareable derived objects. During an express build, they create nonshareable derived objects. Both kinds of DOs have configuration records, but only shareable DOs can be winked in by other views.
When a ClearCase build tool creates a shareable DO, it creates a configuration record for the DO and writes information about the DO into the VOB. (At this point, the DO is shareable but unshared.) Builds in other views use this information during configuration lookup. If the build determines that it can wink in an existing DO, it contacts the view containing the DO and promotes the DO to the VOB. (The DO is now shareable and shared.)
As noted in Express Builds, you must consider whether the performance benefit of winking in DOs is worth the performance cost of making them available for winkin.
NOTE: The process of looking for a DO to wink in uses an efficient algorithm to eliminate mismatches. The build tool does not contact other views to retrieve configuration records unless the configuration lookup process determines that there is a winkin candidate.
The configuration lookup process cannot guarantee that the DO is suitable for use. The process uses details in the config record to determine whether a DO is suitable for winkin, but the config record does not record all parameters of a build. For example, a config record may list only a compiler's name and the options used. If two builds use incompatible compilers with the same name, unwanted winkins from one build to the other can occur.
NOTE: To minimize occurrences of incorrect winkin, all developers must use the same set of tools. For example, put your build tools under version control and always run them from the VOB.
During an express build, the ClearCase build tool creates nonshareable DOs. The build tool creates a configuration record for the DO, but does not write information about the DO into the VOB. Because scanning the information in the VOB is the only method other builds use to find DOs, other builds cannot wink in nonshareable DOs. However, a nonshareable DO can be reused by the view in which it was built.
A nonshareable DO can have shareable sub-DOs, but not shareable siblings. A nonshareable DO can be built using a winked-in shareable DO. (However, a shareable DO cannot have nonshareable sub-DOs or siblings.)
For information on enabling express builds, see Using Express Builds to Prevent Winkin to Other Views.
You can use the same commands that you use with shareable DOs on nonshareable DOs, but some commands work differently on the two kinds of DOs. The reference pages for the commands describe the differences.
When a DO is created, its data container is located in the view storage area. For a shareable DO, the ClearCase build tool creates the VOB database object for the DO; it also writes to the VOB information about the DO that can be used during configuration lookup. A nonshareable DO has no VOB database object, and the build tool does not write any configuration lookup information into the VOB (Figure 5).
A DO consists of the following parts:
VOB database object (shareable DOs only)-Each DO is cataloged in the VOB database, where it is identified by an extended name that includes both its standard pathname (for example, \hw\src\hello.c) and a unique DO-ID (for example, 23-Feb.08:41.391).
Data container-The data portion of a derived object is stored in a standard file within a ClearCase storage area. This file is called a data container; it contains the DO's file system data.
Configuration record-Actually, a CR is associated with a DO; it is not part of the DO itself. More precisely, a CR is associated with the entire set of sibling DOs created by a particular invocation of a particular build script. See Configuration Records.
When a shareable DO is first created, it is unshared:
It appears only in that view.
Its data container is a file in the view's private storage area.
clearmake or omake writes information about the DO into the VOB.
The first time a shareable derived object is winked in by another dynamic view, or when either kind of DO is promoted manually with a winkin or view_scrubber -p command, its status changes to shared:
Its data container is promoted to a derived object storage pool in the VOB.
(shareable DOs only) If the winkin was done by the build tool or the command was executed in another view, the DO now appears in two dynamic views.
When the winkin occurs during a clearmake or omake build:
The dynamic view to which the DO is winked in, and all other views to which the DO is subsequently winked in, use the data container in VOB storage.
The original view continues to use the data container in view storage. (The view_scrubber utility removes this asymmetry, which causes all dynamic views to use the data container in VOB storage.)
When the winkin is done with the winkin or view_scrubber -p command, the data container in the view is removed after it is promoted to VOB storage. The original view and all other views to which the DO is subsequently winked in use the data container in VOB storage.
Figure 5 Storage of a Shareable Derived Object
After a derived object is winked in, it remains shared, no matter how many times it is winked in to additional dynamic views, and even if subsequent rebuilds or deletion commands cause it to appear in only one dynamic view (or zero views).
When a derived object's data container is in the VOB, any number of views can share the derived object without having to communicate with each other directly. For example, view alpha can be unaware of views beta and gamma, with which it shares a derived object. The hosts on which the view storage directories are located need not have network access to each other's disk storage.
If clearmake attempts a winkin that fails, it checks to see if any VOBs are locked. If it finds a locked VOB, it waits until the VOB is unlocked and then retries the winkin.
For more information, see the winkin and view_scrubber reference pages.
You can check in a derived object as a version of an element, creating a DO version. Other versions of such an element can also be, but need not be, derived objects. A DO version behaves like both a version and a derived object:
You can use its version-ID to reference it as both a VOB database object and a data file.
You can apply a version label to it and reference it using that label.
You can display its configuration record with catcr or compare the CR to another with diffcr.
A clearmake or omake build can wink it in if the element is located at the same pathname where the DO was originally built.
You can wink it in with a winkin command.
The describe command lists it as a derived object version. (The lsdo command does not list it at all.)
For more information on DO versions, see Working with DO Versions.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
