How your views are populated in base ClearCase
Two mechanisms determine which versions are visible in your base ClearCase® views (views that are not attached to a UCM stream):
- A set of rules called a configuration specification, or config spec, selects one version of each element in a VOB.
- In a snapshot view, the update operation loads (copies) the selected versions as files and directories in the view. You can change the set of elements that are loaded in your view at any time. For example, if you work on a discrete subset of your project's files, you can choose to load only the subset into your view.
In a dynamic view, a view_server process arranges the versions selected from the VOB into a directory tree. For a dynamic view to access VOB data, you must activate the VOB on your computer.
Config specs for snapshot views
Config specs for snapshot views contain two kinds of rules: load rules and version-selection rules. The following illustrations show how the rules in a config spec determine which files are in a snapshot view.
On the UNIX® system or Linux®:
On Windows® systems:
Config specs for dynamic views (DevOps Code ClearCase systems only)
Dynamic views use version-selection rules only (and ignore any load rules).
A dynamic view selects all elements in all VOBs that are mounted or activated on your computer, and then uses the version selection rules to select a single version of each element. Instead of copying the version to your computer as a standard file, the view uses the MVFS (multiversion file system) to arrange the data selected in the VOB into a directory tree.
Criteria for selecting versions
The rules in the config spec constitute a powerful and flexible language for determining which versions are in your view. For example, version-selection rules can specify the following criteria:
- The latest version.
- A version identified by a label.
A label is a text annotation you can attach to a specific version of an element. Usually, your project manager attaches a label to a set of versions that contributed to a specific build.
A typical config spec rule that uses version labels to select versions:
For example, if your project manager attaches version label BASELINE_1 to a version of element prog.c, any view configured with this rule selects the labeled version (unless some rule earlier in the config spec matches another version of prog.c).element * BASELINE_1
For more information about labels, see the DevOps Code ClearCase Guide to Managing Software Projects.
- A version identified by a time rule, that is, a version created before or after a specific time.
The version-selection rules are prioritized. For example, the view can try to select a version identified by a label first, and if no such version exists, the view can select a version based on a time rule.
Learning the config spec syntax
Usually, only one or two members of your software team learn the syntax for these rules and creates config specs that everyone on the project uses. For more information about the rules in the config spec, see the DevOps Code ClearCase Guide to Managing Software Projects and the config_spec reference page in the DevOps Code ClearCase Command Reference.