SGI Techpubs Library

The new home for SGI documentation is the SGI Customer Portal, This site will be redirected to the new location later this month.

IRIX 5.3  »  Books  »  End-User  »  
CASEVision/ClearCase User's Guide
(document number: 007-2369-001 / published: 1994-07-21)    table of contents  |  additional info  |  download
find in page

Chapter 1. Overview of ClearCase Usage

This chapter presents an overview of day-to-day CASEVision™/ClearCase usage, from the perspective of an individual user. (We do not deal with administrative issues.)

Before reading this chapter, be sure to set up your user environment according to the instructions in the” Preparing to Use ClearCase” chapter in the CASEVision™/ClearCase Tutorial manual. For additional orientation, work through the ClearCase Tutorial manual and read (at least) the first chapter in the CASEVision™/ClearCase Concepts Guide.

Finding Your Niche

The following sections present a “minimalist” procedure for getting up and running in your organization's ClearCase environment.

Finding Your ClearCase Host

ClearCase must be installed on a host before you can use it there. (Simply accessing ClearCase executables with network pathnames does not work. Your own host must have certain data structures, including the ClearCase multiversion file system — the MVFS.) There is no single command that will tell you which hosts in your network have already been installed — check with your system administrator.

If ClearCase is already installed on your workstation, then the administrative directory /usr/adm/atria (or /var/adm/atria) will exist. In addition, you should be able to execute the clearlicense utility program:

% ls -d /usr/adm/atria
% clearlicense
License server on host "newton".
Running since Thursday 01/27/94 21:15:54.
     Max-Users  Expires       Password [status]
        20         none       aaa.bbb.ccc [Valid]
 Maximum active users allowed: 20

If the administrative directory exists, but your shell cannot find this program, there is a problem with your shell's startup script. Consult thePreparing to Use ClearCase” chapter in the CASEVision™/ClearCase Tutorial manual.

If you find a host where you would like to run ClearCase, but it's not currently installed there, see your system administrator and/or consult the CASEVision™/ClearCase Release Notes for installation instructions.

Locating Your Main Tools

The tools in the ClearCase command line interface (CLI) and graphical user interface (GUI) are described in Chapter 2, “Using the ClearCase Command Line Interface,” and Chapter 3, “Using the ClearCase Graphical User Interface.”. For now, make sure that you can access the main CLI tool, cleartool, or the main GUI tool, xclearcase:

  • Start a cleartool session, then enter a quit command to end the session.

    % cleartool
      cleartool> quit         (cleartool's interactive prompt)


  • Start an xclearcase session — the main panel appears, as in Figure 1-1:

    % xclearcase
    <prompt appears: Select view-tagclick the “Cancel” button>

    Figure 1-1. xclearcase Main Panel

Locating Your Network's ClearCase Data Structures

All ClearCase data is stored in VOBs (versioned object bases, the “public” storage areas) and views (the “private” storage areas). They are all centrally registered, making it easy for you to determine their names. For example, the cleartool subcommand lsvob (“list VOB”) shows the names of all of your networks VOBs (See Figure 1-2).

Figure 1-2. ”List VOB” command

Note: xclearcase has a “VOB Browser” for listing existing VOBs.

The asterisk (*) at the beginning of the line shown in Figure 1-2 indicates that the VOB is active on your host. The two pathnames for each VOB reflect that fact that it is activated by being mounted as a file system of type MVFS: the VOB-tag is the full pathname of the mount point on your host; the other pathname specifies the VOB's actual location.

Figure 1-2 is typical: all VOBs are activated at (mounted on) locations in a single directory — here, /vobs. This makes data structures that are actually distributed throughout the local area network all appear to be gathered together. Moreover, it is typical for some or all the VOBs to be linked together, effectively forming a single directory tree structure.

ClearCase has its own versions of the mount and umount commands, which allow non-root users to activate and deactivate public VOBs. For example, the lsvob listing in Figure 1-2 shows VOB-tag /vobs/design to be public, but currently inactive. Any user can activate the VOB as follows:

% cleartool mount /vobs/design

Getting Yourself a View

Even if a VOB is active, you cannot access it directly. All user-level access to a VOB must go through a ClearCase view. (Certain administrative commands can process a VOB at its storage directory pathname.) Without a view, a VOB's mount point just appears to be an empty directory; but as seen through a view, a VOB appears to be an entire directory tree. Each file and directory in this tree in an element, which has a version tree containing all of its historical versions (Figure 1-4).

Just as you can list all of your network's VOBs, you can list all views: (See Figure 1-3.)

Figure 1-3. “List Views” Commands

Note: xclearcase has a “View Browser” for working with existing views and creating new ones.

Figure 1-4. VOB as seen through view

Like a VOB, a view has a storage directory (its real location), but is accessed through a convenient view-tag. (A VOB-tag is a full pathname, because it is a mount point; but a view-tag is a simple name, because you can access it like a directory.) And like a VOB, a view must be explicitly activated; an active view is indicated by an asterisk in the lsview listing.

When a view is active on a host, it appears as a directory at a special location in the host's file system. In the ClearCase viewroot directory (usually /view), the view-tags of all active views appear as subdirectories:

% ls -F /view
garyf_mainline/     gordons_view/     mainline/

We defer details on creating new views until Chapter 4, “Setting Up a View,” for now, let's suppose that the existing view gordons_view is available for your use. The easiest way to use a view is to “set the view”. Setting a view creates a new shell process that you can use to work with any active VOB.

Going to a Development Directory

After setting a view, you can work with any VOB, much as if it were a standard directory tree:

  • navigate with cd, ls, and so on

  • view and edit files with cat, more, vi, emacs, and so on

  • analyze files with grep, sed, awk, and so on

For example:

% cd /vobs/design               (go to the VOB-tag of any VOB 
                                            —its mount point)
% ls -F                                     (what's there?..)
% <no output>              appears to be empty)
% cleartool setview gordons_view                 (set a view)
% ls -F                                        (try again ..)
bin/   include/   lost+found/   (..the VOB's contents appear)
src/   test/

The View as Virtual Workspace

The reason you must use a view to work with VOBs stems from the two essential services provided by a view:

  • Version selection — All of an element's versions are potentially accessible through the element's standard pathname. The view uses the rules in its config spec to select one of the versions. This is ClearCase's transparency feature — a view makes a VOB appears to be a standard directory tree to system software and third-party applications.

  • Private storage — Each view has its own data storage area, enabling you (and other users of the same view) to perform development work without interfering with users working in other views — even those working with the same source elements and building the same libraries and executables.

For each VOB, a view presents a coherent virtual workspace — a directory tree in which you see both VOB-resident objects (the selected versions of elements) and view-resident objects (typically, the source files you're revising and the derived objects produced by your builds in that view). In general, the VOB-resident objects are read-only; the view-resident objects are writable and removable. Figure 1-5 illustrates the virtual workspace.

Figure 1-5. View as a Virtual Workspace

When you (or your compiler) read a source file, you do not need to know whether you are accessing a version selected from VOB storage or a view-private file. Similarly, when you (or your linker) read an object module, you do not need to know whether you are accessing a shared (winked-in) binary from VOB storage or an unshared binary that was built in your view, and appears only in your view.

Standard and Extended Pathnames

Transparency enables you (and your makefiles, scripts, and other tools) to use standard pathnames to access ClearCase data. But you can also use extended pathnames — ClearCase extends the standard operating system file namespace both “upward” and “downward”.

View-Extended Pathnames

Typically most of your work involves just one view — you work in one or more processes that are “set” to that view. But you can also use other views that are active on your host, without having to “set” them. Instead, you can use a view-extended pathname. For example:


specifies the version of an element selected by your view


specifies the version of the same element selected by view bill


specifies the version of the same element selected by view v1.1_port

Conceptually, the viewroot directory is a “super-root” for your host's file system. Through the super-root, you can access any active view; and through a view, you can access any active VOB (Figure 1-6). Thus, the view-extended pathname extended the file namespace upward.

Figure 1-6. Viewroot Directory as Super-Root

VOB-Extended Pathnames

Each view selects only one object at a given pathname. Through your view, you will see a particular version of a source file — say msg.c. But the VOB also contains all other historical versions of the element, all of them potentially accessible through the file name msg.c. Similarly, your view sees a single derived object msg.o — the one produced when you compile msg.c using clearmake. But there may be other derived objects named msg.o in other views, built from different versions of msg.c, built using different header files, built using different command-line options, and so on.

ClearCase has a VOB-extended pathname scheme, which enables you to:

  • access any version of an element, no matter which version is selected by your view. You can also reference other components of an element's version tree: its branches, and the element itself (Figure 1-7a).

  • access any derived object, even if it is not the one produced by clearmake in your view (Figure 1-7b).

    Figure 1-7. VOB-Extended Pathnames

An element's version tree has the same hierarchical structure as a directory tree. This makes it natural to “embed” the entire version tree in the file system under the element's pathname:


standard name of an element (your view accesses a particular version through ClearCase's transparency feature)


extended pathname to the element object


extended pathname to the element's main branch


extended pathname to a subbranch of the main branch


extended pathname to a version on the subbranch

Note: These are also called version-extended pathnames, because they indicate locations within an element's version tree.

The VOB catalogs all derived objects built at a given pathname. They have unique IDs, which incorporate timestamps:


derived object built as msg.o on Nov 24 at 9:11 pm


derived object built as msg.o on Nov 25 at 7:31 am


derived object built as msg.o on Jan 12 at 9:59 pm

In both kinds of VOB-extended naming, think of the extended naming symbol (@@) as “turning off” transparency, allowing you to specify a particular object in the VOB database.

For a complete discussion of ClearCase's file-naming extensions, see the pathnames_ccase manual page.

Pathname Examples

This example in this section demonstrate how (and how well) ClearCase fits into a standard UNIX development environment. The examples involve both standard pathnames and extended pathnames, all processed by standard UNIX programs and by ClearCase commands:

  • Display the version of file msg.c selected by your view:

    % cat msg.c

  • Display the 5th version on the main branch of file msg.c:

    % cat msg.c@@/main/5

  • Display the most recent version on the main branch of file msg.c:

    % cat msg.c@@/main/LATEST

  • Compare your version of file msg.c with the version in a colleague's view:

    % diff msg.c /view/jjkim/vobs/design/src/msg.c

  • Compare your version of file msg.c with a particular historical version:

    % diff msg.c msg.c@@/main/5

  • Search for the string tmpbfr_sz in all the versions on the main branch of file msg.c:

    % grep 'tmpbfr_sz' msg.c@@/main/*

  • Repeat the preceding search in another way — by going to the main branch of msg.c, then entering the grep command:

    % cd msg.c@@/main
    % grep 'tmpbfr_sz' *

  • Search through an element's entire version tree for that same string:

    % find msg.c@@ -print -exec grep 'tmpbfr_sz' {} \;

The last two examples demonstrate that the embedding of version trees in the file namespace is “complete” — you can navigate elements, their branches, and their versions with standard operating system commands, just as if they were regular directories and files.

Modifying Elements - the Checkout/Checkin Model

This section describes the ways in which you “evolve” an element by adding new versions and branches to its version tree. Like many version-control systems, ClearCase uses a “checkout/checkin” model:

  1. Before you begin — In the “steady state”, an element is read-only — you can neither edit it nor remove it with standard operating system commands:

    % ls -l hello.c
    -r--r--r--   1 akp      user      168 May 13 19:30 hello.c

    What you are seeing is one version of the file element — the version selected by your view, according to the rules in its config spec. Typically, it is the most recent version on some branch of the element's version tree.

  2. Checkout — You issue a checkout command, naming the file. This produces an editable copy of the selected version

    % cleartool checkout -nc hello.c
    Checked out "hello.c" from version "/main/2".
    % ls -l hello.c
    -rw-rw-r--   1 sakai    user      168 May 19 19:31 hello.c

    The editable copy appears “in place”, at the same pathname as the element — there is no need to copy the file to another location in order to work on it. In Step #1, your view selected an “old” version of the file, located in VOB storage; now it selects your checked-out version, located in view-private storage.

    Note: The listings above hint at this: the element was created by another user, akp, who owns all its “old” versions. But the checked-out version belongs to the user who performs the checkout — in this example, sakai.

  3. Edit — You revise the contents of the file with any text editor.

    % vi hello.c

    ClearCase is integrated with the popular development-tool messaging systems, SoftBench and ToolTalk. You can use a text editor that works with either of these systems to work with your checked-out version.

  4. Checkin — When the file is correct (or, at least, worth preserving), you issue a checkin command. This adds a new version to the version tree (the successor to the version that was checked out), and removes the editable copy of the file. You can specify a comment during the checkin process, to help document the changes you made.

    % cleartool checkin hello.c
    Comment for all listed objects:
    replaced message
    Checked in "hello.c" version "/main/3".

    Canceling a Checkout Instead of Performing a Checkin — If you decide that you don't want to modify the file after all, you can cancel the checkout with an uncheckout command.

  5. After you end — After you checkin a new version, the file reverts to its “steady-state” read-only status:

    % ls -l hello.c
    -r--r--r--   1 akp      user      233 May 19 19:44 hello.c

    The checked-in version is placed in VOB storage, and immediately becomes shared data, available to all users. In particular, your view now selects this newly-created version. (Since you no longer have the file checked out, your view reverts to selecting a VOB-resident version.)

Reserved and Unreserved Checkouts

In some version-control systems (for example, SCCS), only one user at a time can reserve the right to create the next version on a branch. In other systems, many users can compete to create the same new version. ClearCase supports both models by allowing two kinds of checkouts, reserved and unreserved:

  • Only one view at a time can have a reserved checkout of a particular branch. A view with a reserved checkout has the exclusive, guaranteed right to extend the branch with a new version.

    After you perform the checkin, you no longer have any exclusive rights on that branch. Another user can now perform a reserved checkout to “grab” the right to create the next version on the branch.

  • Many views can have unreserved checkouts of the same branch. Each view gets its own private copy of the most recent version on the branch; each copy can be edited independently of all the others.

    An unreserved checkout does not guarantee the right to create a successor version. If several views have unreserved checkouts of the same branch in different views, the first user to perform a checkin “wins” — other users must merge the checked-in changes into their own work before they can perform a checkin. (See “Scenario: Merging an Unreserved Checkout”.)

By default, the checkout command performs a reserved checkout; use checkout –unreserved to perform an unreserved checkout. The reserve and unreserve commands change the state of a checkout. Figure 1-8 illustrates checked-out versions created by reserved and unreserved checkouts, along with the effect of subsequent checkins.

Figure 1-8. Resolution of Reserved and Unreserved Checkouts

Tracking Checked-Out Versions

In a multiuser environment, it is very likely that a given element will have several checkouts at the same time:

  • Several branches of the element may be under development; checkouts on different branches are mutually independent.

  • As described in “Reserved and Unreserved Checkouts” above, there can be multiple concurrent checkouts of a single version.

The lscheckout (“list checkouts”) command lists all the current checkouts of one or more elements:

% cleartool lscheckout -long sort.9

04-Mar-94.12:12:33     Allison K. Pak (akp.user@neon)
  checkout version "sort.9" from /main/37 (reserved)
  by view: "neon:/net/neon/home/akp/views/930825.vws"
26-Feb-94.08:59:02     Derek R. Philips (drp.user@saturn)
  checkout version "sort.9" from /main/gopher_port/8 (reserved)
  by view: saturn:/net/saturn/home/drp/mainvu.vws
  "incorporate david's comments"

Note: In the example for cleartool lscheckout the same element is checked out on different branches in diferent views.

Checked-Out Versions - Ownership and Accessibility

As the lscheckout listing above indicates, your checked-out version belongs both to you and to your view:

  • As the user who performed the checkout, you are the one who has permission to perform a corresponding checkin or uncheckout. (The root user also has permission, as does the owner of the element and the owner of the entire VOB.)

  • You are the owner of the standard UNIX file in view-private storage that is the checked-out version. This file is created according to your current umask(1) setting, in the standard UNIX manner. Standard mechanisms also control whether other users, working in the same view, can read or write the checked-out version.

  • A view can see only one object at a given pathname. Thus, ClearCase allows each view to have at most one checkout of a given element. If an element is to be checked out twice, on two different branches, then the checkouts must be performed in different views.

Users in other views do not see the checked-out version — they continue to see the version selected by their views' config specs. They can use the lscheckout command to determine that a checkout has been performed and, if permissions allow, they can use a view-extended pathname to access the checked-out version.

Checkout and Checkin as Events

The lscheckout command determines all of an element's checkouts by examining event records, which are stored in the VOB database of that element. Each checkout command creates a checkout version event record; lscheckout lists some or all such event records.

Similarly, the checkin command writes a create version event record to the appropriate VOB database. In general, every ClearCase operation that modifies a VOB creates an event record in the VOB's database, capturing the “who, what, when, where, why” of the operation: login name of the user who entered the command, kind of operation, date-time stamp, hostname, user-supplied comment.

You can use the lshistory command to display some or all of the event records for one or more elements:

% cleartool lshistory util.c
25-May-92.15:45:19     Allison K. Pak (akp.user@neptune)
  create version "util.c@@/main/3" (REL3)
  "special form of username message for root user
   merge in fix to time string bugfix branch"
25-May-92.15:44:05     Derek R. Philips (drp.user@saturn)
  create version "util.c@@/main/rel2_bugfix/1"
  "fix bug: extra NL in time string"
25-May-92.15:43:03     Derek R. Philips (drp.user@saturn)
  create version "util.c@@/main/rel2_bugfix/0"
25-May-92.15:43:03     Derek R. Philips (drp.user@saturn)
  create branch "util.c@@/main/rel2_bugfix"
25-May-92.14:46:21     Allison K. Pak (akp.user@neptune)
  create version "util.c@@/main/2"
  "shorten HOME string"

The chevent command can modify the comment string stored in an event record:

% cleartool chevent -replace util.c@@/main/2
Comments for "util.c":
shorten HOME string, to comply with
AMOK guidelines
Modified event of version "util.c".

Building and Testing Software

One of ClearCase's principal design points is compatibility with your existing software-build procedures. If you use makefiles to organize your build procedures, you can use the clearmake build utility, either directly or using the xclearcase front-end. If your build procedures are implemented as shell scripts or other programs, you can use the clearaudit build utility.

In many cases, you may find that adapting your day-to-day build habits to ClearCase involves little more than switching from ...

% make target-name 
... to ...
% clearmake target-name 

Behind the scenes, ClearCase manages the results of builds:

  • Newly-built files are cataloged as derived objects (DOs) in the appropriate VOB databases.

  • Configuration records (CRs) are also stored in VOB databases, to record exactly how each derived object was built. Like an event record, a CR contains “who, what, when, where” information. It also contains a “bill of materials” that shows how the file was built: versions of source elements used in the build, build options, makefile macros, build script, and more.

  • Based on a configuration-record analysis, clearmake may decide to wink-in an existing derived object (essentially, create a link to it) rather than executing a build script to create a new derived object.

All of this occurs automatically, though you can suppress features individually, using clearmake command-line options.

Using Build Management Structures

In some situations, you may find it useful to examine the structures ClearCase uses for build management. For example, you can use the lsdo command or the ClearCase variant of the ls command to see the unique identifiers with which derived objects are cataloged:

% cleartool ls hello.o
% cleartool lsdo hello.o
08-Mar.12:48   akp        "hello.o@@08-Mar.12:48.7261"
07-Jan.11:40   sakai      "hello.o@@07-Jan.11:40.2143"

Note: cleartool ls is done in your view and cleartool lsdo is all DO's built at that pathname in any view.

The catcr command displays the contents of the configuration record that documents the building of one or more derived objects:

% cleartool catcr hello.o
Target hello.o built on host "neptune" by akp.user
Reference Time 19-May-92.19:30:12, this audit started
View was neptune:/home/akp/akp.vws
Initial working directory was neptune:/usr/hw/src
MFS objects:
/usr/hw/src/hello.c@@/main/4 <19-May-92.19:30:05>
/usr/hw/src/hello.h@@/main/2 <19-May-92.19:30:07>
Build Script:
  cc -c hello.c

There is also a diffcr command, which you can use to compare two builds of the same target — that is, to compare the CRs of two derived objects built at the same pathname.

You can “grab” any existing derived object for use in your view, even if does not match your current configuration of source versions. That is, you can explicitly wink-in a derived object, even if clearmake wouldn't.

The Chapter 10, “Building with clearmake; Some Basic Pointers,” section of this manual discusses build-related issues in greater detail.

Debugging and Testing Software

The best environment for debugging and testing a software build is the view in which you performed it. All source versions that went into a build are visible in the view; likewise, all object modules (.o files) are visible.

ClearCase does not include any specific debugging tools. However, integrations with a third-party tools, such as Centerline's CodeCenter™, may be available for your platform.

Working in a Parallel Development Environment

ClearCase is designed for parallel development, wherein two or more projects can modify the same source files at the same time. The “standard” strategy for organizing the environment uses a baselevel-plus-changes model. Launching and pursuing a new development project involves the steps listed below. (You'll notice that most of the work is administrative.)

  1. An administrator defines a baselevel — a consistent set of source versions — by attaching the same version label to all the source versions — for example, RLS_2.1. The baselevel might be the set of versions that went into some product release; or it might just be a set of versions that yields a functional build of the software system.

  2. The administrator designates a particular branch for use by the development project — for example, branch eco78 for performing the fixes required for ECO #78 to Release 2.1

  3. The administrator publishes a config spec for use by all developers working on the project. This config spec represents the project's organization in terms of the chosen version label and branch (RLS_2.1 and eco78).

  4. You, the developer, create a view and configure it with the published config spec. (Alternatives: all developers share a single view with the proper configuration; the administrator creates the view(s), then tells developers to use them.)

  5. Working in the properly-configured view, you start modifying an element simply by entering a checkout command; the checkout automatically takes place on the designated branch, eco78; if the branch does not already exist, it is created at the version labeled RLS_2.1. After you build and test with your changes, your checkin command creates a new version on the designated branch.

Thus, after some initial setup, “working on a branch” involves nothing special; you just work according to the basic checkout-edit-checkin scheme described in “Modifying Elements - the Checkout/Checkin Model”. Your view takes care of organizing your work according to the administrator-mandated structure.

Comparing Versions of Elements

As you modify source files, you'll often want to perform comparisons:

  • What are all the changes I've made in my checked-out version?

  • How does my checked-out version differ from a particular historical version, or from the version being used by one of my colleagues?

ClearCase includes powerful tools for comparing two or more versions of an element. For example, Figure 1-9 shows how you might display the changes you've made in a source file.

Figure 1-9. Determining the Changes in a Checked-Out Version

To produce a similar display comparing your version of a file with a colleague's (say, the version that appears in view gordons_view), you might enter this command:

% cleartool xdiff base.h \

In addition to simply comparing versions, ClearCase can produce a line-by-line analysis of a version. The annotate command indicates when each line of a file was added, and by whom (Figure 1-10).

Figure 1-10. Annotated File Listing

Examining an Element's Version Tree

ClearCase includes both character-oriented and graphical tools for examining the version tree of an element. A graphical display, like that shown in Figure 1-11, is “live” — for example, you can select one or more versions with the mouse, then click an icon to bring up a window that compares those versions.

Figure 1-11. Graphical Version Tree Display

Merging Versions of Elements

Typically, an element's subbranches are thought of as “temporary”. One branch — usually the main branch — is conceived as holding the element's “official” or “permanent” contents. In this scheme, work performed on each subbranch must eventually be merged back into the main branch. You may wish to wait until a project is finished before merging its branches back into the main branch. Or you may wish to perform frequent merges, in order to keep the contents of the branches from diverging too much.

A typical merge combines the most recent version on a subbranch with the most recent version on the main branch (Figure 1-12). In a real-world environment, an element is also likely to be involved in other projects, taking place on one or more additional branches.

Figure 1-12. Merge of Subbranch Version into Main Branch

ClearCase makes merging as automatic as possible. A single findmerge command (“find, and then merge”) might merge all of a project's changes, made on a subbranch, back into the main branch:

% cd /vobs/proj    (go to project top-level source directory)
        (merge all work on subbranch back into 'main' branch)
% cleartool findmerge . -ftag eco_work_view -merge

For each merge it performs, ClearCase determines how each of the contributor versions have changed from the base version (in Figure 1-12, how contributor versions /main/5 and /main/eco78/2 have changed from the base version /main/3). Often, all such changes are mutually distinct, and a merged version is created completely automatically. If there are any conflicts between the changes, you can resolve them using the graphical merge tool (Figure 1-13) or a character-oriented tool.

Whenever you merge two versions of an element, ClearCase annotates the element's version tree with a merge arrow. (Figure 1-13 shows a merge arrow connecting version /main/eco78/2 to version /main/6.) These annotations make it possible to merge a project's changes a few files at a time, and to determine whether or not all required merges have been performed. Merge operations take into account any existing merge arrows involving the same branches; this makes frequent incremental merging both fast and simple.

Figure 1-13. Graphical Merge Tool

Working with Meta-Data

In addition to storing file system data (source files, shared derived objects) in its storage pools, a VOB stores associated meta-data in its database. As you perform your development tasks, ClearCase automatically creates and stores a variety of meta-data. For example, preceding sections of this chapter have described how:

  • ClearCase commands that modify a VOB (checkout, checkin, and others) write event records to document the change.

  • The clearmake build utility creates configuration records to document software builds.

  • Merge operations are documented by the creation of merge arrows.

In addition, meta-data annotations can be placed on objects explicitly. The most important example was discussed in “Working in a Parallel Development Environment” — an administrator attaches version label annotations to a set of source file versions, in order to define a baselevel.

In many organizations, defining and attaching meta-data annotations is an administrator's or project leader's task; as an individual developer, you most often use existing meta-data annotations, rather than explicitly creating them.

CASEVision/ClearCase User's Guide
(document number: 007-2369-001 / published: 1994-07-21)    table of contents  |  additional info  |  download

    Front Matter
    Chapter 1. Overview of ClearCase Usage
    Chapter 2. Using the ClearCase Command Line Interface
    Chapter 3. Using the ClearCase Graphical User Interface
    Chapter 4. Setting Up a View
    Chapter 5. Defining View Configurations
    Chapter 6. Working in a Parallel Development Environment
    Chapter 7. Comparing and Merging Files Graphically with xcleardiff
    Chapter 8. Using the ClearCase/SoftBench Integration
    Chapter 9. Using the ClearCase/ToolTalk Integration
    Chapter 10. Building with clearmake; Some Basic Pointers
    Chapter 11. Derived Objects and Configuration Records
    Chapter 12. Makefile Optimization
    Chapter 13. Setting Up a Distributed Build
    Chapter 14. Building Software for Multiple Architectures
    Chapter 15. Setting Up a Build on a Non-ClearCase Host
    Chapter 16. Adding a Timestamp to an Executable
    Chapter 17. Compatibility between clearmake and Other make Variants
    Chapter 18. Customizing the Graphical Interface
    Chapter 19. Type Managers and Customized Processing of File Elements
    Chapter 20. Using Triggers, Attributes, and Locks to Implement Development Policies
    Chapter 21. Using ClearCase to Organize and Implement Parallel Development

Home    •     What's New    •     Help    •     Terms of Use    •     Privacy Policy    •

© 2009 - 2015 Silicon Graphics International Corp. All Rights Reserved.