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 and ClearCase LT provide several type managers. On UNIX, users can create additional ones.
Several version-control methods for file elements are implemented in two phases:
For example, checking in a text_file element involves the following:
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.
Following are descriptions of the type managers:
To have a particular file element use a particular type manager, you must establish two connections as indicated:
You can automate the assignment of the new element type to newly created elements using the file-typing facility, driven by .magic files. For more information, see the cc.magic reference page.
A type manager uses different methods to manipulate ClearCase and ClearCase LT data. Methods are invoked at the appropriate time by a version-control command.
On UNIX, a type manager is a collection of programs in a subdirectory of ccase-home-dir /lib/mgrs; the subdirectory name is the name by which the type manager is specified with the –manager option in a mkeltype command. Each program in a type manager subdirectory implements one method (data-manipulation operation). A method can be a compiled program, a shell script, or a link to an executable. It is invoked at the appropriate time by a ClearCase or ClearCase LT version-control command.
A type manager can include the following methods, which are invoked by a command or server process:
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.
A type manager can use symbolic links to inherit one or more of its methods from another type manager. A typical use of symbolic links is to have individual methods be links to a master type manager program, which implements several (or all) of the methods. For an example, see directory ccase-home-dir/lib/mgrs/z_whole_copy.
A link to the cleardiff program can implement the compare and/or merge method for text files. Similarly, a link to the xcleardiff program can implement the xcompare and/or xmerge method. Again, see directory ccase-home-dir/lib/mgrs/z_whole_copy for an example.
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:
When a type manager is invoked by a ClearCase or ClearCase LT command, it scans through the map file, finds the matching type manager and method in the first and second fields, and 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 files, and are stored in the VOB's source pools, which are directories. Only type managers deal with data containers directly; users always manipulate data using the names of elements and UNIX links.
Performing the data manipulation for a version-control operation involves several programs. For example, when ClearCase or ClearCase LT create 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).
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):
type-mrg-id is a one-, two-, or three-character string. One-character values correspond to the predefined 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.
Names of user-defined type managers must not begin with underscore.
Copyright© 2003 Rational Software. All Rights Reserved.