ClearCase Config_Spec概述(1)
我前一段时间写的,在CSDN的BLOG中,转过来
本文欢迎任何非商业转载行为，要求转载必须转载全文，并加明作者，出处，谢谢！
什么是Config_Spec
在应用UCM模式使用ClearCase进行配置管理时，基于Stream创建视图，这时视图是Stream上所有配置项当前版本状态的集合，对于开发人员，这是非常方便的。现在我们有个小问题需要解决：以前我们创建了一个基线，现在我们只是想看一下这个基线中的某个Component所有配置项所对应的版本具体内容，应该如何做呢？创建一个新的Stream，包括所要查看的Component，将Component的Configuration设置为这个基线，然后基于这个Stream创建一个视图，现在我们可以看到了这些配置项对应指定基线的版本。很好，现在有许多UCM Project，有许多基线，我们要看到许多不同的基线所对应的内容，还是要创建许多的Stream吗，这显然不是个好方法。同时，如果我们基于Base ClearCase进行配置管理，如何在视图中体现出需要展现的分支呢？如果我们使用命令行来创建一个视图，之后再看一下这个视图所映射的配置项的当前版本，我们会发现，看到的只是Main分支上最后的版本，这个问题我们要如何解决呢？
IBM Rational ClearCase提供了方法来解决这些问题，就是Config_Spec，Config_Spec描述了视图所展现的配置项的版本的规则。现在我们回到前面的两个问题，想看某一条基线的具体内容，很简单，不需要创建 Stream，简单的创建一个视图，修改视图的Config_Spec，让这个视图展现基线就可以了。基于Base ClearCase进行配置管理情况下，我们创建一个视图后，可以修改Config_Spec，根据需要自由的组合配置项的版本映射到视图，这是一个很大的优点，所以许多有积累的公司更愿意使用Base ClearCase进行配置管理。
在创建一个非UCM模式的动态视图后，我们可以通过命令行或图形界面看一下它的Config_Spec：
element * CHECKEDOUT
element * /main/LATEST
这是Base ClearCase视图缺省的Config_Spec，第一行的含义是如果在当前视图任何配置项执行了Check out操作，则选择配置项的被Check out的版本；第二行的含义是选择在main分支上最新的未Check out的版本。
IBM Rational ClearCase的随机文档cc_ref.中是这样描述版本选择规则的：在决定视图上配置项的版本映射时，对这些版本选择规则从上向下检查，首先检查所有被Mount上的VOB中的配置项是否有符合第一行规则的版本，如果有符合规则的版本，则将配置项的该版本映射到视图上，同时针对该配置项忽略以后和行的版本选择规则；如果配置项没有符合第一行规则的版本，检查被Mount上的VOB中不符合前面的版本选择规则的配置项是否有符合下一行规则的版本，重复检查直至检查完最后一行Config_Spec规则；最后就得到了所有已经Mount的VOB上的配置项在该动态视图上的版本映射。
但是在实际中要注意以下几点：在试验中发现如果没有element * /main/LATEST这最后一行，则任何配置项的版本都不会映射到视图上，如果只想将要符合前几行规则的配置项映射，而不想看到main分支上的配置项的最新版本，则可以将最后一行element * /main/LATEST改为element * /main/0就可以了。
现在，我们回到UCM类型的动态视图来看一下，如果我们针对某个UCM类型的动态视图执行一下cleartool catcs命令，例如，针对cuibz_test_int这个视图：
M:\cuibz_test_int>cleartool catcs
ucm
identity UCM.Stream oid:eb5f484d.d89f46d7.b702.04:7c:84:dd:66:88@vobuuid:7ffa1c
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 2005-10-17 9:13:36.
#
# Select checked out versions
element * CHECKEDOUT
# Component selection rules...
element "[662988dbd7e5485997c63b1eec4f62ed=\CBZTEST_VOB]/..." .../test_Int/LATET
element "[662988dbd7e5485997c63b1eec4f62ed=\CBZTEST_VOB]/..." Initial –mkbranch test_Int
element "[662988dbd7e5485997c63b1eec4f62ed=\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-included component backstop rule: no checkouts
element * /main/0 -ucm -nocheckout
#UCMCustomLoadBegin - DO NOT REMOVE - ADD CUSTOM LOAD RULES AFTER THIS LINE
我们会发现，原来UCM类型的动态视图获取配置项的版本的规则也是通过Config_Spec来实现的，不过这些规则基本都是系统在创建Stream时自动生成的，之后所有在该Stream上所创建的View，都会应用这个版本选择规则。不过从这些Config_Spec规则的#UCMCustomElemBegin描述来看，我们也可以对这个Config_Spec进行修改，以满足我们的特殊要求。
我们回到前面什么是Config_Spec这一节的问题：我们如何方便的获取某个历史基线版本，例如；Baseline_For_Patch1_2006_02_21；我们可以简单的编辑刚创建的非UCM模式动态视图的Config_Spec，在第一行与第二行之间加上一行：
element * Baseline_For_Patch1_2006_02_21
现在刷新一下这个非UCM模式动态视图，就会发现，视图所映射的配置项版本基本上就是这条基线的内容。可能出现的问题是有些不需要的VOB的内容也被映射上了，将最后一行按前面提到的改为element * /main/0就可以解决这个问题。
前面谈到的是动态视图的Config_Spec，这些规则对于静态视图同样有效，静态视图与动态视图的不同的是多了一些规则行，这些规则行决定了符合前面定义的版本选择规则的配置项的版本中哪些被取到静态视图中，这就是Load规则。
现在我们来看一下Config_Spec规则结构，非UCM模式的Config_Spec规则由以下几类组成：
1. 标准规则块：1至多行，每行均以element为开始，每行为一个配置项版本匹配规则。
2. 控制规则块：包括分支与时间两种，包括控制头、控制尾与内嵌标准规则块。
3. Include规则块：以include开始，将外部文件定义的规则加载。
4. Load规则块：以load为开始，决定加载哪些配置项。
