Storage of derived objects

When a DO is created, its data container is located in the view storage area.

For a shareable DO, the HCL VersionVault 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 (see the following figure).

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 path name (for example, /vobs/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 VersionVault storage area. This file is called a data container; it contains the file system data of a DO.
  • 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. For more information, 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 writes information about the DO into the VOB.

Promotion and winkin

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 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 1: Storage of a shareable derived object

storage

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 the disk storage of each other.

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.