TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Quick Review of ClearCase Concepts

ClearCase is a comprehensive software configuration management system. It manages multiple variants of evolving software systems, tracks which versions were used in software builds, performs builds of individual programs or entire releases according to user-defined version specifications, and enforces site-specific development policies.


ClearCase Data Structures

Figure 50 shows a development environment managed by ClearCase. At its heart is a permanent, secure, data repository. It contains data that is shared by all users: this includes current and historical versions of source files. In addition, the repository stores detailed "accounting" data on the development process itself: who created a particular version (and when, and why), what versions of sources went into a particular build and other relevant information. A VOB is a permanent data repository for data and meta-data (non-file-system information) for a development tree or subtree.

Figure 50 ClearCase Development Environment

Clearcase Views and Transparent Access

As Figure 50 illustrates, users access the ClearCase data repository through ClearCase views. A ClearCase view is a software development work environment that is similar to —— but greatly improves on —— a traditional "development sandbox". Each ClearCase view is a workspace containing selections of versions and providing management of derived objects. A ClearCase view allows access to versions of elements as if they were ordinary files using ordinary pathnames.

ClearCase 4.0 and higher includes two kinds of views:

ClearCase views need to be activated before they are used. Before bringing up Apex/ClearCase, you need to set the ClearCase view using the setview command. Please see the ClearCase User's Manual for more details.

ClearCase Version Control

ClearCase manages all software development objects: any kind of file. Versions of text files are stored efficiently as deltas, or incremental changes. Versions of non-text files are also stored efficiently, using data compression. Version control of directories enables the tracking of changes to the organization of the source code base, which are just as important as changes to the contents of individual files. Such changes include creation of new files, renaming of files, and even major source tree "cleanups".

ClearCase Versioned Object Bases (VOBs)

ClearCase development data is organized into any number of versioned object bases (VOBs). Each VOB provides permanent storage for all the historical versions of all the source objects in a particular directory tree. As seen through a ClearCase view, a VOB seems to be a standard directory tree —— the "right" versions of the development objects appear, and all the other versions are hidden.

A version-controlled object in a VOB is called an element; its versions are organized into a version tree structure with branches and subbranches. As Figure 51 shows, branches have user-defined names, typically chosen to indicate their role in the development process. All versions have integer ID numbers; important versions can be assigned version labels to indicate development milestones —— for example, a product release. Figure 51 illustrates the version label beta_version.

Figure 51 Version Tree of an Individual Element

VOBs need to be activated before they are used. The VOB needs to activated before Apex/ClearCase is started.

Elements, Branches, and Versions

Each VOB stores version-controlled file system objects, termed elements. An element is a file for which ClearCase maintains multiple versions. The versions of an element are logically organized into a hierarchical version tree, which can include multiple branches and subbranches. See Figure 51 for an example.

Version-IDs

Each version of an element has a unique version-ID, which indicates its location in the version tree. A version-ID takes the form of a branch-pathname followed by a version-number, for example, the shaded element in Figure 51 is:

Extended Namespace

ClearCase makes access to historical versions easy, by extending the standard file/directory namespace. In essence, the entire version tree of every element is embedded under its standard pathname. Most of the time, the version tree remains hidden; but special version-extended pathnames allow any program to access any (or all) of an element's versions. Figure 51 illustrates the version-extended name of test.txt@@/main/r1_bugs/bug404/1.

Controlling Directories

Apex/ClearCase supports controlling directories as well as files. Directory elements have version trees too. A directory must be checked out to change its contents, but it does not need to be checked out to change the contents of elements within it or to make view-private changes to the directory.

Links in VOBs

A VOB hard link is an additional name for an existing VOB element. A VOB hard link can be used anywhere an element can be specified. A VOB symbolic link is a separated, unversioned VOB object whose contents is a pathname. It cannot be checked out.

Magic Files

ClearCase determines one or more file types for an element. Each element type has an associated type manager, a suite of programs that handle the storage and retrieval of versions for storage pools. Users can define their own elements types to classify elements functionally.

A magic file is used by ClearCase to determine the type of an existing file or for the name of a new file. A magic file consists of an ordered set of file-typing rules. A user may also explicitly set the file type at creation.

Derived Objects

Generally speaking, many tools and commands consume files as input, and produce files as output. For instance, a compiler takes source files as input and generates object files (and in the case of the Apex compilers, other file artifacts as well).

ClearCase refers to these generated files as derived objects (DOs). ClearCase provides the ability to do an audited build, in which ClearCase monitors which source files are referenced by user commands to generate any given DO. The result is a configuration record (CR), a ClearCase object that describes all filesystem objects that were used to produce the DO (including source file versions, other DOs, view private files etc.). Configuration records are internal ClearCase objects which are not themselves visible to the user. However, you can display the contents of a configuration record using the cleartool cater command, and this report can serve as a bill of materials to document all filesystem objects that went into a particular build of an executable.

Note: A CR is created only within a dynamic view.

The other use of configuration records is to enable the sharing of derived objects. The action by which a view gains access to the DOs that were generated in another view is known as "winking in" the DO's. Derived object sharing conveys two benefits:

1 . Conservation of disk space. If each view has to provide storage for all of its DOs (for example, compilation artifiacts), this adds up to a lot of disk space. If DOs can be shared between views, then storage requirements are reduced.

2 . Optimization of builds. Winking in a DO from another view is faster than generating it in the local view from sources.

For more information, see:


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS