Program for managing contents of element versions
ClearCase (data structure)
annotate, compare, construct_version, create_branch, create_element, create_version,
delete_branches_versions, get_cont_info, merge, xcompare, xmerge
A type manager is a suite of programs that manipulates files with a particular data format; different type managers process files with different formats. A directory type manager provides programs that compare and/or merge versions of directory elements. ClearCase provides several type managers.
Several ClearCase version-control commands for file elements are implemented in two phases:
For example, checking in a text_file element involves:
For a different type of element-for example, a bitmap file-the delta is computed differently, or not at all, and so requires a different type manager.
These are the ClearCase type managers:
Stores any data. Stores a whole copy of each version in a separate data container file.
Stores any data. Stores each version in a separate, compressed data container file using the gzip compression program.
Note that compressed files generally take more time to check in (because they must be compressed), and reconstruct when first accessed (first cleartext fetch).
Stores text files only (including those with multibyte text characters). Stores all versions in a single structured data container file. Uses incremental file differences to reconstruct individual versions on the fly.
Stores text files only. Stores all versions in a single structured data container file, in compressed format using both the gzip compression program and deltas.
Stores any data. Stores each branch's versions in a separate, structured compressed data container file using gzip. Uses incremental file differences to reconstruct individual versions on the fly. Version deltas are determined by comparing files on a per-byte basis.
Stores HTML source. Stores information and reconstructs versions in the same way as the text_file_delta manager from which it is derived. Has its own compare, xcompare, merge and xmerge methods.
Stores Microsoft Word documents. Stores information and reconstructs versions in the same way as the z_whole_copy manager from which it is derived. On Windows, has its own xcompare and xmerge methods.
Stores Rational Rose artifacts. Stores information and reconstructs versions in the same way as the text_file_delta manager from which it is derived. On Windows, has its own compare, xcompare, merge, and xmerge methods for which it invokes a tool specialized for Rose files.
Stores XML source. Stores information and reconstructs versions in the same way as the text_file_delta manager from which it is derived. On Windows, has its own compare, xcompare, merge, and xmerge methods for which it invokes a tool specialized for XML files.
Not involved in storing/retrieving directory versions, which reside in the VOB database, not in a source storage pool. This type manager compares and merges versions of the same directory element.
To have a particular file element use a particular type manager, you must establish two connections:
type manager <---- element type <---- file element
You can automate the assignment of the new element type to newly created elements using the ClearCase file-typing facility, driven by .magic files. See the cc.magic reference page for details.
A type manager uses different methods to manipulate ClearCase data. Each method is carried out by a shell script, an executable, or a subroutine inside an executable. Methods are invoked at the appropriate time by a ClearCase version-control command.
A type manager can include these methods:
Invoked by mkelem to create an element's initial data container.
Invoked by mkbranch to create a branch in an element's version tree.
Invoked by checkin to store a new version of an element.
Invoked by annotate to produce an annotated listing of a version's contents.
Invoked by a view's view_server process when a file element is opened, from versions stored in delta or compressed format. This method constructs a readable, cleartext copy of a particular version.
After the cleartext version is constructed, its line terminators may be adjusted by the view_server, according to the view's text mode. See Text Files, Cleartext, and a View's Text Mode in the mkeltype reference page, and also mkview.
Invoked by diff to run a file-comparison program that is specific to the element's data format.
Invoked by merge to run a file-merge program that is specific to the element's data format.
A type manager need not implement every method. For example, a type manager for bitmap graphics images may omit the merge method, because the operation doesn't make sense for that file format. In this case, the command cleartool merge produces an error when invoked on an element that uses this type manager.
The map file, located in the ccase-home-dir\lib\mgrs directory, associates type manager methods with the programs that carry them out. A map file entry has three fields: type manager, method, and program. Below are some example entries from the map file:
|Type Manager||Method||Implementing Program|
When a type manager is invoked by a ClearCase command, it scans through the map file, finds the matching type manager and method in the first and second fields, then runs the program specified in the third field. Note that the entry in the third field must be either a pathname relative to ccase-home-dir\lib\mgrs; for example, ..\..\bin\cleardiff.exe, a Windows Registry key under HKEY_LOCAL_MACHINE that points to an absolute pathname, or an absolute pathname.
Type managers process data containers, each of which stores the actual data for one or more versions of some element. (Although growth may cause a container to split, versions never span container boundaries.) All data containers are standard Windows files, and are stored in the VOB's source pools, which are standard Windows directories. Only type managers deal with data containers directly; users always manipulate data using the names of elements.
Performing the data manipulation for a version-control operation involves several programs. For example, when ClearCase creates a new version of an element:
NOTE: Even with a type manager that implements deltas, a new data container is created each time a new version is created. In this case, the old container (which may have stored 27 versions) is replaced by the new container (which stores 28 versions). A type manager must never write to an old container or delete a old container (it usually does not have rights to do so).
Source Pool Data Container Names
A container leaf name includes a type manager ID to aid checkvob in salvaging nonreferenced containers. Here is the format of a source pool data container name (in s\sdft, for example): .\nn\nn\type-mgr-id-orig-oid-str-xx
type-mrg-id is a one-, two-, or three-character string. One-character values correspond to the predefined ClearCase type managers. Two-digit values correspond to type managers with names that begin with underscore (_), and three-digit values are computed by hashing user-defined type manager names.
NOTE: Names of user-defined type managers must not begin with underscore.
mkelem, mkeltype, cc.magic, gzip
Feedback on the documentation in this site? We welcome any comments!
Copyright © 1999 by Rational Software Corporation. All rights reserved.