See audited build executor.
A VOB becomes active on a host when it is mounted as a file system of type MVFS. A view becomes active on a host when it is started, which establishes a connection between the host's MVFS file system and the view's view_server process.
Part of the xcleardiff display, showing how lines of one file differ from lines of other files, with which it is being compared or merged.
A word or quoted set of words processed by a command.
See trigger inheritance.
A meta-data annotation attached to an object, in the form of a name/value pair. Names of attributes are specified by user-defined attribute types; values of these attributes can be set by users.
Example: a project administrator creates an attribute type whose name is QAed. A user then attaches the attribute QAed with the value "Yes" to versions of several file elements.
See attribute, attribute type.
An object that defines an attribute name for use within a VOB. It constrains the attribute values that can be paired with the attribute name (for example, integer in the range 1–10).
See attribute type.
A process invoked through the UNIX remote-shell facility, in order to execute one or more build scripts on behalf of a remote clearmake.
See build audit.
ClearCase's facility, specified in a config spec rule, for automatically creating one or more branches when a checkout is performed.
See contributor.
See hyperlink.
Files that store bitmaps for the icons displayed by ClearCase GUI programs.
See build options specification.
An object that specifies a linear sequence of versions of an element. The entire set of versions of an element is called a version tree; it always has a single main branch, and may also have subbranches. Each branch is an instance of a branch type object.
See branch type.
A sequence of branch names, starting with /main (the name of an element's starting branch). Example: /main/motif, /main/maintenance/bug459.
An object that defines a branch name for use within a VOB.
An H-P SoftBench program that passes messages among SoftBench applications.
The process of invoking clearmake or clearaudit to produce one or more derived objects. This may or may not involve actual translation of source files and construction of binary files by compilers, linkers, text formatters, and so on. A system build consists of a combination of actual target rebuilds and build avoidance (reuse of existing derived objects)
In a target rebuild, clearmake executes the build script associated with a particular target in a makefile. Each target rebuild produces derived objects along with a configuration record, which includes an audit of the files involved in the actual target rebuild.
In build avoidance, clearmake “produces” a derived object either by reusing the one currently in the view, or by winking-in one that exists in another view. The process by which clearmake decides how to produce a derived object is called configuration lookup.
The process of recording which files and directories (and which versions of them) are accessed (read or written) by the operating system during the execution of one or more programs. A client host's MVFS file system performs an audit during execution of a ClearCase build program: clearmake, clearaudit, or abe. When the build audit ends, the build program creates one or more configuration records (CRs).
An audited shell is a UNIX shell process in which all file system accesses are audited. Such a shell is created by clearaudit.
See build.
See configuration lookup.
See dependency.
A host used to execute build scripts during a distributed build.
A file that lists hosts to be used in a distributed build. The file is selected at build time by macro or environment variable clearcase_bld_host_type.
The ability of clearmake to fulfill a build request by using an existing derived object, instead of creating a new derived object by executing a build script.
A file containing rules that specify settings of make macros, which affect the way in which a target rebuild proceeds.
The moment at which a top-level build session (invocation of clearmake) begins. Versions created after this moment may be “frozen out” of the build.
The set of shell commands that clearmake (or standard UNIX make) reads from a makefile when building a particular target.
A host used in a clearmake distributed build.
A file on a build host that controls its availability as a build server.
A top-level invocation of clearmake; during the session, recursive invocations of clearmake or clearaudit may start subsessions.
A word, typically the name of an object module or program, that can be used as an argument in a clearmake command. The target must appear in a makefile, where it is associated with one or more build scripts.
Build rules defined in a system-supplied (or ClearCase-supplied) file, which supplement the explicit build rules in a user's makefile (s).
The taking away of a ClearCase license from a lower-priority user by a higher-priority user.
A derived object that is being considered for wink-in or reuse during configuration lookup.
Names of elements and VOB symbolic links that appear in a version of a directory element are said to be cataloged in the directory version. A derived object is said to be cataloged (and, hence, available for reuse and wink-in) in a particular VOB.
A “placeholder” object in a VOB database, created by the checkout command. This object corresponds to the view-private file that the user edits after checking out the element. The checked-out version of a directory element exists only in the VOB database — there is no view-private component.
The two-part process that extends a branch of an element's version tree with a new version. The first part of the process, checkout, expresses the user's intent to create a new version at the current end of a particular branch. (This is sometimes called “checking out a branch”.) The second part, checkin, completes the process by creating the new version.
For file elements, the checkout process creates an editable version of the file in the view, with the same contents as the version at the end of the branch. Typically, a user edits this file, then checks it back in.
For directory elements, the checkout process allows file elements, (sub)directory elements, and VOB symbolic links to be created, renamed, moved, and deleted.
Performing a checkout of a branch does not necessarily guarantee the user the right to perform a subsequent checkin. Many users can checkout the same branch, as long as the users are in different views. At most one of these can be a reserved checkout, which guarantees the user's right to checkin a new version. An unreserved checkout affords no such guarantee. If several users have unreserved checkouts on the same branch in different views, the first user to perform a checkin “wins” — another user must perform a merge if he wishes to save his checked-out version.
The event record created by the checkout command.
An ASCII text file that contains a whole copy of some version of an element, having been extracted from a data container that is in compressed format or delta format. A ClearCase type manager creates a cleartext container the first time it accesses the version. Subsequent reads of that version access the cleartext file, for faster access.
A VOB storage pool, used for data containers that contain cleartext.
ClearCase's command-line interface.
The programs invoked by users: cleartool, xclearcase, clearmake, cleardiff, and other programs located in the ClearCase bin directory.
The discrepancies among the system clocks of several hosts.
In the command-line interface (CLI), a word beginning with a hyphen (–) that affects the meaning of a command; in the graphical user interface (GUI), a setting in the “Options” part of a panel.
The action taken by a cleartool command when the user does not specify a comment-related option.
A clearmake execution mode, in which it emulates another make variant.
The ClearCase element type that uses data compression on individual versions.
The ClearCase element type that uses both delta management and data compression on individual versions.
The information recorded in a derived object's CR: versions of source files used to build the object, build script, build options, and so on.
A set of rules, specifying which versions of elements are to be selected by a view. Each config spec rule selects a particular version of one or more elements.
The default ClearCase config spec is:
element * CHECKEDOUT
element * /main/LATEST
See scope, pattern, version-selector.
The set of versions (one version of each element) selected by a view's config spec.
The process by which clearmake determines whether to produce a derived object by performing a target rebuild (executing a build script) or by reusing an existing instance of the derived object. This involves comparing the configuration records of existing derived objects with the build configuration of the current view: its set of source versions, the current build script that would be executed, and the current build options.
The discipline of tracking the individual objects and collections of objects (and the versions thereof) that are used to build systems.
A listing produced by a target rebuild, logically included in each derived object created during the rebuild. A configuration record indicates exactly which file system objects (and which specific versions of those objects) were used by the rebuild as input data or as executable programs, and which files were created as output. It also contains other aspects of the build configuration.
Each target rebuild typically involves the execution of a single build script, and creates a single configuration record. If a target has subtargets that must be rebuilt, also, a separate configuration record is created for each subtarget rebuild.
A tree structure of configuration records, which mirrors the hierarchical structure of targets in the makefile.
See config spec.
See config spec.
See data container.
See view context.
One of the files or versions that supplies input to a merge. One of them is the base contributor — the merge algorithm compares each other contributor with the base contributor.
A shell script by one of the ClearCase file-conversion programs — for example, clearcvt_rcs.
See configuration record.
A hyperlink that connects two objects in different VOBs. The hyperlink always appears in a describe listing of the “from” object. It also appears in a listing of the “to” object, unless it was created as a unidirectional hyperlink (mkhlink -unidir). See same-VOB hyperlink.
The context in which relative pathnames are resolved by the operating system. This can be a location in ClearCase's extended namespace.
A file (or directory) that contains the data produced by a build script. A data container and a configuration record are the essential constituents of a derived object.
See config spec.
A derived object that cannot be successfully processed, because it data container and/or associated configuration record are not available.
The incremental difference (or set of differences) between two versions of a file element. Certain type managers (for example, text_file_delta), store all versions of an element in a single data container, as a series of deltas.
(same as for standard UNIX make) In a makefile, a word listed after the colon (:) on the same line as a target. A source dependency of a target is a file whose version-ID is taken into account in a configuration lookup of the target. A build dependency is a derived object that must be built before the target is built.
A file produced by a clearmake build or a clearaudit session. Each derived object is associated with a configuration record produced by clearmake during the build.
A storage pool for the data containers of a VOB's derived objects. Only those derived objects that are shared by two or more views are stored in these pools — data containers of unshared derived objects are stored in view-private storage.
The first time a derived object is winked-in to a view, the promote_server program copies the data from the original view, creating a data container in a derived object pool. Different pools for the same VOB can be located on different disks, or on different machines in the local area network.
The removal of data containers from derived object pools, and of derived objects themselves from a VOB database. Periodically, ClearCase automatically scrubs derived objects that are not referenced in any view.
The ClearCase feature wherein several views can simultaneously use the same derived object, through a mechanism resembling a UNIX hard link. See wink-in.
See DO version.
A subwindow in an xcleardiff window that shows the contents of one of the files being compared or merged.
A set of lines in a difference pane, or in cleardiff output, that differs among the files being compared or merged.
An element whose versions are like UNIX directories — they catalog the names of file elements, other directory elements, and VOB symbolic links.
A version of a a directory element.
See parallel build.
See derived object.
A derived object that has been checked in as a version of an element.
A unique identifier for a derived object, including a time stamp and a numeric suffix to guarantee uniqueness. Example: the characters beginning with “@@” in hello.o@@12-May.19:15.232.
The Domain Software Engineering Environment.
Invisible, because another object with the same name is currently selected by the current view.
An object that encompasses a set of versions, organized into a version tree.
A class of versioned objects. ClearCase supports predefined element types (for example, file, text_file). Users can define additional types (for example, c_source_file) that are refinements of the predefined types. When an element is created, it is assigned one of the currently-defined element types.
Each user-defined element type is implemented as a separate VOB object, created by a user command.
The wildcard symbol “...”. In a version-selector, it indicates zero or more directory levels.
A program that packages the functionality of an external software system.
A ClearCase operation that is recorded by an event record in a VOB's event history.
An item in a VOB database that contains information about an operation that modified that VOB.
A view used to export a VOB to a non-ClearCase acess host.
ClearCase's extension of the standard UNIX pathname hierarchy. Each host has a view-extended namespace, allowing a pathname to access VOB data using any view that is active on that host. Each VOB has a VOB-extended namespace, allowing a pathname to access any version of any element, independently of (and overriding) version-selection by views. Derived objects also have extended pathnames, which include DO-IDs. See namespace.
A symbol (by default, @@) appended to an element name or derived object name, signaling the MVFS file system to bypass automatic version-selection by a view.
A VOB-extended pathname specifies a particular location in an element's version tree, or a particular derived object cataloged in that VOB. If the pathname specifies a particular version, is termed a version-extended pathname. Examples:
foo.c@@/main/17
/usr/myproduct/bin/xtract@@/RELEASE_1
/usr/myproduct@@/main/bug403/5
A view-extended pathname accesses a file system object in the context of a specified view. For an element, such a pathname specifies the version of the element selected by that view's config spec; for a view-private file or derived object, such a pathname accesses an object in the view's private storage area. Examples:
/view/akp/usr/project/foo.c
/view/archive/usr/project/foo
/view/bugfix/usr/project/to_do.list
The identifier returned by ClearCase file typing subsystem, through a lookup in ClearCase-supplied and/or user-supplied magic files. File types are used to select an element type for a new element; they are also used by ClearCase GUI programs to select display icons.
See file system data.
See element.
See pattern.
The set of element versions selected by a view.
The bytes stored in a version of a file element. A file's contents are distinguished from its meta-data (attributes, hyperlinks, and so on).
The process by which ClearCase verifies that the conditions defined in a trigger are satisfied, and causes the associated trigger action(s) to be performed.
A non-hierarchical listing, combining information from a collection of configuration records.
See hyperlink.
A string-valued attribute attached to a hyperlink object, conceptually at its “from” end.
A standard operating system pathname beginning with “/”. For example, /usr/project/foo.c is a full pathname, but /view/akp/usr/project/foo.c is a view-extended pathname.
A file produced by the SCCS get command.
A trigger type that is automatically associated with all elements in a VOB.
A network-wide pathname for a ClearCase view storage directory or VOB storage directory. Some “global” pathnames are valid only within a particular network region.
A make variant distributed by the Free Software Foundation.
An additional name for a file system object, cataloged in the same directory or in a different directory. UNIX hard links are cataloged in standard UNIX directories; VOB hard links are cataloged in versions of directory elements.
A source file whose contents are included in a program with an #include statement.
Meta-data in a VOB, consisting of event records involving that VOB's objects. The history of a file element includes the creation event of the element itself, the creation event of each
version of the file, the creation event of each branch, the assignment of attributes to the element and/or its versions, the attaching of hyperlinks to the element and/or its versions, and so on.
The state of a process whose current working directory is in the ClearCase VOB-extended namespace (for example, hello.c@@/main).
A logical pointer between two objects. A hyperlink is implemented as a VOB object; it derives its name by referencing another VOB object, a hyperlink type. A hyperlink can have a from-string and/or to-string, which are implemented as string-valued attributes on the hyperlink object.
An xclearcase panel that enables a user to traverse hyperlinks.
A system-generated identifier that, in conjunction with the name of the hyperlink type, uniquely identifies a hyperlink object. Example: @391@/usr/hw.
An object that defines a hyperlink name for use within a VOB.
A string that specifies a particular hyperlink. It consists of the name of a hyperlink type object, followed by a (possibly abbreviated) hyperlink-ID. Examples:
DesignFor@391@/usr/hw
A small picture used by ClearCase GUI programs.
A file containing rules that map ClearCase file types to names of bitmap files.
A list of type objects, defining the scope of a trigger type.
See trigger inheritance.
A host of which ClearCase has been (or is about to be) installed.
The mode of cleartool usage in which the program prompts you (with cleartool>) to enter a command, executes the command, then prompts you to enter another one. See single-command mode.
A type object that defines a version label for use within a VOB.
The simple file name at the end of a multiple-component pathname.
Permission for one user to run ClearCase programs and/or use ClearCase data, using any number of hosts in the local area network.
A file that defines a set of ClearCase licenses.
A “slot” in the scheme by which some ClearCase users can bump others, taking their licenses.
A host whose albd_server process controls access to the licenses defined in its license database file.
The text string that is the contents of a UNIX-level symbolic link or a VOB symbolic link.
The ClearCase facility for intelligently managing a distributed build, so as not to overload individual hosts.
A mechanism that prevents a VOB object from being modified (for file system objects) or unreferenceable (for type objects). See obsolete.
A symbol that specifies a Boolean arithmetic operation.
A subdirectory of a VOB's top-level directory, to which elements are moved if they are no longer cataloged in any version of any directory element. See orphaned element. There is also a lost+found directory at the top level of a view storage directory.
A file used by the ClearCase file typing subsystem to determine the type of an existing file, or for the name of a new file.
The starting branch of an element's version tree. The default name for this branch is main.
A parameter in a makefile, which can be assigned a string value within the makefile itself, in a build options spec, on the clearmake command line, or by assuming the value of an environment variable.
A text file, read by clearmake, that associates build scripts, consisting of shell commands (“executable commands”), with targets. Typically, executing a build script produces one or more derived objects.
Makefiles constructed for clearmake need not include source-level dependencies (for example, header file dependencies), but they must include build-order dependencies (for example, that executable program hello is built using object module hello.o.
See dependency.
The script, created by one of the ClearCase conversion utilities, that is explicitly executed by the user to perform the data conversion.
The combining of the contents of two or more files into a single new file. Typically, all the files involved are versions of a single file element. This process may be completely automated or may require the user to resolve conflicting changes. The merge can be recorded with a merge arrow, which is implemented as a hyperlink of type Merge.
Data associated with an object, supplementing the object's file system data. Example: The contents of a file version is a series of text characters. User-specified meta-data annotations attached to the file version includes version labels, attributes, and hyperlinks. ClearCase automatically maintains other meta-data for some objects, in the form of event records and configuration records.
A program that implements one of the functions of a type manager.
An event whose event record is, by default, not listed by the lshistory command.
A directory tree which, when activated (mounted as a file system of type MVFS) implements a ClearCase VOB. To standard UNIX commands, a VOB appears to contain a directory hierarchy; ClearCase commands can also access the VOB's meta-data.
MVFS file system also refers to the multiversion file system, a virtual file system extension that is linked with the UNIX kernel, providing access to VOB data.
A file or directory whose pathname is within a VOB (that is, whose pathname is within the directory tree beneath the top-level VOB-tag. A non-MVFS object has a pathname that is not within a VOB.
A file/directory name hierarchy. Different views can “see” different namespaces, because they can select different versions of directory elements. See extended namespace.
A logical subset of a local area network, within which all hosts refer to VOB storage directories and view storage directories with the same network pathnames.
The username sometimes assigned to a remote process owned by the root user on the local host.
Access to ClearCase data from a host on which ClearCase has not been installed.
See MVFS object.
One of the message-passing programs in an H-P SoftBench environment.
A hyperlink that is connected to only one object, not two.
An item stored in a versioned object base (VOB). This includes elements, versions of elements, branches, derived objects, hyperlinks, locks, pools, and types.
A ClearCase-internal identifier for an object. See UUID.
An object that has been locked with the lock –obsolete. By default, such objects are not listed by commands such as lstype and lslock.
An element that is no longer cataloged in any version of any directory. Such elements are moved to the lost+found directory.
The user who owns a VOB, a view, or an individual file system object. The user who creates an item becomes its initial owner.
A build process in which multiple build scripts are executed concurrently. In a distributed build, execution takes place on multiple hosts in a local area network.
The concurrent creation of versions on two or more branches of an element.
A sequence of directory names, perhaps ending with a simple filename. A pathname that begins with “/”, indicating the root directory, is termed a full pathname. Any other pathname is termed a relative pathname. See extended pathname, namespace.
A character string that specifies one or more file and/or directory names. Examples:
/usr/project/.../include
*.c
lib/*.[ch]
See scope, version selector, config spec.
Ability to perform an operation that modifies a VOB or a file system object.
The feature by which a newly-created element is assigned to the same VOB storage pools as its parent directory element.
A trigger that fires after the associated operation.
A version of an element that immediately precedes another version in the element's version tree.X is the predecessor of version Y, then Y is the successor of X. If there is a chain of predecessors linking two versions, one is called an ancestor of the other.
A trigger that fires before the associated operation, possibly cancelling the operation itself.
The group to which a user belongs, by virtue of being listed in the password database. A user can belong to additional groups, as well.
The directory tree (.s) in which view-private files, directories, and links are stored. By default, this is a subtree of the view storage directory, but ClearCase supports creation of remote private storage areas.
See public VOB-tag.
Migration of a derived object from view storage (private) to VOB storage (shared).
If a VOB's VOB-tag is public, it is mounted automatically at system startup, and it can be mounted or unmounted by any user. If a VOB's VOB-tag is private, only the VOB's owner can mount the VOB. See VOB-tag password file.
A collection of predicates and logical operators that allows selection of elements, branches, and versions based on their associated meta-data. This language can be used in config specs, in the ClearCase find command, and in the –version option to many commands.
The Revision Control System.
See event record, configuration record.
The number of references to a derived object, in multiple views and, perhaps, several times in the same view (through UNIX hard links).
See build reference time.
See supertype.
A pathname that does not begin with “/”.
The host on which the ClearCase software is unloaded from the distribution medium.
For a checked-out version, either “reserved” or “unreserved”. The reserve and unreserve commands change the reserve state of a checked-out file.
See checkout.
A specification of which kinds of objects are to be associated with a trigger type.
clearmake is said to reuse a derived object if the object already exists in a view and a build leaves it alone.
The privileged “superuser” on a host.
A hyperlink that connects two objects in the same VOB.
The format of a database.
A file that contains a collection of X Window System resources, which control various aspects of GUI applications.
The part of a config spec rule that restricts it to a particular kind of file system objects. See config spec, pattern, version selector.
Discarding of data container files from cleartext pools and derived object pools, performed by scrubber(1MA).
See selection expression.
An expression used by ClearCase's file typing mechanism to match a file system object (or just the name of one). The expression consists of selection operators and logical operators.
(noun) The view context of a process, established by using the setview command. “Setting a view” creates a process in which all standard pathnames are resolved in the context of a particular view. See working directory view.
A file in which SCCS stores all versions of a versioned file.
A derived object that is referenced by multiple views, and whose data container has migrated to a VOB's derived object storage pool.
A derived object created by the same build script as another derived object. When clearmake reuses (or winks in) a derived object, it always reuses (or winks in) all of its siblings, too.
The mode of cleartool usage in which you specify the (sub)command, options, and arguments on the shell command line, along with “cleartool”. After executing that one (sub)command, cleartool exits and control returns to the shell.
An interprocess messaging system.
See version control.
See dependency.
A storage pool for the data containers that store versions of file elements.
A source pool, derived object pool, or cleartext pool.
A network-wide database, which records the actual storage locations of all VOB storage directories and all view storage directories.
A derived object that cannot be accessed, because the VOB directory (or the entire VOB) in which it was created is not currently accessible, or has been deleted.
A build session that was started while a higher-level build session was active.
In a hierarchical build, a makefile target upon which a higher level target depends. Subtargets must be built (or reused, or winked-in) before higher-level targets.
A branch of an element's version tree other than the main branch.
See predecessor version.
An element type that is used as the basis for defining another element type (said to be a refinement of the supertype).
A network-wide database, which records the globally-valid access paths to all VOB storage directories (or all view storage directories), along with the VOB-tags (or view-tags) with which users access these data structures.
See build.
The ClearCase element type that uses delta management to combine all versions of an element into a single data container. The associated type manager is named text_file_delta.
A hyperlink for which there is no “to” object, only a text annotation on the “from” object.
A separate config spec rule that specifies a time to which the special version label LATEST should evaluate in all subsequent rules; or, a clause that sets the LATEST time within an individual rule,
See hyperlink.
A string-valued attribute attached to a hyperlink object, conceptually at its “from” end.
An interprocess messaging system.
A scrollable subwindow in which a ClearCase GUI program displays output.
The ClearCase feature that enables standard programs to access versioned files and directories using standard pathnames.
A “monitor” that specifies one or more standard programs or built-in actions to be executed automatically whenever a certain ClearCase operation is performed.
See pre-operation trigger, post-operation trigger, trigger type.
The process by which triggers in the inheritance list of a directory element are automatically attached to new elements created within the directory.
An object through which triggers are defined. Instances of a “element” trigger type can be attach to one or more individual elements (“attached trigger”). A “global element” trigger type is implicitly attached to all elements in a VOB. A “type” trigger type is attached to a specified collection of type objects.
A type object defines a ClearCase data structure. Users can create instances of these structures: meta-data annotations are placed on objects by creating instances of label types, attribute types, and hyperlink types. The structure of the version tree of a file or directory is defined by creating an instance of an element type, along with instances of branch types. Triggers are defined as instances of trigger types.
A set of routines (methods) that stores and retrieves versions of file elements from disk storage. Some type managers include methods for other operations, such as comparison, merging, and annotation,
A trigger type that is associated with (and thus, monitors changes to) one or more type objects.
The act of cancelling a checkout operation.
See hyperlink.
See UUID.
See storage registry.
See checkout.
A derived object that has never been winked-in to another view.
A file that stores a user's individual specifications for cleartool comment handling.
A universal unique identifier, which ClearCase uses to track VOBs, vies, and the objects they contain.
An object that implements a particular revision of an element. The versions of an element are organized into a version tree structure. Also: the view-private file that corresponds to the checked-out version object created in a VOB database by the checkout command.
The original version on a branch. It is automatically created when the branch is created, and has the same contents as the version at the branch point. Version 0 on the main branch is defined to be empty.
The discipline of tracking the version evolution of a file or directory.
See extended namespace.
A pathname that explicitly specifies a version of an element (or versions of several elements), rather than allowing the version-selection to be performed automatically by a view.
A branch pathname and version number, indicating a version's exact location in its version tree:
/main/4
/main/rel2_bugfix/2
/main/bugs/bug405/9
An instance of a label type object, supplying a user-defined name for a version.
The ClearCase-assigned integer that identifies the position of a version on its branch.
The process of choosing one version from an element's entire version tree. A ClearCase view performs automatic version selection, using its config spec. Users can select versions with version-extended pathnames and with the ClearCase query language.
A command-line option, a part of a config spec rule, or a portion of a version-extended pathname, specifying the version of one or more elements to be used. See scope, pattern, and configuration specification.
The hierarchical structure in which all the versions of an element are (logically) organized. When displaying a version tree, ClearCase also shows merge operations (indicated by gray arrows in the illustration)
See VOB-extended namespace.
A repository that stores versions of file elements, directory elements, derived objects, and meta-data associated with these objects. A view makes a VOB appear to be a standard directory tree.
A ClearCase data structure which provides a virtual workspace for one or more users — to edit source versions, compile them into object modules, format them into documents, and so on. Users in different views can work with the same files without interfering with each other. For each element in a VOB, a view uses its config spec to select just one version from its version tree. Each view can also store view-private objects, which are do not appear in other views.
The view (if any) which will be used to resolve a pathname to a particular version of an element.
The database within a view storage directory, which the associated view_server process uses to track objects in the view's private storage area.
See extended namespace.
A pathname that begins with a view prefix (for example, /view/alpha), specifying a particular view to be used for resolving element names to particular versions.
An object stored in a view: a checked-out version of a file, an unshared derived object, or a view-private file, directory, or link. No historical information is retained for view-objects. See VOB object.
One or more components at the beginning of a pathname that specify a particular view. For example, /view/gamma and ../epsilon.
A directory that exists only in a particular view, having been created with the standard UNIX mkdir command. A view-private directory is not version-controlled, except insofar as it is separate from private directories in other views.
A file that exists only in a particular view. A private file is not version-controlled, except insofar as it is separate from private files in other views.
The name with which users reference a view. This name appears as a subdirectory of a client host's viewroot directory (/view).
The directory tree in which a view's data is stored: checked-out version, view-private objects, and unshared derived objects.
A file on the network's registry server host that records that actual storage locations of all the views in the network.
A main-memory-only data structure, maintained by the MVFS file system, that behaves like a directory. Each view is accessed through a view-tag entry in this directory. By default, the viewroot directory is named /view. A view whose tag is alpha is accessible as /view/alpha.
The directory tree in which a view's private data is stored: config spec, checked-out versions of file elements, view-private files and directories. The top-level directory of this tree is called the view storage directory.
The directory (default name: /view) in which view-tag entries appear, allowing views to be accessed through the UNIX file system.
The daemon process that continually interprets a view's config spec, mapping element names into versions.
An extension to the UNIX kernel, allowing alternative file systems to be implemented without revision to the kernel itself.
See versioned object base.
The part of a VOB storage area in which ClearCase meta-data and VOB objects (elements, branches, versions, and so on) are stored. This area is managed automatically by ClearCase's embedded database management software. The actual file system data, by contrast, is stored in the VOB's storage pools. For data integrity, ClearCase maintains a copy of this “live” VOB database, the shadow database.
An extension to the operating system's file naming scheme, which allows any historical version of an element to be accessed directly by any program. The extension also provides access to the meta-data (but not the file system data) of all of a VOB's existing derived objects.
A name, cataloged in a (version of a) directory element, for an element. Typically, the first such link is called the element's “name”; the term VOB hard link is used to refer to any additional names for the element.
A host on which one or more VOB storage directories reside.
A VOB symbolic link or VOB hard link.
The directory on which a VOB storage area is mounted. All UNIX commands, and most ClearCase commands, access a VOB through its mount point.
An object stored in a VOB: element, version of element, type, hyperlink, derived object, and so on. See view object.
Initially, the user who created a VOB with the mkvob command. The ownership of a VOB can be changed subsequently, with the chown_vob command.
A machine on whose disk a VOB is physically stored.
The directory tree in which a VOB's data is stored: elements, versions, derived objects, CRs, event history, hyperlinks, attributes, and other meta-data. The top-level directory of this tree is called the VOB storage directory.
A file on the network's registry server host that records that actual storage locations of all the VOBs in the network.
An object, cataloged in a (version of a) directory element, whose contents is a pathname. ClearCase does not maintain a version history for a VOB symbolic link.
The full pathname at which users access a VOB. The VOB storage directory is activated by mounting it as a file system of type MVFS at the location specified by its VOB-tag.
A file used to validate the password entered by a user when creating a public VOB-tag.
A make macro that specifies directories that will be searched during a build for data.
See pattern.
Causing a derived object to appear in a view, even though its file system data is actually located in a VOB's derived object storage pool.
The view context of a process, established by using the cd command to change the current working directory to a view-extended pathname. See set view.