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 place-holder 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.