How a config spec works
Snapshot views use config specs that contains two kinds of rules: load rules and version-selection rules.
Dynamic views use version-selection rules only and ignore any load rules.
Load rules specify which elements are copied into the view.
Version-selection rules specify the version that is visible in the view.
Figure 1 illustrates how ClearCase® interprets the load rules to select the version of the file that is visible through your snapshot view.
Figure 2 illustrates how Rational® ClearCase interprets the load rules to select the version of the file that is visible in your view.
For each element, the config spec attempts to locate a version that matches a config spec rule. If no version of the element matches any of the rules, the element is not accessible through the view.
Understanding the role of the config spec
Config specs are used to achieve a degree of control over project work.
Project managers use config specs for any of the following reasons:
- To control which versions developers see and what operations developers can perform in specific views.
- To prohibit checkouts of all selected versions or restrict checkouts to specific branches.
Understanding the default config spec
The default config spec defines a dynamic configuration which selects checked-out or the latest version of every element on the main branch throughout the entire source tree by any developer.
The following two lines are the default config spec rules:
element * CHECKEDOUTelement * /main/LATEST
The first rule selects the checked-out version of the element in your view.
The second rule selects the latest version of that element on the main branch.
If another team member checks in a new version of an element on the main branch, the new and latest version appears immediately if your view is a dynamic view, and you do not have the element checked out.
With a snapshot view, the new version on the main branch becomes visible when you update your view.
Understanding include files
Rational® ClearCase® supports an include file facility, which makes it easy to ensure that all team members use the same config spec.
Include files contain config spec rules and are placed in a public location. Subsequently, team members replace their default config spec with a one-line rule that points to the include file.
Include files are identified by the .csp extension; however, include files are not required to have the .csp file extension.
For example, the config spec to be used by all team members is called major.csp and is located in a publicly accessible location /public/c_spec/. Each team member replaces the content of their config spec with the following line:
Windows
include \\main_svr\public\c_spec\major.csp
UNIX
include /public/c_spec/major.csp
If you create config specs to be shared between UNIX and Windows computers, where VOB tags are different, you must have two includes files, or you must store the include file in a UNIX directory that is accessible from both platforms.
No comments:
Post a Comment