在实际情况中常常会出现客户发来缺陷报告，指明在某一个版本上出现了缺陷，这时需要我们重新搭建环境来进行缺陷重现，过程中需要重现历史版本。在前文中提到，针对需要重现的历史版本，如果所需要的所有配置项都打上了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这一行只匹配目录配置项。
<!--[if !supportLists]-->1.3 <!--[endif]-->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中。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
