Configuration record example

The catcr command displays the configuration record of a specified DO.

The following figure shows a CR, with annotations to indicate the various kinds of information in the listing.

config example — Figure 1: Kinds of information in a configuration record

Some notes on the preceding figure:

03 version of the source element, listed with version-ID. By default, catcr does not list versions of the VOB directories involved in a build. To list this information, use the -long option:
```
cleartool catcr -long util.o
directory version /vobs/hw/.@@/main/1     <25-Feb-06.16:59:31>
directory version /vobs/hw/src@@/main/3   <26-Feb-06.20:53:07>
...
```
Declared dependencies. One principal feature of VersionVault is the automatic detection of source dependencies on MVFS files: versions of elements and objects in view-private storage. In addition, a CR includes non-MVFS objects that are explicitly declared as dependencies in the makefile. The preceding figure shows one such declared dependency, on file build.notes.1, located in the non-VOB directory /tmp.
Listing of checked-out versions. Checked-out versions of file elements are highlighted. Checked-out versions of directory elements are listed like this:
```
directory version /vobs/hw/src@@/main/CHECKEDOUT    <26-Feb-06.17:05:23>
```
When the elements are subsequently checked in, a listing of the same configuration record shows the updated information. For example,
```
/vobs/hw/src/util.c                   <25-Feb-06.17:02:27>
```
becomes
```
/vobs/hw/src/util.c@@/main/4        <25-Feb-06.17:02:27>
```
The actual configuration record contains a VersionVault internal identifier for each MVFS object. After the version is checked in, catcr lists that object differently.
Notes:
1. The time stamps in the configuration record are for informational purposes; they are not used for rebuild or winkin decisions. VersionVault uses OIDs to track versions used in builds.
2. It is possible to produce two configuration records that show different time stamps for the same version of an object. If an object is checked out before a build, clearmake records the checkout time as the most recent modification time of the object. If you then check in the object and rebuild, clearmake records the checkin time as the most recent modification time of the object. Comparing the configuration records from both builds then shows that the same version of the object has different time stamps.