How your views are populated in base VersionVault

Two mechanisms determine which versions are visible in your base VersionVault 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®:

A VOB contains the element prog.c main branch with versions 0 through 4. A load rule (snapshot view) copies the version from the VOB to the user's work area. The rule element * /main/LATEST selects version 4. The cleartool command ls -l ~/pat_v1.4_cropcircle_sv/guivob lists the version selected in the view.

On Windows® systems:

A VOB contains the element prog.c main branch with versions 0 through 4. A load rule (snapshot view) copies the version from the VOB to the user's work area. The rule element * /main/LATEST selects version 4. The Details pane of HCL VersionVault Windows Explorer or Windows Explorer lists the version selected in the view.

Config specs for dynamic views (HCL VersionVault 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:
    element * BASELINE_1
    
    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).

    For more information about labels, see the Help.

  • 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 Help and the config_spec reference page in the Help.