ClearCase Concepts and Terminology
ClearCase Concepts & Terminology










VOB
Element
Version, Version Tree
Meta data
Branch
View
View private object
Config Spec
View Profile
Checkouts (reserved/unreserved)
VOB – Version Object Base
 Comprised of a large set of of server based
storage containers residing in a proprietary
database.
 Data repository that stores versions of file
elements, directory elements, and meta-data
associated with these elements.
 Any item stored within a VOB is called an
element. There are two effective types of
elements for this discussion: file elements and
directory elements.
Element – File or Directory
 An element is a file or directory that is under
ClearCase control, including all its constituent
versions.
 An element is the basic item that ClearCase
“versions”. The version of an element is what
the end-user will work with in the majority of
his/her ClearCase interactions.
 A new version of a file or directory element is
created each time it is revised and checked-in.
Element – File or Directory
 File elements can be of many different file
types. Examples of these file types include
binary files (ie. DLLs, executables) as well as
standard source code files for all types of
languages.
 Directory elements contain file entries only.
Version of an Element
 A version is a particular revision of an element
(file element or directory element).
 A new version of a file or directory element is
created each time it is revised and checked-in.
 The versions of every element are organized into
a version tree structure.
Version Tree of an Element
 A version tree is a hierarchical structure in
which all the versions of an element (file or
directory elements) are logically organized.
Meta-Data
 Meta-data is information associated with a
ClearCase element, including labels, attributes,
hyperlinks, branches, triggers, etc. We will
discuss in brief only those meta-data that an
end-user would deal with (labels, attributes,
branches).
 A label is a ccadmin-defined field that is
attached to a version. This field can contain any
data such release or fix ids, source code
baseline ids, or other identifiers useful to the
developer.
Meta-data (continued)
 An attribute is a tag in the form of a name/value
pair. It can have a specific value or a range of
values and can be attached to versions and/or
branches.
 An attribute’s name/value-range are usually
defined by ccadmin. The value assigned to an
attribute is usually set by the end-user.
 Attributes are useful in creating interfaces with
other systems, and for tracking the status
shipped/testing status of a particular code
module.
Meta-data (continued)
 A branch is a linear sequence of an element’s
versions.
 It is a special type of meta-data that enables
multiple versions of an element to diverge at a
specified point, which enables developers to
work in parallel on a common module.
 Common types of branches: integration branch
(shared/common branch among large team),
private branch (exclusive branch used to isolate
changes from other team members).
View – Primary Workspace
 A view is the basic ClearCase unit used to access
a VOB (versioned object base).
 Users may have more than one view, active or
inactive, at a time.
 Each view can be configured to select a
different version set of elements. For example,
HRMS801_view can be configured to look at the
latest 8.01 version of File A, while
HRMS880_view can be configured to look at the
latest 8.80 version of Fie A.
View Types – Dynamic & Snapshot
 ClearCase utilizes two types of views: dynamic
view and snapshot view.
 The dynamic view is the most common method of
accessing a VOB.
 Uses the ClearCase Multiversion File Version (MVFS).
 Provides immediate access to the latest checked-in
versions of elements based on the view’s
configuration.
 Displays itself under the “B:drive” on your local
machine’s Windows Explorer session.
 Can be activated and used only when your machine is
connected directly to the PeopleSoft LAN.
View Types (continued)
 The snapshot view is best utilized when you are
disconnected from the the LAN.
 Copies/loads the elements from a VOB to a
designated location on your local machine.
 Requires the user to perform an update to load any
newly created versions into the view since the last
update or original load took place.
 Does not provide access to the lastest checked-in
versions of elements until the user has performed an
update view operation.
View Private Object
 A view private object is a file or directory that
exists only in a particular view.
 View private objects are not under ClearCase
version control.
 Include objects such as temporary files,
checked-out files, any files copied into a view by
the user.
 An editable view private copy of a file is placed into a
user’s view at checkout time. It will remain as a view
private copy until it is checked-in, which would then
promote the changes to the VOB and create a new
version of that element.
View Config Spec
 A view’s config spec (configuration specification)
governs which versions of VOB elements a view
will select and in what order they should be
selected.
 Every view has a config spec, either the default
one or a customized one.
 Config specs are usually created/modified by
ccadmin. On rare occasion, a user might modify
his/her own view config spec.
Accessing VOB elements
Dynamic or Snapshot
View config spec
selects one version
of an element,
rejects all others.
View Profiles (Windows only)
 A view profile consists of a base config spec
along with a list of vobs to be automatically
mounted when the view is activated.
 Can be associated with a view at any time, but is
most commonly associated with the view at view
creation time.
 Available only to ClearCase Windows clients.
Not available on Unix platform.
Modifying VOB Elements
 Modifying VOB elements involves starting a view,
checking out the elements you wish to change,
editing them, checking in the elements that have
been changed.
 Two types of checkouts in ClearCase: reserved
checkout and unreserved checkout.
Reserved Checkout
 A reserved checkout creates a place-holder
(reservation) for the next version of the
element.
 The user/view that issued the reserved
checkout has exclusive ownership of the placeholder until the checkout has been checked-in or
cancelled.
 No other checkins of the element can be made
until the reserved checkout has been resolved
(ie. checked in or cancelled).
Unreserved Checkout
 An unreserved checkout of an element does
*not* reserve the next successor version for
that view.
 Can be issued against the same element by
multiple views assuming no reserved checkout
exists on that element.
 Checkin of an unreserved checkout is on a first
come, first served basis.
 If a checkin from another view has taken place before
your checkin, a merge of the versions might be
required in order to checkin your change.