扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者:呐喊 来源:CSDN 2008年3月24日
关键字: 项目管理 ClearCase Config_Spec 规则
在本页阅读全文(共19页)
在创建一个非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:eb
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 "[662988dbd7e
element "[662988dbd7e
element "[662988dbd7e
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规则由以下几类组成:
<!--[if !supportLists]-->1. <!--[endif]-->标准规则块:1至多行,每行均以element为开始,每行为一个配置项版本匹配规则。
<!--[if !supportLists]-->2. <!--[endif]-->控制规则块:包括分支与时间两种,包括控制头、控制尾与内嵌标准规则块。
<!--[if !supportLists]-->3. <!--[endif]-->Include规则块:以include开始,将外部文件定义的规则加载。
<!--[if !supportLists]-->4. <!--[endif]-->Load规则块:以load为开始,决定加载哪些配置项。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者