Prev | Next |
This chapter describes ClearCase's view facility, which implements independent, user-configurable workspaces for software development.
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:
Figure 4-1 illustrates such a development workspace.
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.
ClearCase supports the creation of any number of independent views. Each view is a flexible, resource-conservative workspace that combines these services:
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.
- 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.
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.
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.
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”.
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”.
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).
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.
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.
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:
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 |
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).
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.
All of the following pathnames might be used in a single command (for example, to compare the specified versions):
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.
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') |
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).
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:
For all file and directory elements, use the most recent version on the branch named maintenance.
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):
The view_server and the MVFS use caching techniques to reduce the computational requirements of this scheme.
element * .../maintenance/LATEST |
element -eltype c_file *.[ch] 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):
- 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.
- 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.
- 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.
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:
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.
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 |
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.
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.
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.
In addition to providing access to source versions, a view provides
private (isolated) storage for the files generated during software
development:
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).
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:
- 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.
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.”
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.
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.
“Mainline” development work requires a view configured with the default ClearCase config spec (Figure 4-8).
Accordingly, the user creates a shell process that is set to such a view (or starts the xclearcase GUI application with the view set).
Accordingly, the user creates a shell process that is set to such a view (or starts the xclearcase GUI application with the view set).
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.
The user's view selects a version of util.c as follows:
- 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.
- 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).
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.
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.
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”.
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.
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.
As the following analyses show, this config spec both imposes and follows the required branching structure:
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.
Users can checkout two or more branches at the same time, as long as they are working in different views.
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.
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.
- 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.
- Before checkout, Rule 2 selects the most recent version on the branch.
Prev | Table of Contents | Next |
Chapter 3. ClearCase Meta-Data | Chapter 5. Building Software with ClearCase |
No comments:
Post a Comment