1 如何利用Config_Spec
1.1 Base ClearCase应用
应用Base ClearCase进行软件开发，一定要用到Config_Spec，因为新建的General视图中显示了主分支main上的最后版本，要在需要的版本上进行修改一定要修改Config_Spec。
应用Base ClearCase做开发时，尽量每个完整的任务对应一个视图。这个视图开放权限可以让所有完成任务所需要的人员访问，在完成任务后，将所有修改打上相应的Label，备份Config_Spec并将这个视图删除。
根据需要可以给任务定义一个分支，需要注意，要使用分支前一定要在VOB中创建一个新的branch type；Config_Spec不能自动创建branch type，如果在VOB中没有，在Checkout时会报出错误。如果是多个VOB协同工作，最好定义一个Admin VOB，在Admin VOB定义一个Global Branch Type以协同。
如果可能最好是在以前确定好的一个Label上开始新的工作，这样可以不必维护复杂的Config_Spec；如果发现有多个任务需要的配置项的版本映射规则相同，但是会在此基础上创建不同的分支，则先创建一个视图，维护Config_Spec，选择公用的版本映射规则，但是在其中不要应用任何mkbranch选项，在此视图基础上打一个Label，之后将这个视图删除，在这个Label的基础上创建新的不同的Config_Spec以进行工作。例如：
element …\Config.java …/Support_Telecom/LATEST –time 18-AUG-2005
element …\config.xml …/Support_Telecom/LATEST –time 18-AUG-2005
element * …/Support_Telecom/LATEST
element * /main/LATEST
发现在对电信的支持过程中在2005年8月15日后第一个版本的Config.java与config.xml是正确的，其后修改错误，但是其他的配置项是正确的。
我们可以地这个View上为配置项打上label，Right_ For_Telecom_2006_4_29
新的任务是Telecom_New_Feature，则视图的Config_Spec可以如下
element * CHECKEDOUT
element * Right_Config_For_Telecom_2006_4_29 –mkbranch Telecom_New_Feature
ellment * /main/LATEST –mkbranch Telecom_New_Feature
需要注意，在最后一行要加上–mkbranch Support_Other，否则新增加的配置项会在main分支上。实际上可能需要多个-mkbranch，以保证分支的层次能够反映实际的情况。例如：Supprt_Other是Framework_2.5基础上进行的支持工作， Framewokr_2.5是主分支main的子分支，则应该写成：
element * CHECKEDOUT
element * Right_Config_For_Telecom_2006_4_29 –mkbranch Telecom_New_Feature
element * /main/Framework_2.5/ Support_Telecom/LATEST –mkbranch Telecom_New_Feature
element * /main/Framework_2.5/LATEST –mkbranch Support_Telecom
ellment * /main/LATEST –mkbranch Framework_2.5
这样会保证新增加的配置项会从主分支main下一层层的创建子分支，直到/main//Framework_2.5/ Support_Telecom/ Telecom_New_Feature。
在实际的项目中，Config_Spec远比本文描述的复杂，需要根据实际情况做调整。
历史版本重现
在实际情况中常常会出现客户发来缺陷报告，指明在某一个版本上出现了缺陷，这时需要我们重新搭建环境来进行缺陷重现，过程中需要重现历史版本。在前文中提到，针对需要重现的历史版本，如果所需要的所有配置项都打上了Label，则通过Config_Spec是非常简单的事情。例如，以下Config_Spec可以将Framework_2.5_patch1这个版本取出：
element * Framework_2.5_patch1 –nocheckout
element * /main/0 –nocheckout
我们发现和以前的Config_Spec不同的是，没有了element * CHECKEDOUT这行，而且每个匹配规则下也加上了-nocheckout选项，这是因为这个视图创建的目的只是为了获取版本，而不是修改，这样可以防止误操作而得到了错误的版本。
但是一般情况下Patch的Label不会打上所有配置项，而是只打上修改的配置项的相应版本，改进Config_Spec如下：
element * Framework_2.5_patch1 –nocheckout
element * Framework_2.5 -nocheckout
element * /main/0 -nocheckout
这种情况下，如果2.5版本中没有这个Bug，只是Patch1修改所引起的，想看到修改了哪些版本，一般人认为第一个Config_Spec就可以了，但是发现没有显示任何内容，这是为什么呢？
因为在ClearCase中，目录也是配置项，在修改过程中，可能没有增加任何配置项，所以patch的Label没有打在任何目录上。所以看不到任何内容。我们可以修改如下：
element * Framework_2.5_patch1 –nocheckout
element –directory * Framework_2.5 -nocheckout
element * /main/0 -nocheckout
这时我们就可以看到了修改的内容，前题是Framework_2.5这个Label打到了所有的相关配置项上，包括目录配置项。
element –directory * Framework_2.5 –nocheckout这一行只匹配目录配置项。
UCM应用中的调整
由于应用Base ClearCase进行开发对ClearCase配置管理工程师的要求比较高，所以许多公司应用UCM方式进行开发，但是在开发过程中有时会出现一些问题，当前Stream上有的些版本与其他Stream上的有些版本合并在一起才是所需要，而这些配置项在同一个Component中，不能通过基线的组合达到要求，这时就要利用Config_Spec进行调整。
先创建一个General视图，根据需要修改Config_Spec，之后在这个视图上打上Label，再执行Component的Import Label将这个Label转换为UCM的基线，以这个基线为基础新建一个project就可以达到要求。
例如：
element …\Config\... …/Patch2/LATEST -nocheckout
element * …/Patch3/LATEST -nocheckout
element * …/Framework_2.5/LATEST -nocheckout
element * /main/0 –nocheckout
这个Config就可以满足将Patch2的Config目录Patch3的其他修改结合的任务。
需要注意的是mklabel后必须将这个Label引入，否则不能应用到UCM中。
