Glossary



Prev 
 Next

Glossary

abe
See audited build executor.
active
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.
annotation box
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.
argument
A word or quoted set of words processed by a command.
attached list
See trigger inheritance.
attribute
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.
attribute name
See attribute, attribute type.
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).
attribute value
See attribute type.
audited build executor
A process invoked through the UNIX remote-shell facility, in order to execute one or more build scripts on behalf of a remote clearmake.
audit, audited shell
See build audit.
auto-make-branch
ClearCase's facility, specified in a config spec rule, for automatically creating one or more branches when a checkout is performed.
base contributor
See contributor.
bidirectional
See hyperlink.
bitmap files
Files that store bitmaps for the icons displayed by ClearCase GUI programs.
BOS file
See build options specification.
branch
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.
branch name
See branch type.
branch pathname
A sequence of branch names, starting with /main (the name of an element's starting branch). Example: /main/motif, /main/maintenance/bug459.
branch type
An object that defines a branch name for use within a VOB.
Broadcast Message Server
An H-P SoftBench program that passes messages among SoftBench applications.
build
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.
build audit
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.
build avoidance
See build.
build configuration
See configuration lookup.
build dependency
See dependency.
build host
A host used to execute build scripts during a distributed build.
build hosts file
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.
build avoidance
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.
build options specification
A file containing rules that specify settings of make macros, which affect the way in which a target rebuild proceeds.
build reference time
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.
build script
The set of shell commands that clearmake (or standard UNIX make) reads from a makefile when building a particular target.
build server
A host used in a clearmake distributed build.
build server control file
A file on a build host that controls its availability as a build server.
build session
A top-level invocation of clearmake; during the session, recursive invocations of clearmake or clearaudit may start subsessions.
build target
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.
built-in rules
Build rules defined in a system-supplied (or ClearCase-supplied) file, which supplement the explicit build rules in a user's makefile (s).
bump
The taking away of a ClearCase license from a lower-priority user by a higher-priority user.
candidate
A derived object that is being considered for wink-in or reuse during configuration lookup.
cataloged
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.
checked-out version
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.
checkout/checkin
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.
checkout record
The event record created by the checkout command.
cleartext file
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.
cleartext pool
A VOB storage pool, used for data containers that contain cleartext.
CLI
ClearCase's command-line interface.
client
The programs invoked by users: cleartool, xclearcase, clearmake, cleardiff, and other programs located in the ClearCase bin directory.
clock skew
The discrepancies among the system clocks of several hosts.
command option
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.
comment default
The action taken by a cleartool command when the user does not specify a comment-related option.
compatibility mode
A clearmake execution mode, in which it emulates another make variant.
compressed_file
The ClearCase element type that uses data compression on individual versions.
compressed_text_file
The ClearCase element type that uses both delta management and data compression on individual versions.
configuration (of a derived object)
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.
config spec
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.
configuration (of a view)
The set of versions (one version of each element) selected by a view's config spec.
configuration lookup
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.
configuration management
The discipline of tracking the individual objects and collections of objects (and the versions thereof) that are used to build systems.
configuration record (CR)
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.
configuration record hierarchy
A tree structure of configuration records, which mirrors the hierarchical structure of targets in the makefile.
configuration rule
See config spec.
configuration specification.
See config spec.
container
See data container.
context
See view context.
contributor
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.
conversion script
A shell script by one of the ClearCase file-conversion programs — for example, clearcvt_rcs.
CR
See configuration record.
cross-VOB hyperlink
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.
current working directory
The context in which relative pathnames are resolved by the operating system. This can be a location in ClearCase's extended namespace.
data container
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.
default config spec
See config spec.
degenerate derived object
A derived object that cannot be successfully processed, because it data container and/or associated configuration record are not available.
delta
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.
dependency
(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.
derived object (DO)
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.
derived object storage pool
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.
derived object scrubbing
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.
derived object sharing
The ClearCase feature wherein several views can simultaneously use the same derived object, through a mechanism resembling a UNIX hard link. See wink-in.
derived object version
See DO version.
difference pane
A subwindow in an xcleardiff window that shows the contents of one of the files being compared or merged.
difference section
A set of lines in a difference pane, or in cleardiff output, that differs among the files being compared or merged.
directory element
An element whose versions are like UNIX directories — they catalog the names of file elements, other directory elements, and VOB symbolic links.
directory version
A version of a a directory element.
distributed build
See parallel build.
DO
See derived object.
DO version
A derived object that has been checked in as a version of an element.
DO-ID
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.
DSEE
The Domain Software Engineering Environment.
eclipsed
Invisible, because another object with the same name is currently selected by the current view.
element
An object that encompasses a set of versions, organized into a version tree.
element type
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.
ellipsis
The wildcard symbol “...”. In a version-selector, it indicates zero or more directory levels.
encapsulator
A program that packages the functionality of an external software system.
event
A ClearCase operation that is recorded by an event record in a VOB's event history.
event record
An item in a VOB database that contains information about an operation that modified that VOB.
export view
A view used to export a VOB to a non-ClearCase acess host.
extended namespace
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.
extended naming symbol
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.
extended pathname
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
file type
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.
file contents
See file system data.
file element
See element.
filename pattern
See pattern.
file system configuration
The set of element versions selected by a view.
file system data
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).
fire a trigger
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.
flat
A non-hierarchical listing, combining information from a collection of configuration records.
from-object
See hyperlink.
from text
A string-valued attribute attached to a hyperlink object, conceptually at its “from” end.
full pathname
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.
g-file
A file produced by the SCCS get command.
global element trigger type
A trigger type that is automatically associated with all elements in a VOB.
global pathname
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.
Gnu make
A make variant distributed by the Free Software Foundation.
hard link
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.
header file
A source file whose contents are included in a program with an #include statement.
history
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.
history mode
The state of a process whose current working directory is in the ClearCase VOB-extended namespace (for example, hello.c@@/main).
hyperlink
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.
hyperlink browser
An xclearcase panel that enables a user to traverse hyperlinks.
hyperlink-ID
A system-generated identifier that, in conjunction with the name of the hyperlink type, uniquely identifies a hyperlink object. Example: @391@/usr/hw.
hyperlink type
An object that defines a hyperlink name for use within a VOB.
hyperlink selector
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
icon
A small picture used by ClearCase GUI programs.
icon file
A file containing rules that map ClearCase file types to names of bitmap files.
inclusion list
A list of type objects, defining the scope of a trigger type.
inherit, inheritance list
See trigger inheritance.
installation host
A host of which ClearCase has been (or is about to be) installed.
interactive mode
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.
label type
A type object that defines a version label for use within a VOB.
leaf name
The simple file name at the end of a multiple-component pathname.
license
Permission for one user to run ClearCase programs and/or use ClearCase data, using any number of hosts in the local area network.
license database file
A file that defines a set of ClearCase licenses.
license priority
A “slot” in the scheme by which some ClearCase users can bump others, taking their licenses.
license server
A host whose albd_server process controls access to the licenses defined in its license database file.
link text
The text string that is the contents of a UNIX-level symbolic link or a VOB symbolic link.
load balancing
The ClearCase facility for intelligently managing a distributed build, so as not to overload individual hosts.
lock
A mechanism that prevents a VOB object from being modified (for file system objects) or unreferenceable (for type objects). See obsolete.
logical operator
A symbol that specifies a Boolean arithmetic operation.
lost+found
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.
magic file
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.
main branch
The starting branch of an element's version tree. The default name for this branch is main.
make macro
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.
makefile
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.
makefile dependency
See dependency.
master conversion script
The script, created by one of the ClearCase conversion utilities, that is explicitly executed by the user to perform the data conversion.
merge
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.
meta-data
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.
method
A program that implements one of the functions of a type manager.
minor event
An event whose event record is, by default, not listed by the lshistory command.
multiversion file system (MVFS).
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.
MVFS object
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.
namespace
A file/directory name hierarchy. Different views can “see” different namespaces, because they can select different versions of directory elements. See extended namespace.
network region
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.
nobody
The username sometimes assigned to a remote process owned by the root user on the local host.
non-ClearCase access
Access to ClearCase data from a host on which ClearCase has not been installed.
non-MVFS object
See MVFS object.
notice forwarder
One of the message-passing programs in an H-P SoftBench environment.
null-ended
A hyperlink that is connected to only one object, not two.
object
An item stored in a versioned object base (VOB). This includes elements, versions of elements, branches, derived objects, hyperlinks, locks, pools, and types.
object-ID (OID)
A ClearCase-internal identifier for an object. See UUID.
obsolete object
An object that has been locked with the lock –obsolete. By default, such objects are not listed by commands such as lstype and lslock.
orphaned element
An element that is no longer cataloged in any version of any directory. Such elements are moved to the lost+found directory.
owner
The user who owns a VOB, a view, or an individual file system object. The user who creates an item becomes its initial owner.
parallel build
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.
parallel development
The concurrent creation of versions on two or more branches of an element.
pathname
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.
pattern
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.
permission
Ability to perform an operation that modifies a VOB or a file system object.
pool inheritance
The feature by which a newly-created element is assigned to the same VOB storage pools as its parent directory element.
post-operation trigger
A trigger that fires after the associated operation.
predecessor version
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.
pre-operation trigger
A trigger that fires before the associated operation, possibly cancelling the operation itself.
principal group
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.
private storage area
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.
private VOB-tag
See public VOB-tag.
promotion
Migration of a derived object from view storage (private) to VOB storage (shared).
public VOB-tag
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.
query language
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.
RCS
The Revision Control System.
record
See event record, configuration record.
reference count
The number of references to a derived object, in multiple views and, perhaps, several times in the same view (through UNIX hard links).
reference time
See build reference time.
refinement
See supertype.
relative pathname
A pathname that does not begin with “/”.
release host
The host on which the ClearCase software is unloaded from the distribution medium.
reserve state
For a checked-out version, either “reserved” or “unreserved”. The reserve and unreserve commands change the reserve state of a checked-out file.
reserved checkout
See checkout.
restriction list
A specification of which kinds of objects are to be associated with a trigger type.
reuse
clearmake is said to reuse a derived object if the object already exists in a view and a build leaves it alone.
root
The privileged “superuser” on a host.
same-VOB hyperlink
A hyperlink that connects two objects in the same VOB.
schema
The format of a database.
scheme file
A file that contains a collection of X Window System resources, which control various aspects of GUI applications.
scope
The part of a config spec rule that restricts it to a particular kind of file system objects. See config spec, pattern, version selector.
scrubbing
Discarding of data container files from cleartext pools and derived object pools, performed by scrubber(1MA).
selection operator
See selection expression.
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.
set view
(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.
s-file
A file in which SCCS stores all versions of a versioned file.
shared derived object
A derived object that is referenced by multiple views, and whose data container has migrated to a VOB's derived object storage pool.
sibling
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.
single-command mode
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.
SoftBench
An interprocess messaging system.
source control
See version control.
source dependency
See dependency.
source pool
A storage pool for the data containers that store versions of file elements.
storage pool
A source pool, derived object pool, or cleartext pool.
storage registry
A network-wide database, which records the actual storage locations of all VOB storage directories and all view storage directories.
stranded derived object
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.
subsession
A build session that was started while a higher-level build session was active.
subtarget
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.
subbranch
A branch of an element's version tree other than the main branch.
successor version
See predecessor version.
supertype
An element type that is used as the basis for defining another element type (said to be a refinement of the supertype).
tags registry
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.
target, target rebuild
See build.
text_file
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.
text-only
A hyperlink for which there is no “to” object, only a text annotation on the “from” object.
time rule
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,
to-object
See hyperlink.
from text
A string-valued attribute attached to a hyperlink object, conceptually at its “from” end.
ToolTalk
An interprocess messaging system.
transcript pad
A scrollable subwindow in which a ClearCase GUI program displays output.
transparency, transparent access
The ClearCase feature that enables standard programs to access versioned files and directories using standard pathnames.
trigger
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.
trigger inheritance
The process by which triggers in the inheritance list of a directory element are automatically attached to new elements created within the directory.
trigger type
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.
type
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.
type manager
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,
type trigger type
A trigger type that is associated with (and thus, monitors changes to) one or more type objects.
uncheckout
The act of cancelling a checkout operation.
unidirectional
See hyperlink.
universal unique identifier
See UUID.
unregister
See storage registry.
unreserved checkout
See checkout.
unshared derived object
A derived object that has never been winked-in to another view.
user profile
A file that stores a user's individual specifications for cleartool comment handling.
UUID
A universal unique identifier, which ClearCase uses to track VOBs, vies, and the objects they contain.
version
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.
version 0
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.
.version control
The discipline of tracking the version evolution of a file or directory.
version-extended namespace
See extended namespace.
version-extended pathname
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.
version-ID
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
version label
An instance of a label type object, supplying a user-defined name for a version.
version-number
The ClearCase-assigned integer that identifies the position of a version on its branch.
version selection
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.
version selector
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.
version tree
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)
version-extended namespace
See VOB-extended namespace.
versioned object base (VOB)
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.
view
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.
view context
The view (if any) which will be used to resolve a pathname to a particular version of an element.
view database
The database within a view storage directory, which the associated view_server process uses to track objects in the view's private storage area.
view-extended namespace
See extended namespace.
view-extended pathname
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.
view object
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.
view prefix
One or more components at the beginning of a pathname that specify a particular view. For example, /view/gamma and ../epsilon.
view-private directory
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.
view-private file
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.
view-tag
The name with which users reference a view. This name appears as a subdirectory of a client host's viewroot directory (/view).
view storage directory
The directory tree in which a view's data is stored: checked-out version, view-private objects, and unshared derived objects.
view storage registry
A file on the network's registry server host that records that actual storage locations of all the views in the network.
viewroot directory, view-tag
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.
view storage area, view storage directory
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.
viewroot directory
The directory (default name: /view) in which view-tag entries appear, allowing views to be accessed through the UNIX file system.
view_server
The daemon process that continually interprets a view's config spec, mapping element names into versions.
virtual file system
An extension to the UNIX kernel, allowing alternative file systems to be implemented without revision to the kernel itself.
VOB
See versioned object base.
VOB database
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.
VOB-extended namespace
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.
VOB hard link
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.
VOB host
A host on which one or more VOB storage directories reside.
VOB link
A VOB symbolic link or VOB hard link.
VOB mount point
The directory on which a VOB storage area is mounted. All UNIX commands, and most ClearCase commands, access a VOB through its mount point.
VOB object
An object stored in a VOB: element, version of element, type, hyperlink, derived object, and so on. See view object.
VOB owner
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.
VOB host
A machine on whose disk a VOB is physically stored.
VOB storage directory
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.
VOB storage registry
A file on the network's registry server host that records that actual storage locations of all the VOBs in the network.
VOB symbolic link
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.
VOB-tag
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.
VOB-tag password file
A file used to validate the password entered by a user when creating a public VOB-tag.
VPATH
A make macro that specifies directories that will be searched during a build for data.
wildcard
See pattern.
wink-in
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.
working directory view
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.

Prev Table of Contents Next
Chapter 6. ClearCase Process Control 
Index 

No comments:

Post a Comment

Subscribe to: Posts (Atom)