Administrator's Guide for Rational ClearCase LT, Release 2002.05.00, All Platforms

6.4 VOB Datatypes

From the user's standpoint, a VOB contains file system objects and metadata. Some metadata is stored in the form of objects; other metadata is stored as records or annotations attached to objects. This section describes VOB datatypes.

Some of these datatypes are created automatically by ClearCase commands. Others must be created explicitly by users or (more often) administrators. Users never access metadata directly. Instead, they use cleartool describe and various ClearCase GUIs, most of which can retrieve metadata whether or not they are run in a view context.

The VOB Object

Each VOB database contains a VOB object that represents the VOB itself. The VOB object provides a handle for certain operations. For example:

Listing event records of operations that affect the entire VOB (see the lshistory command). This includes creation and deletion of type objects, removal of elements, and so on.

Placing a lock on the entire VOB (see the lock command).

File System Objects

A VOB database keeps track of users' file system objects using the following database objects:

File element	An object with a version tree, consisting of branches and versions. Each version of a file element has file system data: a sequence of bytes. Certain element types constrain the nature of the versions' file system data; for example, versions of text_file elements must contain text lines, not binary data.
Directory element	An object with a version tree, consisting of branches and versions. Each version of a directory element catalogs a set of file elements, directory elements (subdirectories), and VOB symbolic links. An extra name for an element that is already entered in some other directory version is termed a VOB hard link.
VOB symbolic link	An object that contains a text string. On UNIX systems, this string is interpreted by standard commands in the same way as an operating system symbolic link.

Link Counts for UNIX File System Objects

Link counts for UNIX file system objects, which are required when accessing VOB objects in a view on a UNIX computer, are stored in the VOB database and are reported by the UNIX ls command as follows:

Symbolic link	1
File element	1
File version	1
Directory element	2
Directory version	2 plus number of directory elements cataloged in that version
Branch	2 plus number of subbranches (each branch appears as a subdirectory in the extended-namespace representation of an element's version tree)

This scheme satisfies two UNIX rules:

The link count is at least 1 for an object that has a name.

The link count of a directory is 2 + number-of-subdirectories.

The scheme does not satisfy the rule that the link count should be the number of names the object has in the current namespace.

Type Objects

A type object is a prototype for one or more instances of type objects stored in a VOB database. If a type object exists, a user can create an instance of it by entering the appropriate command (for example, cleartool mklabel to create an instance of a label type object).

A VOB can store several kinds of type objects:

Type	Mnemonic	Description
Element type	eltype	Instances are elements.
Branch type	brtype	Instances are branches.
Hyperlink type	hltype	Instances are VOB hyperlinks (used to connect pairs of objects).
Trigger type	trtype	Instances are triggers.

In addition, VOBs can store type objects that can only be used to modify instances of other type objects:

Type	Mnemonic	Description
Label type	lbtype	Instances are labels that can be attached to any version object.
Attribute type	attype	Instances are attributes (name/value pairs) that can be attached to any instance of a type object.

The mnemonic associated with each type object can be used in an object-selector prefix to cleartool commands like describe. For example, to describe a branch type named v4_patch, use the brtype mnemonic as shown here:

cleartool describe brtype:v4_patch

Instances of Type Objects

After a type object is created, users can create any number of instances of the type. Creating an instance of a type object creates a reference to the type object. For example, attaching version label BASELEVEL_4.2 to a particular version does not make a copy of the BASELEVEL_4.2 type object. Instead, it establishes a connection between the version object and the label type object.

This scheme makes it easy to administer type objects and their instances. For example, renaming the label type object from BASELEVEL_4.2 to BL4.2 renames all its existing instances.

NOTE: Creating an instance does not make a copy of the type object, but in certain cases it does create a new object. For example, the mkbranch command creates a new branch object and creates a reference connecting the new branch object to an existing branch type object.

Element	Each file or directory element in a VOB is created by mkelem or mkdir as an instance of an existing element type in that VOB.
Branch	Each branch in an element is created by mkbranch as an instance of an existing branch type in that element's VOB.
Version label	The mklabel command annotates a version with a version label, by creating an instance of an existing label type.
Attribute	The mkattr command annotates a version, branch, element, VOB symbolic link, or hyperlink with an attribute, by creating an instance of an existing attribute type. Each instance of an attribute has a particular value-a string, an integer, and so on.
Hyperlink	The mkhlink command creates a hyperlink object, which is an instance of an existing hyperlink type. A typical hyperlink connects two objects, in the same VOB or in different VOBs.
Trigger	The mktrigger command creates a trigger object, which is an instance of an existing trigger type. The trigger may be attached to one or more elements.

Predefined and User-Defined Type Objects

Each VOB is created with a set of predefined type objects. Users can create additional type objects as needed using the cleartool mkeltype command. The online help for mkeltype lists the predefined element types for the current release of ClearCase. You can also use the ClearCase Administrator Console or the cleartool lstype command to list the type objects defined in a given VOB.

Scope of Type Objects

Each VOB has its own set of type objects, for use in creating instances of the types in that particular VOB. ClearCase also provides a global type facility that you can use to increase the scope of a type object from a single VOB to a group of VOBs. For more information about using global types, see Chapter 8, Using Administrative VOBs and Global Types.

Changing an Element's Type

You can use chtype to convert an element from one element type to another (for example, from file to text_file). Typically, you change an element's type to change the way its versions are stored. For example, versions of a file element are stored in separate data containers in a VOB source pool. Converting the element to type text_file causes all its versions to be stored in a single data container, as a set of deltas (version-to-version differences); this saves disk space.

NOTE: All versions of an element must fit the new element type. For example, converting an element to type text_file fails if any of its versions contains binary data, rather than text. You cannot convert files to directories, and vice versa.

Event Records

Nearly every operation that modifies the VOB creates an event record in the VOB database. See the events_ccase reference page for more information.

The vob_scrubber utility deletes unneeded event records. By default, the scheduler runs vob_scrubber periodically. See the schedule reference page for information on describing and changing scheduled jobs.