ClearCase Architecture

Version: 178
Published on: 5/18/2011 1:27 PM

1. Using source code repositories

Following is a diagram of the abstract structure of a typical source code repository.

In this diagram, a single repository contains all versions of all files. The names of
elements are unique within the repository. Each developer gets a private, independent
workspace that represents a "slice" of the repository along with the developer's own
changes. The developer can retrieve specific versions of files from the repository to his
workspace, add to, modify, or delete from the files in his workspace, and update the
repository with his changes.

2. The ClearCase implementation

The ClearCase version control system is designed to allow the physical distribution of the
repository and workspaces across any number of hosts. This leads to a higher level of
complexity than single-point-of-access version control systems such as PVCS and
Subversion. ClearCase manages all of these distributed components with the registry.
 ClearCase Architecture

2.1. The registry

The registry server is the focal point for ClearCase management.

• It provides a namespace for managing objects in your development group.

• It indexes vobs, which are physical storage areas for the repository.
• It indexes views, which are physical and virtual storage areas for workspaces.

Vobs may be physically distributed over any number of hosts, but their names must be
unique in the registry namespace. Similarly, views may be physically distributed over any
number of hosts, but their names must also be unique in the registry namespace. This
namespace acts like a meta-repository, providing a context that applies to physically
distributed components, such as vobs and views, as well as other familiar elements in
version control systems, such as labels and baselines.

2.2. The repository

2.2.1. ClearCase Vobs

ClearCase stores versioned sets of files in a sort of database called a vob (versioned
object database). It would be easy to think of each vob as a repository, but this leads to
some confusion. ClearCase's use of the registry, common to all vobs, allows things that
were traditionally scoped within a repository to span multiple vobs. For this reason, it's
better to think of the collection of vobs known to the registry as the repository, as shown
in this diagram:

-2-
 ClearCase Architecture

Some comments about vobs:

• All vobs must be stored in an area that is available as a file share over the
network.
• Vobs can be distributed across multiple hosts on the network.
• All vobs are indexed by the registry server, which keeps track of the host and file
locations on which each vob is stored.
• All vob names must be unique across the entire namespace managed by the
registry server. This namespace is not limited to a specific host.

-3-
 ClearCase Architecture

• A vob must be "mounted" on a host before it can be used by the dynamic views
on that host.

2.2.2. Single Component vs. Multi-Component vobs

A vob is permanently configured when it is created as a "single component" or "multi-

component" vob. These names refer to how labels and baselines can be applied to the
individual versioned files in the vob.

• In the case of a single component vob, a label or baseline name is associated with
a specific version of every versioned file in the entire vob.
• In the case of a multi-component vob, each top-level directory of the vob is
treated as an independent set of files for association with a label or baseline.

2.3. The workspaces

2.3.1. ClearCase Views

A workspace in the ClearCase implementation is called a view. A view is an area of

storage for holding a set of working copies of files. Users familiar with source control
systems such as RCS, PVCS, Subversion and the like may be surprised to see that
ClearCase globally manages all workspaces, even personal ones. These workspaces must
be created, named, and registered with the registry server, which maintains a list of all
workspaces in your enterprise.

-4-
 ClearCase Architecture

Some comments about views:

• All views must be stored in an area that is available as a file share over the
network.
• A view is used to access particular versions of files in one or more vobs.
• View names are registry-wide in scope.
• A view is permanently associated with a specific storage area which can be on
any machine (see below) in the network as long as it is available as a share.
• A view is permanently associated with a specific owner.

-5-
 ClearCase Architecture

2.3.2. View Configuration Specs

A view configuration spec identifies the vobs associated with the view, and the version of
each file from those vobs.

• Views can reference any vob known to the registry server.

• The versions desired can be identified specifically (i.e. version #12) or relatively
(i.e. the latest version)
• Before a dynamic view is started, the vobs referenced in the view configuration
spec must be "mounted" on the view's host.

2.3.3. View, the misnomer

For those of us used to the idea of a database view, the name view can be misleading.
Like a database view, a ClearCase view describes a "slice" of the database. With a
database view, however, the description of the "slice" never changes, while a ClearCase
view will be loaded with a different description depending upon your work. In addition, a
ClearCase view is associated with a physical storage location which never changes. For
this reason, it's probably better to think of a ClearCase view as a "viewer" or
"workspace". Or a tv that lets you look at a particular channel (slice) of the database, and
then turn the knob by changing the view definition to look at something else:

-6-
 ClearCase Architecture

This approach is critically different from a database view, in that the description part of a
database view usually never changes.

To help keep the correct idea in mind, this document will often refer to
a ClearCase view as a workspace.

2.3.4. Snapshot vs. Dynamic

ClearCase supports 2 different kinds of workspace that differ in how they maintain their
synchronization with the central repository:

Snapshot View Workspace Dynamic View Workspace

• must be manually updated from the • continuously and automatically
repository to show changes from updated from the repository to show
other users changes from other users

• resides on a network share that is • resides on a network share that is

backed by an ordinary filesystem backed by an MVFS filesystem

-7-
 ClearCase Architecture

• uses physical storage to keep the • only checked out and derived files
workspace's copies of all files use physical storage on the host,
other files are virtualized from the
repository

• Dynamic views require the vob to be mounted to the host on which the dynamic
view is stored.
• Dynamic views can be started and stopped. This starts and stops the background
process that connects to the vob and maintains the view's contents.

A workstation with clearcase installed can be configured to have a local MVFS

filesystem. MVFS pulls files from the vob as they are referenced and frees them when
space is needed for other files. This is why a workstation's local MVFS filesystem can
appear to have more storage than is available on the local hard drive that backs the MVFS
filesystem.

2.4. Accessing components

When debugging problems with ClearCase, it may be helpful to understand how each of
the components we have described above are accessed. In this area, as well, ClearCase
differs from other well known version control systems. Some systems like VCS and
SubVersion access their repositories mainly via a server process, which is typically
located at a specific port on a specific host. Other systems, such as PVCS, run entirely on
the client, and use a common set of files that are located at a specific file share on a
specific host. ClearCase uses both server processes and file shares to make its repository
available to network clients, and allows it to be broken down into many pieces which can
reside on any number of hosts throughout the network. Furthermore, ClearCase uses this
technique for managing workspaces as well.

2.4.1. Locating the Component

Obviously, the ClearCase architecture requires a mechanism to find one of these

distributed components, and that is the registry server. Accessing any ClearCase
component involves first making an RPC request to the registry server to locate the
desired component on your network. Once the component is located, it can be accessed
via either the file share method or the RPC method.

2.4.2. Access methods

• When performing a task that uses the shared filesystem to access components,
access control is managed by the operating system.

-8-
 ClearCase Architecture

• When making an RPC request, ClearCase invokes a server on a remote host and
passes to it your user id and group memberships. The remote server then maps
these credentials to id's in its local environment, and uses this information to
determine your access rights.
• Note that these two access methods are fairly independent of each other.

2.4.3. Vob services

A vob is made available to its clients via both a shared filesystem and through rpc calls,
assisted by the registry server:

Some comments about accessing vob services:

• Some access to vobs is made available to clients via a shared filesystem. So far it
looks like dynamic views are the only clients which access vobs in this way.
• Some access to vobs is made available to clients via RPC calls.
• Public vobs are owned by the ccadmin account on the host on which they reside.

-9-
 ClearCase Architecture

• Public vobs group ownership is assigned to the ClearCase users group.

• Most users will access the vobs via the rights assigned to the group bits which are
granted to members of the ClearCase users group.
• A user must be a member of the clearcase users group to access vobs.

For windows clients accessing vobs on Unix hosts, a third party component called Samba
is used to support shared filesystem access:

Some comments about Samba:

• When a unix vob is shared via samba, the owner shows through while the group
ownership appears as an acl entry.
• The setting (rwx) of the group bits does NOT show through to the group acl when
using Samba. Access does work as it should, however.

2.4.4. View services

Like a vob, a view is made available to its clients via both a shared filesystem and
through rpc calls, assisted by the registry server.

- 10 -
 ClearCase Architecture

Views make use of two filesystem areas, and understanding the difference between them
is important to organizing environments. One area we will call "the presentation area",
and is the filesystem area that you use to access files for builds and such. Views also have
a "view storage" area, which contains the database files needed to support the view
presentation. Rather than placing these files politely in a background area, the view
storage filesystem area must be directly managed by users and administrators, just like
that of a vob.

Some comments about accessing views:

• Some control access to views is made available to clients via a shared filesystem
in which is stored the "view storage". No matter what kind of view this supports,
the view storage area must be an ordinary filesystem.
• Some control access to views is made available to users via RPC calls.
• The presentation area of a workspace can contain unchecked out files from the
repository, checked out files, and "view private" files.
• Unchecked out files are owned by the account that created the view and read only.
• Checked out files are owned by the account that created the view and read/write.
• View private files are owned by whoever created them.

2.4.5. The Implementation of Static Views

- 11 -
 ClearCase Architecture

2.4.6. The Windows Implementation of Dynamic Views

Not what you'd expect !!

- 12 -
 ClearCase Architecture

• The shared filesystem is only used to access the view's database files. It is not
used to present the view itself.
• There is a single MVFS drive on the view server, where all of the views hosted by
that server are presented. The drive is attached at startup, and contains a directory
for each view being hosted. The drive is only available on the local host, and can
not be shared as a whole.
• When you create a view, a drive on your Windows client is optionally created
which maps to that view's directory in the presentation area on the view server.

3. Assembling an Environment

3.1. A common view server

Although the ClearCase distributed architecture supports a decentralized approach, most

environments can benefit from some centralized services. One commonly used approach
is the "common view server". This is a server that provides a single area for a group of
developers to store dynamic views.

- 13 -
 ClearCase Architecture

Some comments about this arrangement:

• by backing up this one server, we can be sure all the developers' day-to-day work
is backed up
• the overhead of running an MVFS filesystem is confined to one place
• makes a workspace publicly available and easily shareable with other developers
• the developers generally work with the view, and have little interaction with the
vob once the view is set up

3.2. A personal static workspace

This arrangement can be used when you want to create a workspace that you can work on
"offline".

- 14 -
 ClearCase Architecture

3.3. A personal dynamic workspace

This arrangement can be used in situations where we may need to support many
workspaces on a host (such as a build server), so we want to use MVFS to keep local
storage requirements to a minimum.

- 15 -
 ClearCase Architecture

• if used for a build server, the views will not contain "view private" or checked out
files, so backups are not needed

- 16 -