Chapter 4. ClearCase Views



Prev 
 Next

Chapter 4. ClearCase Views

This chapter describes ClearCase's view facility, which implements independent, user-configurable workspaces for software development.

Requirements for a Development Workspace

Long-lived development projects typically involve many users, each working with tens, hundreds, or thousands of source files. The users work at different rates, and on different tasks: new coding for the next release; fixing bugs in one or more old releases; porting to new platforms; and so on.
Each user needs a certain set of sources with which to work. Different tasks (for example, bugfixing vs. new development) require different versions of the sources — that is, different configurations of the source tree(s).
Moreover, the user's workspace needs to be isolated, for purposes of editing, compiling, testing, and debugging. Ideally, the isolation should be relative, not absolute:
  • Others should be able to track the user's work, and selectively integrate it into their own work.
  • Conversely, others should be able to shut out (until a subsequent integration period) those changes that prove destabilizing to their own work.
Figure 4-1 illustrates such a development workspace.
Figure 4-1. Requirements for a Development Workspace

ClearCase Development Workspaces: Views

ClearCase supports the creation of any number of independent views. Each view is a flexible, resource-conservative workspace that combines these services:
  • Access to permanent, shared storage — A view accesses the correct set of source versions for the task at hand (bugfix, port to a new architecture, new development, and so on). It automatically selects a particular version of each ClearCase element, according to user-specified rules. Together, a “matched set” of versions constitutes a particular configuration of the central data repository.
  • Private storage — A view provides an isolated workspace with private storage, enabling individual users or small groups to work independently of each other.
A view can be completely private to an individual user, or shared among users. A view can be accessed on a single host, or from any host in a local area network. Views are compatible with all software development tools, not just ClearCase's own programs. Users working in views can use system-supplied programs, home-grown scripts, and third-party tools to process ClearCase data.

View Implementation and Usage

In its implementation, a view is somewhat similar to a VOB (see “VOB Data Structures”). Each view has a view storage directory, which contains a view database and a private storage area. Access to the physical storage is mediated by a ClearCase server process, the view_server.
But in its usage, a view differs greatly from a VOB. As part of the central data repository, a VOB is intended to be seen by (some or) all users. By contrast, a view is not principally a repository; rather, it is a tool for seeing the repository. Moreover, a view is much more likely to be private (intended for one user) than public.

Processes and View Contexts

A process that works with ClearCase data must use a view. That is, any reference to a location within a VOB must be interpreted in the context of some view. Typically, a user enters a command to “set a view”, which establishes a view context both for the current process and for any child (subsidiary) processes created subsequently. All those processes will see a particular configuration of the data repository.
A user might set different views in different windows, in order to work with two or more configurations at once. It is even possible to use multiple views in a single command — see “View-Extended Pathnames”.

Transparency and Its Alternatives

After setting a particular view, a user can use standard pathnames to access all ClearCase data; the view takes care of resolving the pathnames, component by component (Figure 4-2).
Figure 4-2. View Transparency: Resolving a Pathname

The net effect is to make all VOBs appear to be standard directory trees; an element with a complex version tree appears to be a simple file or directory. That is, automatic version-selection by a view makes the ClearCase versioning mechanism transparent.

Overriding Automatic Version-Selection

Automatic version selection by a view does not prevent users from explicitly accessing other versions. A ClearCase extended pathname can specify any version of any element, or the version of an element selected by some other view.
Version-extended pathnames, introduced in “Accessing Any Version with a Version-Extended Pathname”, specify versions by their version-tree locations. For example:
% cat util.c@@/main/bug404/1

View-Extended Pathnames

Users can also use view-extended pathnames, which reference the particular versions of elements selected by other views. All views are embedded in ClearCase's extended file name space, under a “super-root” directory, the viewroot. In this directory, each view appears as a separate subdirectory, named by its unique view-tag (Figure 4-3).
Figure 4-3. Viewroot Directory as a Super-Root

Through a view-extended pathname, any view can be used to access any available VOB. Figure 4-4 shows the components of a view-extended pathname.
Figure 4-4. View-Extended Pathname

All of the following pathnames might be used in a single command (for example, to compare the specified versions):
util.c (version seen in current view)
/view/gamma/vobs/vega/src/util.c (version seen in view 'gamma')
/view/akp/vobs/vega/src/util.c (version seen in view 'akp')

Mechanics of Version-Selection

Each ClearCase VOB contains all the versions of the file system objects in a particular source tree. Version-selection by a view is a dynamic filtering of the contents of all available VOBs (not a static copying or linking operation). The actual contents of a selected version remain in VOB storage; the version is merely mapped into the view's file name space (Figure 4-5).
Figure 4-5. Dynamic Version Selection by a View

The Config Spec and the View Server Process

Each view has a user-defined config spec (short for “configuration specification”), a set of rules for selecting versions of elements. Following are typical config spec rules, along with English translations:
element * .../maintenance/LATEST
For all file and directory elements, use the most recent version on the branch named maintenance.
element -eltype c_file *.[ch] BETA_TEST
For all elements of element type c_file whose file name suffix is .c or .h, use the version labeled beta_test.
Each view also has an associated server process, its view_server. Using the config spec rules, the view_server automatically resolves (converts) each reference to an element (foo.c) into a reference to a particular version of the element (foo.c@@/main/4). The following steps summarize the view_server's procedure for resolving element names to versions (Figure 4-6):
  1. User-level software (for example, an invocation of the C compiler) references a pathname. The ClearCase MVFS,which processes all pathnames within VOBs, passes the pathname on to the appropriate view_server process.
  2. The view_server attempts to locate a version of the element that matches the first rule in the config spec. If this fails, it proceeds to the next rule and, if necessary, to succeeding rules until it locates a matching version.
  3. When it finds a matching version, the view_server “selects” it and has the MVFS pass a handle to that version back to the user-level software.
    Figure 4-6. Using a Config Spec to Select a Version of an Element

The view_server and the MVFS use caching techniques to reduce the computational requirements of this scheme.

Flexibility of Rule-Based Version Selection

This rule-based scheme for defining source configurations provides power and flexibility, supporting both “broad-brush” and “fine-tuned” approaches. The entire source environment can be configured with just a few rules, applied to all file and directory elements. When required, fine tuning can be implemented at the individual file or directory level.
For example, a user might discover that someone has created a new version of a critical header file (say, base.h@@/main/17) — a change that causes the user's compilations to fail. A config spec rule can “roll back” the critical file (in that user's view) to a known “good” version:
element base.h /main/16
  ... or ...
element base.h /main/LATEST -time 11:30
The second alternative above illustrates use of a time rule, which can “roll back” one, many, or all source files to a known “good” state. This is very useful when an application compiles correctly before lunch break, but not after.
If no version of an element matches any of the config spec's rules, the element is suppressed from the view. This feature can be used to configure views that are restricted to accessing a particular subset of sources.

Open-Endedness of a View

Since the rules in a config spec typically involve pathname patterns (wildcards) that apply to many files and/or directories, a view is open-ended — new directories or even entire newly-mounted VOBs are automatically incorporated into a view. There is no need to “add files to a view” explicitly.

Storage Efficiency of a View

Since access to shared versions is accomplished by mapping, rather than by copying, a view is storage-efficient. For example, all views might share version /main/3 of a rarely-changed source file. The total storage cost to the views for accessing this version is zero — the single version they all share is accessed from a VOB storage pool. In addition, the views can share access to the object module built from the shared source file, through ClearCase's derived object sharing feature.

View-Private Storage / The Virtual Workspace

In addition to providing access to source versions, a view provides private (isolated) storage for the files generated during software development:
  • working (“checked-out”) versions of source files
  • object modules and executables built with ClearCase tools
  • other view-private objects — files, directories, and links created with standard commands and tools. Examples of view-private objects include text-editor backup files, source code excerpts, test subdirectories, and test data files.
A view's private storage area is typically located within a user's home directory on a workstation. (A view shared by a group of users might have its private storage area located on a central file server host.) But the actual location of the private storage area is largely irrelevant — from the user's standpoint, the view's private storage is fully integrated with the selected versions of elements, forming a virtual workspace, in which all the files appear to be co-located in the VOB's directories (Figure 4-7).
Figure 4-7. Virtual Workspace: View-Private Objects in VOB Directory

By extension (and as suggested by “View-Extended Pathnames”), a set of views is a set of “parallel” virtual workspaces — each view instantiates a variant of the complete development environment:
  • Users working in different views can create files with different names or with the same names (for example, by building the same software system), without interfering with each other.
  • Users can monitor the work taking place in other views, and can easily examine or copy it (subject to standard security mechanisms).
  • A software build in one view can reuse the object modules and executables previously built in another view. ClearCase performs this linking operation (termed wink-in) automatically, but only if reusing the existing object is equivalent to rebuilding it in the current view. For more on this topic, see Chapter 5, “Building Software with ClearCase.”

View Usage Scenarios

The following sections present typical scenarios of using a view for software development. These scenarios illustrate how views and VOBs interrelate, and provide opportunities to see config specs “in action”, performing version-selection.

Revising a Source File / Checkout-Edit-Checkin

The simplest ClearCase development scenario involves revising a source file element on its main branch. (The element might also have subbranches, being used concurrently for other development tasks.) ClearCase uses a checkout-edit-checkin scheme to control the creation of new versions of elements. This scheme is similar to that used by many other version-control systems, including sccs and rcs. We track the use of this scheme to create a new version of element util.c.

Setting a View

“Mainline” development work requires a view configured with the default ClearCase config spec (Figure 4-8).
Figure 4-8. Default Config Spec

Accordingly, the user creates a shell process that is set to such a view (or starts the xclearcase GUI application with the view set).

Changing to the VOB Directory

Once a view context is established, the user can work directly with any VOB, for example, by cd'ing to the directory in which element util.c resides.

Before the Checkout

The user's view selects a version of util.c as follows:
  1. The view_server process for the view attempts to find a version of element util.c that matches the first config spec rule. The pattern “*” matches the file name, but the element is not checked-out. Thus, the first rule fails to select any version.
  2. The view_server attempts to find a version of util.c that matches the second rule. Once again, the pattern “*” matches; and this time, the version selector /main/LATEST matches, too; the most recent version on a branch is always matched by the special version label latest. Thus, this version of element util.c is selected to appear in the view. Any command that processes the contents of util.c will access the version's read-only data container in a VOB storage pool (Figure 4-9).
    Figure 4-9. Before a Checkout

Checking Out the File

The user enters a checkout command on file util.c. This creates an editable view-private file that is a copy of the /main/LATEST version. It also creates a checkedout “placeholder” object in the VOB database. (Figure 4-10). With this change, element util.c now matches the first config spec rule, both the pattern “*” and the keyword checkedout. Thus, the editable, checked-out version appears in the view.
Figure 4-10. After a Checkout

Working With the File

The user works with the checked-out version of util.c using any available commands, programs, and scripts. All incidental files (text-editor backup files, cut-and-paste excerpts, and so on) are view-private files; such files automatically appear in the view, without needing to be selected through the config spec mechanism.

Checking In the File

The user enters a checkin command on file util.c. This creates a new, read-only version in the VOB by copying the contents of the editable, view-private file (and then deleting it). Now, the view reverts to using the /main/LATEST rule to select a version of util.c (Figure 4-11); it selects the newly-created version in the same way that it selected the predecessor version in “Before the Checkout”.
Figure 4-11. After a Checkin

Parallel Development / Working on a Branch

ClearCase views play a pivotal role in ClearCase's support for parallel development. This topic was approached from a version-tree perspective in “Requirements for a Development Workspace”. Now, we can concentrate on how the view mechanisms work to support a baselevel-plus-changes model.

Different Views for Different Branches

Any number of branches can be created in an element's version tree. In general, development projects maintain their mutual independence by creating versions on different branches. Thus, a user's view must be configured to see the branches for his own project. A user working on a new port of an application might use a view that selects versions on branches named gopher_port; a user fixing bugs might use a view that selects versions on branches named r2_fix.
Figure 4-12 shows the config spec for a view used by a user working on the “gopher” port, which is based on the “R2” release of the application.
Figure 4-12. Config Spec for Parallel Development

As the following analyses show, this config spec both imposes and follows the required branching structure:
  • Elements not modified for the port — Many elements will not need to be modified at all to port the application. For such elements, Rules 1 and 2 fail to match, so the version-selection mechanism “falls through” to Rule 3. This rule establishes the view's baselevel set of versions: the versions that are labeled R2.
  • Beginning porting work on an element — Prior to the first time an element is modified for the porting project, the user's view uses Rule 3 to select the version labeled R2, as described in the preceding paragraph. When the user enters a checkout command to modify the element, the -mkbranch clause is invoked, creating the required gopher_port branch at the version labeled R2, and checking out the new branch.
Now, Rule 1 applies, enabling the user to edit the checked-out version. When the user enters a checkin command, version 1 is created on the new branch.
  • Continuing porting work on an element — During the porting project, the user can modify an element any number of times. All new versions go onto the element's gopher_port branch:
    • Before checkout, Rule 2 selects the most recent version on the branch.
    • After checkout, Rule 1 selects the checked-out, editable version.
    • After checkin, Rule 2 applies once again, selecting the newly-created version on the branch.
Users can checkout two or more branches at the same time, as long as they are working in different views.

Prev Table of Contents Next
Chapter 3. ClearCase Meta-Data 
Chapter 5. Building Software with ClearCase 

No comments:

Post a Comment