ClearCase Reference Manual, Release 4.0, Windows

diffcr

Compares configuration records created by clearmake, omake, or clearaudit

APPLICABILITY

ClearCase (cleartool subcommand), Attache (command)

SYNOPSIS

diffcr [ -r·ecurse | -fla·t ] [ -sel·ect do-leaf-pattern ] [ -ci ] [ -typ·e { f | d | l } ... ]: [ -ele·ment_only ] [ -vie·w_only ] [ -cri·tical_only ] [ -nam·e tail-pattern ]
[ -wd ] [ -nxn·ame ] [ -l·ong | -s·hort ] do-pname-1 do-pname-2

DESCRIPTION

The diffcr command compares the configuration records (CRs) of two derived objects. A CR is produced by clearmake, clearaudit, or omake when it finishes executing a build script in a dynamic view. By comparing CRs, you can determine these differences:

Versions of MVFS objects used as sources or produced during the build (includes elements and other objects whose pathnames are under a VOB mount point)
(For builds performed with omake) Versions of non-MVFS objects that appeared as makefile dependencies during the build (explicit dependencies declared in the makefile)
The total number of times an object was referenced during a build, and the first target in which that object was referenced
Build options (which can come from the command line, the Windows environment, the makefile itself, and so on)
The build script executed
Noncritical differences, such as the date/time of the build, dynamic view name, or host name

NOTE: Not all of this information is available from configuration records of DOs created by clearaudit.

The do-pname arguments specify the derived objects to be compared. You can specify a derived object in these ways:

Use a derived-objectID (DO-ID), which identifies a derived object created in any dynamic view. A DO-ID takes the following form:

DO-pname@@creation_date.creation_time.id-number

For example:

myprog.obj@@11-Nov.17:39.3871

To display a derived object's DO-ID, use lsdo.

Use a standard pathname, which identifies a DO created in the current dynamic view. For example, myprog.obj.
Use a view-extended pathname, which identifies a DO created in another dynamic view. For example, M:\jpb_view\vob1\src\myprog.obj.

You can compare a nonshareable DO in your view to a nonshareable DO created in another view, but you must use a view-extended pathname to specify the DO in the other view.

diffcr supports the same filter and report style options as the catcr command. This means that you can restrict the comparison to particular subtargets of the do-pnames, control which objects appear in the listing, select how pathnames are displayed, and expand the listing to include comments and other supplementary information. See the catcr reference page for additional information.

DOs in Unavailable Views

diffcr maintains a cache of tags of inaccessible views. For each view-tag, the command records the time of the first unsuccessful contact. Before trying to access a view, the command checks the cache. If the view's tag is not listed in the cache, the command tries to contact the view. If the view's tag is listed in the cache, the command compares the time elapsed since the last attempt with the timeout period specified by the CCASE_DNVW_RETRY environment variable. If the elapsed time is greater than the timeout period, the command removes the view-tag from the cache and tries to contact the view again.

The default timeout period is 60 minutes. To specify a different timeout period, set CCASE_DNVW_RETRY to another integer value (representing minutes). To disable the cache, set CCASE_DNVW_RETRY to 0.

PERMISSIONS AND LOCKS

Permissions Checking: No special permissions required. Locks: No locks apply.

OPTIONS AND ARGUMENTS

COMPARING DIFFERENCES IN SUBTARGETS. Default: diffcr compares the CRs for do-pname-1 and do-pname-2 only, not for any of their subtargets.

-r·ecurse: Compares the CRs of the two specified derived objects, and their common subtargets. Each pair of CRs is compared separately. By default, a recursive comparison does not descend into DO versions; use -ci to override this.

-fla·t: Similar to -recurse, but consolidates the CRs for each do-pname-n into a single list, with no duplicates, and then compares the lists. The report includes file system objects only; no headers, variables and options, or build scripts. It also includes the total number of times each object was referenced during the build, and the first target in which that object was referenced (First seen in target).

-sel·ect do-leaf-pattern: Starts the comparison at the subtargets of do-pname that match do-leaf-pattern (which can include pattern-matching characters; see the ClearCase wildcards_ccase or Attache wildcards reference page). This option is useful for focusing on a particular object (for example, object module hello.obj) that was built as part of a larger object (for example, executable hello.exe).

-ci (for use with -recurse or -flat only): Descends into the CRs of DO versions that were used as build sources.

SPECIFYING KINDS OF OBJECTS TO DISPLAY. Default: diffcr reports on all objects in the CRs, which may include source files and directories; derived objects; makefiles; view-private files, and (for builds performed with omake) non-MVFS objects that were explicitly declared as dependencies.

-typ·e { f | d | l } ...: Lists file-system objects of a particular kind: files (f) directories (d), or links (l). The default value varies with the report style: normal and short listings (-short) default to f; long listings (-long) default to fdl. You may specify multiple kinds of objects by grouping them into a single argument; -type fd, for example.

-ele·ment_only: Lists versions of elements only, including checked-out versions. This option excludes from the listing derived objects (except DO versions), view-private files and directories, and non-MVFS objects.

-vie·w_only: Lists view-private objects only, including checked-out versions of elements. If you specify this option along with -element_only, the listing includes only checked-out versions of elements.

-cri·tical_only: Excludes from the listing any differences in objects marked as "noncritical" in the CR. Objects with that property typically have it because the user specified them as dependents of the .NO_DO_FOR_SIBLING special target in a clearmake makefile or as dependents of the .NODO_FOR_SIBLING special target in an omake makefile.

-nam·e tail-pattern: Considers the entry for a file system object only if its final pathname component matches the specified pattern. See the ClearCase wildcards_ccase or Attache wildcards reference page for a list of pattern-matching characters.

CONTROLLING REPORT APPEARANCE. Default: diffcr reports, in three sections, on MVFS objects, variables and options, and the build script. The report uses full pathnames, and it omits comments and directory versions.

-wd: Lists pathnames relative to the current working directory, rather than as full pathnames.

-nxn·ame: Lists simple pathnames for MVFS objects, rather than version-extended pathnames or DO-IDs.

-l·ong: Expands the report to include the kinds of objects in the CR, and comments. For example, an object may be listed as a version, a directory version, or derived object (see ls -long for a complete list). Comments indicate whether an object is in a makefile, a referenced derived object, or a new derived object.

-s·hort: Restricts the report to file-system objects only (omits header information, variables and options, and build scripts).

SPECIFYING THE DERIVED OBJECTS. Default: None.

do-pname-1, do-pname-2: Standard pathnames and/or DO-IDs of two derived objects to be compared. Either or both can be a DO version.

EXAMPLES

Examples including wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the command interpreter prompt. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt. In Attache, cmd-context represents the workspace prompt.

Compare the CRs of two derived objects built at the name bgrs.exe. Use lsdo to determine the DO-ID of the derived object that is not visible in the current dynamic view.

cmd-context lsdo -zero bgrs.exe

11-Dec.15:24 "bgrs.exe@@11-Dec.15:24.1487" 11-Dec.12:05 "bgrs.exe@@11-Dec.12:05.1256"

cmd-context diffcr -flat bgrs.exe bgrs.exe@@11-Dec.12:05.1956

< Reference Time 11-Dec-98.15:23:52, this audit started 11-Dec-98.15:23:59 > Reference Time 11-Dec-98.12:02:39, this audit started 11-Dec-98.12:04:52 < View was DRIVE:\users\jones\views\main.vws [uuid 66e68edc.471511cd.ac55.08:00:2b:33:ec:ab] > View was DRIVE:\users\jones\views\r1_fix.vws [uuid 8b468fd0.471511cd.aca5.08:00:2b:33:ec:ab] ---------------------------- ---------------------------- MVFS objects: ---------------------------- < \vob1\docaux\bgr\bgrs.exe@@11-Dec.15:24.1987 > \vob1\docaux\bgr\bgrs.exe@@11-Dec.12:05.1956 ---------------------------- < \vob1\docaux\bgr\bugs.obj@@11-Dec.15:23.1981 > \vob1\docaux\bgr\bugs.obj@@11-Dec.12:03.1902 ---------------------------- < \vob1\docaux\bgr\bugsched.obj@@11-Dec.15:23.1984 > \vob1\docaux\bgr\bugsched.obj@@11-Dec.12:04.1953

The comparison shows that the builds used different versions of the object modules bugs.obj and bugsched.obj.

Compare the same two derived objects again, this time including the CRs of all subtargets.

cmd-context diffcr -flat bgrs.exe bgrs.exe@@11-Dec.12:05.1956

---------------------------- MVFS objects: ---------------------------- ---------------------------- < First seen in target "bugs.obj" < 1 \vob1\docaux\bgr\bugs.c@@\main\2 <11-Dec-98.15:22:53> > First seen in target "bugs.obj" > 1 \vob1\docaux\bgr\bugs.c@@\main\1 <19-Dec-97.11:49:54> ---------------------------- < First seen in target "bugsched.obj" < 1 \vob1\docaux\bgr\bugsched.c@@\main\2 <11-Dec-98.15:23:04> > First seen in target "bugsched.obj" > 1 \vob1\docaux\bgr\bugsched.c@@\main\1 <19-Dec-97.11:50:07> ---------------------------- < First seen in target "bgrs.exe" < 1 \vob1\docaux\bgr\bgrs.exe@@11-Dec.15:24.1987 > First seen in target "bgrs.exe" > 1 \vob1\docaux\bgr\bgrs.exe@@11-Dec.12:05.1956 ---------------------------- < First seen in target "bgrs.exe" < 2 \vob1\docaux\bgr\bugs.obj@@11-Dec.15:23.1981 > First seen in target "bgrs.exe" > 2 \vob1\docaux\bgr\bugs.obj@@11-Dec.12:03.1902 ---------------------------- < First seen in target "bgrs.exe" < 2 \vob1\docaux\bgr\bugsched.obj@@11-Dec.15:23.1984 > First seen in target "bgrs.exe" > 2 \vob1\docaux\bgr\bugsched.obj@@11-Dec.12:04.1953

The integer at the beginning of an entry indicates the number of times the object was referenced during the build. The first seen in target message indicates the first target rebuild in which the object was referenced.

For the same two derived objects as in the preceding examples, compare the file element versions used to build subtarget bugsched.obj. Report the differences in short format.

cmd-context diffcr -short -select bugsched.obj -type f -element_only bgrs.exe ^ bgrs.exe@@11-Dec.12:05.1956

---------------------------- < \vob1\docaux\bgr\bugsched.c@@\main\2 > \vob1\docaux\bgr\bugsched.c@@\main\1

Compare two builds of program main, listing only those entries that involve the file src\prog.c.

cmd-context diffcr -recurse -name prog.c main1 main2