Rules of clearcase config_spec

This article welcomes any non-commercial reprinting behavior. Requirements: The full text must be reprinted and the author should be added. The source is correct. Thank you!

After creating a dynamic view in non-UCM mode, we can view its config_spec through the command line or graphic interface:

Element * checkedout

Element */main/latest

This is the default config_spec in the base clearcase view. The first line indicates that if the check out operation is performed on any configuration item in the current view, select the version of the check out configuration item; the second line indicates that the latest version not checked out is selected on the main branch.

IBM Rational clearcase's random document cc_ref. the version selection rules are described as follows: when determining the version ing of configuration items on the view, check these version selection rules from top to bottom, first, check whether all the configuration items in vob on the Mount have versions that comply with the rules of the first line. If there are versions that comply with the rules, map the version of the configuration item to the view, the version selection rules for future and row are ignored for this configuration item. If the configuration item does not comply with the version of the first row rule, check whether the configuration items on the mounted vob do not comply with the previous version selection rules have versions that comply with the rules of the next row. Repeat the check until the last config_spec rule is checked; finally, we get the version ing of all the configuration items on the mounted vob on the dynamic view.

However, pay attention to the following points in practice: if the last line of element */main/latest is not found in the experiment, the versions of any configuration item will not be mapped to the view, if you only want to map configuration items that match the rules of the first few rows, but do not want to see the latest configuration items on the main branch, you can change the last line of element */main/latest to element */main/0.

Now, let's go back to the dynamic view of the UCM type. If we execute the cleartool catcs command for a dynamic view of a UCM type, for example, for the view cuibz_test_int:

M:/cuibz_test_int> cleartool catcs

UCM

Identity UCM. Stream OID: EB 5f 484d. d 89f 46d7. b702.04: 7c : 84: DD: 66: 88 @ vobuuid: 7ffa 1c

3.25884205.996e.90: 64: A3: 78: D4: 22 1

 

# Only edit this config spec in the indicated "Custom" Areas

#

# This config SPEC was automatically generated by the UCM stream

# "Test_int" at 9:13:36.

#

 

# Select checked out versions

Element * checkedout

 

# Component selection rules...

 

Element "[662988dbd7e 5485997c 63b1eec 4f 62ed =/cbztest_vob]/... ".../test_int/latet

Element "[662988dbd7e 5485997c 63b1eec 4f 62ed =/cbztest_vob]/... "Initial-mkbranch test_int

Element "[662988dbd7e 5485997c 63b1eec 4f 62ed =/cbztest_vob]/... "/main/0-mkbranch test_int

 

End UCM

 

# Ucmcustomelembegin-do not remove-add custom element rules after this line

# Ucmcustomelemend-do not remove-end custom element rules

 

# Non-writable ded component backstop rule: no checkouts

Element */main/0-UCM-nocheckout

 

# Ucmcustomloadbegin-do not remove-add custom load rules after this line

 

We will find that the rules for obtaining the version of the configuration item from the original dynamic view of the UCM type are also implemented through config_spec, but these rules are basically automatically generated when the system creates the stream, all views created on the stream will apply this version selection rule. However, from these config_spec rules# UcmcustomelembeginWe can also modify config_spec to meet our special requirements.

Let's go back to the previous question about config_spec: how can we easily obtain a historical baseline version, for example, baseline_for_patch1_2006_02_21; we can simply edit the config_spec of the newly created dynamic view in non-UCM mode, and add a line between the first line and the second line:

Element * baseline_for_patch1_2006_02_21

Refresh the non-UCM mode dynamic view and you will find that the configuration item version mapped to the view is basically the content of this baseline. The possible problem is that some unwanted vob content is also mapped. Changing the last line to element */main/0 as mentioned above can solve this problem.

We have discussed the config_spec of the dynamic view. These rules are equally valid for the static view. The difference between the static view and the dynamic view is that there are more rule rows, these rule lines determine which versions of the configuration items that comply with the previously defined version selection rules are obtained in the static view. This is the load rule.

Now let's take a look at the config_spec rule structure. The config_spec rules in non-UCM mode are composed of the following types:

1. Standard Rule block: 1 to multiple rows, each row starts with an element, and each action matches a configuration item version.

2. Control Rule block: Includes branch and time, including control header, control tail, and embedded Standard Rule block.

3. Include rule block: starts with include and loads rules defined by external files.

4. Load rule block: starts with load and determines which configuration items to load.