IBM Rational UCM模式

           企业软件变更管理系统的搭建

           具体项目与产品开发流程的确定

           UCM模式在软件产品线上的应用

           配置管理存储库的物理视图与逻辑视图

           ClearCase Administrator

           ClearQuest Administrator

课程对象

本课程适用于配置管理人员，项目经理，架构师。

前提课程

·         软件开发流程与Rational UCM模式

后续课程

·         高级变更管理

《中级变更管理》课程日程安排

此课程包括讲授和实验，共安排五天，如下表：

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远比本文描述的复杂，需要根据实际情况做调整。

1.2           历史版本重现

在实际情况中常常会出现客户发来缺陷报告，指明在某一个版本上出现了缺陷，这时需要我们重新搭建环境来进行缺陷重现，过程中需要重现历史版本。在前文中提到，针对需要重现的历史版本，如果所需要的所有配置项都打上了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这一行只匹配目录配置项。

1.3           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中。

1.1         UCM规则

一般情况下，不要修改UCM规则，而且ClearCase的公开文档中没有对UCM规则的描述，本文只是作者对UCM规则的试验与理解获得，不保证正确性。

以下是一个UCM 视图的Config_Spec：

ucm

identity UCM.Stream oid:9fd98bf2.f8be42ba.90b8.b4:5c:bd:2c:8d:66@vobuuid:3073f95a.f08a45d2.bc05.ea:ff:4e:97:8b:ea 1

# ONLY EDIT THIS CONFIG SPEC IN THE INDICATED "CUSTOM" AREAS

#

# This config spec was automatically generated by the UCM stream

# "Only_Comp1_Int" at 2006-4-19 13:17:50.

#

# Select checked out versions

element * CHECKEDOUT

# Component selection rules...

element "[0a71c94ae2f74f80a1a7e70ef7722ca1=/Train]/Comp1/..." .../Only_Comp1_Int/LATEST

element "[0a71c94ae2f74f80a1a7e70ef7722ca1=/Train]/Comp1/..." /main/0 -mkbranch Only_Comp1_Int

element "[0a71c94ae2f74f80a1a7e70ef7722ca1=/Train]/Comp1/..." /main/0 -mkbranch Only_Comp1_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与end ucm标识了UCM规则的开始与结束。在其内的所有规则块的解释都按UCM规则进行。

1.1.1            Inentity UCM.Stream

identity UCM.Stream描述了该视图所attach的Stream的信息，这样，视图的SetActivity、Checkout、Chekcin等操作可以关联到Stream上。

identity UCM.Stream格式如下：

identity UCM.Stream streamoid@vobuuid 1

其中Streamoid应用ClearCase内部数据库信息描述，以oid:为头，之后加上了Stream的UUID。Vobuuid以vobuuid:加上PVOB的UUID。

可以应cleartool describe看一下信息，例如：

Cleartool describe –short  oid:9fd98bf2.f8be42ba.90b8.b4:5c:bd:2c:8d:66@vobuuid:3073f95a.f08a45d2.bc05.ea:ff:4e:97:8b:ea

得到的结果与cleartool describe –short stream:Only_Comp1_Int@/Train_PVOB一致。

在实验中，可以将streamoid@vobuuid替换为Only_Comp1_Int@/Train_PVOB，结果与原UCM 视图显示内容一致。

需要注意在streamoid@vobuuid之后需要加上空格与1，否则会不符合规则，含义不明。

1.1.2            Component选择规则

在UCM 视图中，除了应用element * CHECKEDOUT获取当前视图所有Checkout的配置项外，其他配置项都通过Component选择规则获取，每个Component包括三行，可以有多个Component；第一行格式如下：

element “[vobuuid=/VOB tag ]/Component name/…” …/Stream_branch/LATEST

其中vobuuid为Component所在的VOB的UUID，VOB tag为Component所在VOB在当前Region的tag，如果是单一Component的VOB，则没有Component name；…则是选择当前Component下的所有配置项，包括目录与文件配置项；Stream_branch为当前Stream的名称，因为相应分支名称采用了Stream的名称，因为不知道可能在哪层上创建，所以在前面加上了…。该行的目的获取所有在该分支下的配置项。

第二行格式如下：

element “[vobuuid=/VOB tag ]/Component name/…” foundation_baseline –mkbranch Stream_branch

如果是集中流，foundation_baseline为Stream初时创建时所选择的Component的baseline，如果是开发流，而且从集成流上rebase了recommended baseline，则会是Recommend Baseline；可以用命令cleartool lsstream -l获取流的foundation baselines。该行的目的是匹配所有foundation baseline的配置项，如果Checkout，在baseline选择的版本分支下则自动创建该流的分支。如果在创建Stream时所选择的Component是一个空的Component，则foundation_baseline改为/main/0。

第三行的格式如下：

element “[vobuuid=/VOB tag ]/Component name/…” /main/0 –mkbranch Stream_branch

该行的目的是，如果创建新的Element，则会在主分支main下创建一个Stream分支。

1.1.3            其他规则

在UCM 视图中可以让用户自行添加一些规则，这就是CustomElem规则，在UCM 视图的Config_Spec中两行注释，在中间可以添加规则，这些不会被自动清除。

#UCMCustomElemBegin - DO NOT REMOVE - ADD CUSTOM ELEMENT RULES AFTER THIS LINE

#UCMCustomElemEnd - DO NOT REMOVE - END CUSTOM ELEMENT RULES

这两行注释置于Component选择规则之后，这样保证了配置项版本优先选择Stream的，在这里需要注意，只能选择 Stream所不涵盖的配置项，因为Component选择规则在先，Stream所涵盖的配置项的版本已被选中，在其后的规则将会被忽略。

在UCM 视图的Config_Spec中有以下一行：

element * /main/0 -ucm -nocheckout

这一行保证了不会将已Mount的VOB下的配置项显示出来，因为/main/0的含义是初始，为空。

Include规则

格式如下：

include config-spec-pname

将指定的文件包括的Config_Spec规则读入。

当应用执行 setcs或edcs时，会重新装入文件，这时如果指定文件的内容改变，相应的规则也会改变。

Include规则必须在一行的结束，以下两种格式均符合要求：

include config_spec.txt;

element * CHECKEDOUT; include config_spec.txt

而以下格式不符合要求：

       Include config_spec.txt; element * /main/LATEST

需要注意，与time规则不同的是，执行startview或是 View Server机器重新启动都不会重新装入文件，如果需要更新，必须执行setcs或edcs命令。

静态视图装载规则

格式如下：

Load pname

目的是将指定的配置项的符合Config_Spec的版本下载到静态视图。如果在动态视图中应用该规则，会被忽略，但是不会触发任何错误。

pname可以是目录配置项也可以文件配置项，必须是全路径，不能应用通配符。

         控制规则块

控制规则块是笔者自己的定义，ClearCase给出的标准说明是时间规则块与分支规则块。这些规则块设置的目的是如果有几个配置项选择中有相同的-time或-mkbranch选项，则可以使用时间规则块与分支规则块，下面分别描述这时间规则块与分支规则块。

1            时间规则块

格式如下：

time date_time

规则行

end time [ date_time ]

其中匹配规则可以是标准规则块，也可以包括控制规则块与其他规则块。如果在其中再次嵌入时间规则块，则在嵌入的规则块内遵守嵌入的时间定义，嵌入结束后，遵守外层的定义。例如：

       element * CHECKEDOUT

time 17:02

element .../test3.txt /main/Test_Config_Spec/LATEST

time 17:00

element .../test1.txt /main/Test_Config_Spec/LATEST

end time 17:00

element .../test4.txt /main/Test_Config_Spec/LATEST

end time 17:02

element * /main/Test_Config_Spec/LATEST

element * /main/LATEST -mkbranch Test_Config_Spec

等同于以下规则块：

element * CHECKEDOUT

element .../test3.txt /main/Test_Config_Spec/LATEST –time 17:02

element .../test1.txt /main/Test_Config_Spec/LATEST –time 17:00

element .../test4.txt /main/Test_Config_Spec/LATEST –time 17:02

element * /main/Test_Config_Spec/LATEST

element * /main/LATEST -mkbranch Test_Config_Spec

如果最后一个时间规则块没有定义end time，则一直到最后一行，时间规则都起作用。end time后一般可以不加上date_time，但是如果有嵌套，最好加上时间描述，描述要与向上找到的第一个未匹配的time所描述的时间一致。

如果在时间规则块内嵌的匹配规则带有-time选项，则匹配规则自带的time选项生效，而时间规则对这个带time选项的匹配规则无效。

2            分支规则块

格式如下：

mkbranch branch-type-name [ –override ]

规则行

end mkbranch [ branch-type-name ]

等同于每个规则行后加上-mkbranch branch-type-name。如果内部的规则行带有-mkbranch选项，且没有使用-override，则应用内部规则行自带的mkbranch选项，如果应用-override，则会将定义的分支覆盖内部规则行自定义的mkbrranch选项。如果内部规则行是CHECKEDOUT，则mkbranch无效。

分支规则块可以嵌套，在嵌套的情况下，最好在end mkbranch后加上分支的名字；ClearCase会向上第一个未匹配的mkbranch，如果名字不一致，会提示错误，以防止出现误操作。

分支规则内可以再嵌套分支规则块，会创建多层的分支。例如：

element * CHECKEDOUT

element * /main/Test_Config_Spec/Test_Config_Spec_Sub/LATEST

mkbranch Test_Config_Spec

mkbranch Test_Config_Spec_Sub

element * /main/Test_Config_Spec/LATEST

end mkbranch Test_Config_Spec_Sub

element * /main/LATEST

end mkbranch Test_Config_Spec

这个分支等同于

element * CHECKEDOUT

element * /main/Test_Config_Spec/Test_Config_Spec_Sub/LATEST

element * /main/Test_Config_Spec/LATEST –mkbranch Test_Config_Spec_Sub

element * /main/LATEST –mkbranch Test_Config_Spec

在这种情况下在所选择的配置项版本将会检查是否有分支，如果没，则会建立新分支。

标准版本选择规则的格式如下：

scope pattern version-selector [ optional-clause ]

一行可以有多个标准规则，以分号间隔。

所有scope均为针对配置项，所以都以element开始，可以设置-file、-directory与-eltype参数。

如果element不包括任何参数，则之后的pattern verion-selector [ optional-clause ]对任何配置项都有效，-file、-directory分别只对文件配置项、目录配置项起作用；-eltype后与指定的配置项类型有一空格间隔，例如：–eltype text_file，表明之后的匹配规则只对text_file类型的配置项起作用；如果一个eltype包括一些一些子eltype，只对本eltype有效，例如：-eltype file不对text_file类型配置项有效。

pattern为配置项匹规则，可以以下使用通配符：

a) ?                匹配任何符合命名规则的单个字符，例如：a?c，则可以匹配a1c，aAc与a.c，等，但是不匹配ac、与a/c。

b) *        匹配0至符合命名规则最大长度的任何符合命名规则的字符，这些字符不必一致，与?不同的是，*可以匹配0个字符，例如：*src*，匹配TheSrc，src1，src。

c) ~       对应根目录。

d) [abc]   对应[]内的任何一个字符，例如：C*[gs].java，匹配Config.java与Constants.java。

e) [a-z]    对应[]内ASCII编码位于-之前字符与-之后字符之间的一个字符，包括-之前与之后的各个字符，例如：t[a-e]st匹配tast、tbst、tcst、tdst与test。

f) …       匹配0至符合规则要求的任意多层目录，例如：src/…/Config.java，匹配以下配置项：

                            src/com/Config.java

                            src/com/test/Config.java

                            src/Config.java

                     如果匹配规则为src/…，则包括src目录及它所有的子目录。

以上通配符可以组合，例如：匹配符 src/…/C[a- z][A-Z].java匹配以下配置项：

                            src/com/CaA.java

                            src/com/test/CoT.java

Version-selector描述了针对配置项的版本选择规则，有以下三种版本选择规则：

a)    分支名称加版本号：如/main/0，就表示main分支上版本0，这是一个空的版本，而/main/test/1则表示了main分支下test分支下的第1个版本。

b)   分支名称加Label：如/main/test/MyLabel2，则寻找的是所有main/test分支下被打上MyLabel2的配置项的版本。也可以只有Label，则会寻找所有分支上被打上该Label的配置项的版本，如果在多个分支上同一个配置项有多个版本打上了该Label，则会出现错误。例如：有一个预定义的LABEL：LATEST，/main/LATEST是表明main分支上的最新的版本，但是LATEST并不是版本号，而是预定义的Label，每个分支的最新版本都具有这个 Label；这里就要注意，不能应用 …/LATEST，这表明选择所有分支上最后的版本，会发生冲突，如果在你的config_spec中出现以上版本选择规则，一般情况下会报出一个view server的致命错误。

c) 分支名称加上查询选项：如/main/test/{TESTED==yes}，寻找的是在main/test分支下最后一个TESTED属性为yes的版本。与Label一样，也可以只有查询选项，但是也一样要求不能出现冲突。

在Version-selector中的几个特殊的规则：

a) CHECKEDOUT：匹配当前视图被Checkout的版本，如果是文件配置项，则是与配置项名称相同的视图私有文件。

b) –config：匹配由clearmake或omake生成的Derived Objects，可以指定不同版本的配置项所对应的不同的Derived Objects。

c) –none：这个匹配规则主要是针对Unix操作系统，在Windows下设置了，如果不应用cleartool ls，则不会发现配置项的存在，而在UNIX系统下，会产生一个ENOENT（没有这样的文件或目录）的错误。应用cleartool ls会提示：[no version selected]。

d) –error：这个匹配规则与上一个一样是针对Uni操作系统的；应用cleartool ls会提示：[error on reference]。

最后是可选项：optional-clause。包括以下可选项：

a) –time：这个可选项的应用一定要在Version-selector中有LATEST这个标签才有效，如果没有这个标签，则不会提示错误，但是也不会起作用。

-time后要加上日期与时间，表示从LATEST向上查找，找到一个最近一个从指定日期与时间之后创建的版本，如果在指定的日期和时间时配置项还不存在，则不会给出初始空版本，而是匹配LATEST版本。

日期与时间的格式如下：

date.time | date | time | now

以上因项是互斥的，可以在后面加上UTC，这样时间为格林威治标准时间，可以避免时区的影响。如果没有指定日期，则缺省设置为today；如果没有指定时间，则缺省设置为00:00:00。需要注意，日期在执行完setcs就自动转变为标准日期，如果设置为today，同一个视图没有执行endview操作，一周以后，匹配规则找的是前一周时间的版本，而不是最近的版本，所以如果设置了-time选项，且应用了today等方式设置日期，最好执行endview后再执行startview，这时会重新设置日期。

以下是日期与时间的规则。

date :=day-of-week | long-date

time :=h[h]:m[m][:s[s]] [UTC [ [ + | - ]h[h][:m[m] ] ] ]

day-of-week :=today |yesterday |Sunday | ... |Saturday |Sun | ... |Sat long-date :=d[d]–month[–[yy]yy]

month :=January |... |December |Jan |... |Dec

例如：.../Config.java /main/Only_Comp2_Int/LATEST -time 10:00，匹配的是最近一次设置Config_Spec或StartView当天10:00以后main主分支下Only_Comp2_Int分支下任何Config.java的第一个版本。

       Time中now是一个特殊格式，指定的当前时间。

b) –nocheckout：所选择的配置项不显示Checkout版本，所对应的配置项的规则必须位于element * CHECKEDOUT的上面，如果第一行是element * CHECKEDOUT，则-nocheckout设置无效；可以删除lement * CHECKEDOUT，也可以修改element * CHECKEDOUT，不再匹配任何配置项。如果配置项确实有checkout的版本，则会在视图提示Eclipse，即有checkout状态的配置项，但是不能显示。

c) –mkbranch：如果一个匹配前面版本选择规则的配置项的版本被Checkout时，自动建立配置项的指定分支。格式如下：

       -mkbranch branch-type-name

需要注意，这里的branch-type-name必须在VOB中已经定义，如果没有定义会出现错误，无法执行Checkout操作。同时对版本选择规则为-none或-error的不起作用。

在创建一个非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为开始，决定加载哪些配置项。

本文欢迎任何非商业转载行为，要求转载必须转载全文，并加明作者，出处，谢谢！

什么是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进行配置管理。

ClearCase Administrator不等同于配置管理工程师，ClearCase Administrator要负责ClearCase系统的建立与维护事宜，而配置管理工程师则是负责具体的配置管理工作，如基线的建立、配置项的追踪等，ClearCase Administrator与配置管理工程师两个职责可以由一个人同时负责，但是需要明确，这是两个不同的职责。

1.1   ClearCase Administrator的职责

ClearCase Administrator的职责主要有以下几部分：

•    ClearCase系统部署与网络管理

• 制订ClearCase配置管理方
• 部署ClearCase配置系统，安装/配置ClearCase Server
• 制作ClearCase安装包，指导开发人员安装ClearCase客户端。
•  ClearCase Server调优

• ClearCase数据管理

• • ClearCase数据备份与恢复
  • ClearCase数据迁移
  • ClearCase Storage管理
  • ClearCase数据定期维护
  • ClearCase数据存储安全管理
    
• ClearCase用户管理
  • 制订权限控制方案
  • 管理用户与组
  • 解决权限问题
• ClearCase License管理
  • License Server建立与维护
  • 管理License
  • License设置，包括时间、优先级等

可以设置Trigger的ClearCase 操作

声明：在本文中描述的Trigger在实际应用中需要做修改，如果直接应用可能会产生不明后果，本文作者对此概不负责。

首先我们来看一下应用UCM模式的Trigger。UCM中Rational 已经提供一些基本的流程定制，可以简化我们创建分支、版本归并的许多操作，但是每个项目都是独一无二的，对于复杂的项目，UCM不能完全满足需要。所有UCM类型的操作基本对应同样Cleartool子命令，其中Deliver类、Rebase类及mkbl_complete操作是特例，这些操作不对应具体的cleartool子命令。针对UCM模式有以下几类ClearCase操作：

1.        Deliver：将源流的修改提交到目标流；创建Trigger可以针对deliver_start，deliver_cancel，deliver_complete这三个操作；cleartool deliver子命令会引起这几个操作；Deliver包括Deliver from Stream与Deliver Baseline两种。在创建完Trigger后，需要将Trigger关联到目标流上，Trigger才能起作用。在创建针对Deliver操作的Trigger时只能设置Stream与Project进行约束。

2.        Rebase：从源流获取最新的修改；其中包括rebase_start，rebase_cancel，rebase_complete这三个操作。与Deliver操作类似，在创建完Trigger后，需要将Trigger关联到目标流上，Trigger才能起作用。在创建针对Rebase操作的Trigger时只能设置Stream与Project进行约束。

3.        Activity：其中包括mkactivity，chactivity，rmactivity，setactivity这四个操作。其中针对mkactivity的Trigger需要关联到要创建活动的流，其他三个操作的Trigger需要关联到要操作的活动。在创建针对Activity操作的Trigger时只能设置Stream与Project进行约束。

4.        Stream：其中包括mkstream，chstream，rmstream这三个操作。其中针对mkstream的 Trigger需要被关联到要创建流的project，其他两个操作的Trigger需要关联到被操作的流。同时，在创建针对mkstream操作的Trigger只能设置Project进行约束，而对其他两个操作可以设置Stream与project约束条件。

5.        Baseline：其中包括mkbl，mkbl_complete，chbl，rmbl这四个操作。mkbl_complete操作是一个特例，从cleartool mkbl子命令来看，针对的是Component，而mkbl_complete是对一个Stream上所有的Component打上baseline的操作，可以理解为在图形界面下，针对一个Stream执行Make Baselines。所以针对mkbl_complete 的Trigger必须关联到要执行Make Baselines的Stream上，其他三个操作都要被关联到与Baseline有关的Component上；针对mkbl与mkbl_complete操作，可以设置Stream、Component与Project约束条件，针对另两个操作只可以设置Component与Project 约束条件。另外针对mkbl，如果在环境变更中CLEARCASE-PROJECT与CLEARCSE_STREAM都没有被定义，则针对Component执行Import Label时也会触发Trigger。

6.        Project：其中包括mkproject，chproject，rmproject这三个操作。其中针对mkproject操作的trigger需要关联到PVOB，并且不能设置约束条件，另两个条件则需要关联到被操作的Project上，并可以针对Project设置约束条件。

7.        Component：其中包括mkcomp与rmcomp这两个操作。针对这两个操作的trigger需要被关联到PVOB，并且不能设置约束条件。

8.        其他：其中包括mkfolder，chfolder与rmfolder这三个操作。针对这些操作的的Trigger需要被关联要操作的Folder，并且可以设置project约束条件。

在前面根据需要定制Trigger一节，描述了我对Deliver操作的理解，这里我们仔细看一下，针对Deliver的操作我们可以定制哪些Trigger，需要注意这些Trigger都比较简单，是针对某一项非常明确的需求，在具体应用时要加以组合成为一个Trigger。

1.        deliver_start：Stream的 Policy中有一些设置可以理解为已设置好的Trigger，deliver_start这个操作的事前触发的Trigger在检查完Project及Stream的Policy之后才会被触发，所以没有必要在这里设置Trigger检查源流是否有未Check in的配置项、是否执行了Rebase操作等，这些可以通过设置Stream的Policy来解决；针对deliver_start，可以设置以下Trigger：

a)        事前触发(preop)的Trigger，检查是否有Deliver的权限：Cleartool mktrtype –ucmobject c "Only Cuibz could execute deliver opeartion" -element -preop deliver_start -nusers cuibz -execunix "Perl -e /"exit -1;/"" -execwin "ccperl -e /"exit (-1);/"" deliver_check；之后我们可以将这个Trigger关联到相应的流上，需要注意的是Deliver及Rebase类型操作的Trigger要关联到要Deliver或Rebase的Stream上，即目标流，否则不会起作用；cleartool mktrigger deliver_check stream:test_Int@/Test_PVOB，这里你可以根据实际情况修改stream。如果目标流上只允许有deliver权限的人员进行Deliver操作，则可以不设置这个trigger，而是简单的锁定目标流，同时将有权限的操作人员加入Excluded中即可。

b)        事前触发的trigger，锁定目标流，这样可以避免针对同一个配置项进行多个Deliver同时操作导致的Merge及Check out的Reserved及Unreserved的问题（对一个配置项只能有一个Reserved 类型check out操作，其他都为Unreserved操作，在Reserved类型check out没有check in之前，其他Unreserved类型的check out操作不能check in)；需要注意，如果认定了这个Trigger，则要有针对deliver_cancel及deliver_complete的事后触发的trigger，来对目标流及源流进行解锁。具体的Trigger如下：cleartool mktrtype –ucmobject –preop deliver_start –exec “cleartool lock –nusers %CLEARCASE_USER% stream:%CLEARCASE_STREAM%” -comment “Lock source stream except operater” deliver_lock_targetstream。其中lock命令的参数中-nusers %CLEARCASE_USER%的目的是在锁定目标Stream后，可以让deliver这个操作的发起用户不受影响，否则会无法执行deliver操作；%CLEARCASE_STREAM%是目标Stream，但是前面一定要加上stream:这个前缀，否则锁定时cleartool lock这个命令会无法识别，导致deliver操作被拒绝。

c)        事前触发的trigger，锁定源流，这样可以避免准备提交时，有用户check in不准备提交的版本；具体Trigger如下：cleartool mktrtype –ucmobject –preop deliver_start –exec “cleartool lock –nusers %CLEARCASE_USER% stream:%CLEARCASE_SRC_STREAM%” -comment “Lock target stream except operater” deliver_lock_sourcestream。%CLEARCASE_SRC_STREAM%是源Stream。你可以将这这个trigger与前一个trigger结合起来，同时锁定目标流与源流，具体trigger如下：cleartool mktrtype –ucmobject –preop deliver_start –exec “cleartool lock –nusers %CLEARCASE_USER% stream:%CLEARCASE_STREAM% stream:%CLEARCASE_SRC_STREAM%” -comment “Lock target and source stream except operater” deliver_lock_stream。

d)        事前触发的trigger，通过脚本对源流进行构建，以验证提交的源码的完整性，如果构建失败，则可以自动回滚deliver操作，并给出提示；这个trigger如果和下一个结合在一起可以支持在目标流上的Daliy Build工作。

e)        事后触发的trigger，对目标流进行构建，如果构建失败，则执行自动执行deliver –cancel回滚deliver操作；一般情况下建议和上一个trigger合并为一个trigger，先检测在源流修改是否可构建，再检测目标流上配置项经过merge后，是否可构建，这样可以支持在目标流上的Daliy Build工作。

f)         事后触发的trigger，对锁定的源流进行解锁。  Trigger如下：cleartool mktrtype -ucmobject –postop deliver_start –exec “cleartool unlock stream:%CLEARCASE_SRC_STREAM%” -comment “Unlock source stream” deliver_unlock_source_stream。

g)        事前触发的trigger，将deliver的发起人、源流、目标流、活动等信息发送邮件到相关人处。可以参见IBM Rational ClearCase随机帮助文档cc_proj.pdf。

h)        如果应用脚本等，还可以建议设置其他的trigger，如锁定源流上要提交的活动，或检查目标流上要进行归并的配置项是否处于check out状态等。

i)          检查目标流是是否有正在执行的Deliver操作。保证目标流上的Deliver是唯一的，这个脚 本在 IBM Rational ClearCase的随机帮助文档cc_proj.pdf中有，章节为Working  in UCM -> Using Trigger to Enforce Development Policies -> Enforce Serial Deliver Operations，读者可以自行查看。

2.        deliver_cancel：如果没有执行deliver_complete，则回滚deliver操作，针对这个clearcase操作，可以设置以下trigger：

a)        事前触发的trigger，检查权限，确保只有deliver操作发起者与配置管理人员才能进行回滚deliver操作，这样可以避免以下这种情况：一个deliver在进行中，其他人员由于尝试进行其他deliver导致回滚原deliver问题。

b)        事前触发的trigger，将deliver -cancel的消息发送到相关人员处。

c)        事后触发的trigger，对目标流、源流、活动等进行解锁，如果在deliver_start中设置了trigger对目标流、源流、活动等锁定，则回滚时一定要进行解锁。

d)        事后触发的Trigger：与事前触发的保证 Deliver操作唯一性的Trigger对应，同样参见IBM Rational CleaseCase的随机文档cc_proj.pdf。

3.        Deliver_complete：将目标流上check out的配置项check in，并打上隐藏的delivered基线，针对这个clearcase操作，可以设置以下trigger：

a)        事前触发的trigger，检查权限，确保只有deliver操作发起者与配置管理人员才能进行执行deliver -complete操作。

b)        事后触发的trigger，对应deliver_start相应的trigger，如果在deliver_start的trigger中锁定了目标流、源流或活动，则在deliver_complete后进行解锁。

c)        事前触发的trigger，对目标流进行构建，如果构建失败，则提示进行回滚，一般情况下建议如果在deliver_start中设置事后触发的trigger检查对目标流进行构建检查，则不必在deliver_complete设置此trigger。

d)        事后触发的trigger，将目标流打上baseline。

e)        事后触发的trigger，发起对目标流上所有静态视 图的update操作。

f)         事后触发的trigger，发送邮件通知相关人员，deliver已经完成，构建工程师可以进行构建及版本发布，测试人员可以开始测试工作。

g)        事后触发的trigger，自动对各个相关的流执行rebase，这个trigger需要注意，一般情况下只rebase推荐基线，刚deliver的不一定是稳定的基线，所以不建议使用该trigger。

针对其他UCM类型操作的Trigger可以参考IBM Rational ClearCase随机帮助文档cc_proj.pdf。

接着我们来看一下针对配置项的ClearCase操作有哪些可以定义Trigger；需要注意，和针对UCM对象的ClearCase操作不同，针对配置项的ClearCase操作并不等同于cleartool的子命令。针对配置项的ClearCasse操作有以下几类：

1.        Modify_ELEM：对配置项的修改，包括以下ClearCase操作

a)        checkout：Check out命令一定会导致这个操作，clearimport、findmerge、mkelem、mkbranch 与relocate命令可能会发起checkout操作。针对checkout操作，我们可以设置Trigger，发送通知有checkout操作进行，尤其是针对clearimport、findmerge、mkelem、mkbranch 与relocate操作，因为这些命令如果导致checkout操作，大多数情况下是增加配置项或更改配置项的目录等，这种情况需要通知相关人员。也可以用Trigger进行权限控制等。如果是多个开发人员在一个开发流上进行开发，也可以设置一个事后触发的Trigger，将所有Reserved类型的Checkout改为Unreserved类型，以防止针对同一配置项多人Check out后，如果Reserved Check out没有执行Check in操作，其他Check out都不能执行check in操作；针对checkout的Trigger除了设置配置项类型与分支类型的约束条件。

b)        chevent：为配置项关联的某个event修改注释，一般情况下只有chevent命令可以导致这个操作；针对这个操作，设置事前触发的Trigger只允许配置管理员执行可以防止对注释的错误修改。

c)        reserve：将unserved类型的checkout操作改为reserved类型的checkout操作，一般情况下可以设置一个事前触发的Trigger，防止开发人员任意修改操作导致其他开发人员必须等待，不能执行check in操作的问题。

d)        unreserve：将reserved类型的check out操作改为Unreserved类型的Check out操作；可以设置一个事前触发的Trigger，防止其他人修改check out类型，限制任意的check out操作，这个Trigger与reserve的Trigger是对立的；也可以设置一个事后触发的Trigger，邮件通知原check out操作人员，你的check out操作类型被修改了，其他人可以不等原操作者Check in就执行Check in操作了。

e)        uncheckout：回滚Check out操作；可以设置事前触发的Trigger，检查权限，只允许Check out操作人与配置管理人员执行该操作。

2.        MODIFY_DATA：包括以下ClearCase操作：

a)        Check in操作：check in、mkelem与mkbranch一定会导致这个操作，clearimport与relocate可能会导致这个操作。可以设置事前触发的Trigger，检查权限；也可以设置事后触发的Trigger，更新静态视图，可以应用脚本检查注释是否符合要求等。

b)        chtype：修改配置项的类型及各个Type，只有chtype会导致这个操作；可以设置事前触发的Trigger，检查权限。

c)        lnname：将配置项链接到某个目录配置项，ln、ln –s、mkelem、mkdir与mv一定会导致这个操作，relocate可能会导致这个操作；可以设置事前触发的trigger检查权限。

d)        lock：这里的lock只是针对配置项的lock，而不包括对Type及UCM Object；可以设置事前触发的trigger检查权限。

e)        mkbranch：产生新的分支；mkbrach、mkelem一定会导致这个操作，checkout、clearimport与relocate可能会导致这个操作；可以设置事前触发的trigger检查权限。

f)         mkelem：新建配置英；mkelem与mkdir一定会导致这个操作，clearimport与relocate可能会导致这个操作；可以设置事前触发的trigger检查权限。

g)        mkslink：在目录配置项下建立另一个配置项的Symbolic Link；ln –s一定会导致这个操作，可以设置事前触发的trigger检查权限。可以设置事前触发的trigger检查权限。

h)        protect：修改配置项的Owner、Group及权限；只有protect会导致这个操作；可以设置事前触发的trigger检查权限。

i)          rmbranch：删除分支；只有rmbranch会导致这个操作；可以设置事前触发的trigger检查权限。

j)          rmelem：完全的删除配置项；rmelem一定会导致这个操作，relocate可能会导致这个操作发生；再这里再一次介绍我认为最重要的Trigger，强烈建议所有的VOB都 要建立这个Trigger，禁止配置管理人员以外人员删除配置项：Cleartool mktrtype -c "Only Cuibz could execute rmelem" -element –all -preop rmelem -nusers cuibz -execunix "Perl -e /"exit -1;/"" -execwin "ccperl -e /"exit (-1);/"" rmelem_check。

k)        rmname：从一个目录配置项内移走一个配置项；rmname、rmelem与mv一定会导致这个操作；可以设置事前触发的trigger检查权限。

l)          rmver：删除配置项的某一个版本；rmver一定会导致这个操作，注意：checkvob –fix命令也可能会导致这个操作；同rmelem一样，建议一定要建立禁止配置管理人员以外人员删除版本的事前触发的trigger：Cleartool mktrtype -c "Only SCM could execute rmelem" -element –all -preop rmver -nusers cuibz -execunix "Perl -e /"exit -1;/"" -execwin "ccperl -e /"exit (-1);/"" rmver_check。

m)      unlock：对配置项进行解锁；可以设置事前触发的trigger检查权限。

3.        MODIFY_MD，有以下ClearCase操作：

a)        chmaster：主要是针对Multisite ClearCase的，修改配置项的Mastership；

b)        mkattr：将定义好的attribute关联到配置项；mkattr一定会导致这个操作，clearimport、mkhlink与relocate可能会导致这个操作发生；

c)        mkhlink：将定义好的hyperlink关联到配置项；mkhlink一定会导致这个操作，clearimport、findmerge、merge与relocate可能会导致这个操作发生；

d)        mklable：将定义好的label关联到配置项的某个版本；mklabel一定会导致这个操作，clearimport与relocate可能会导致这个操作发生；

e)        mktrigger；将定义好的Trigger关联到配置项；mktrigger一定会导致这个操作，relocate可能会导致这个操作发生；

f)         rmattr：取消配置项上关联的某个attribute；只有rmattr会导致这个操作；

g)        rmhlink：取消配置项上关联的某个hyperlink；rmhlink与rmmerge一定会导致这个操作的发生；

h)        rmlabel：取消配置项某个版本关联的label；只有rmlabel会导致这个操作的发生；

i)          rmtrigger：取消配置项关联的某个Trigger；只有rmtrigger会导致这个操作的发生；

针对以上这些操作，可以设置Trigger检查权限。

最后是针对Type的操作，前文提到针对Type操作的Trigger设置不需要应用mktrigger，下面我们来看一下有哪些针对Type的操作可以设置Trigger：

1.        chevent：修改Type对象事件的注释；

2.        chmaster：主要是针对Multisite ClearCase的，修改Type对象的Mastership；

3.        lock：锁定type对象；

4.        mkattr：将已定义好的将定义好的attribute关联到Type对象；

5.        mkhlink：将定义好的hyperlink关联到Type对象；

6.        mktype：定义一个新的Type类型；

7.        modtype：修改一个Type，mktype –replace可以导致这个操作；

8.        mklable：将定义好的label关联到Type对象的某个版本；

9.        mktrigger；将定义好的Trigger关联到Type对象；

10.    rmattr：取消Type对象上关联的某个attribute；

11.    rmhlink：取消Type对象上关联的某个hyperlink

12.    rmtype：删除某一个Type类型；

13.    rntype：修改某个Type的名称；rename可以导致这个操作的发生；

14.    unlock：对某个type对象解锁；

针对以上这些操作，可以设置Trigger检查权限。

由于篇幅所限，对具体的Trigger这里没有具体描述，所有的Trigger都应进行本地化定义。

在本文的最后，我要真诚的感谢SCM论坛Rational ClearCase分论坛的朋友，在2005年2月我开始写这篇文档，由于各种原因中断，在他们鼓励下我重新完成了这篇文档。

本文参考了IBM Rational ClearCase的随机文档。本文的所有的例子都基于ClearCase 2003.06.15实现。

根据需要定制Trigger

优化ClearCase，支持配置管理流程

配置管理是一个系统，包括三部分：工具、人员、配置管理的流程与纪律，工具的目的是在流程与纪律的约束下，配合人员、简化人员的工作；经常有这样的情况发生，我们可以找到许多ClearCase的脚本和Trigger，但是拿来用时并不尽如人意，常有一些意想不到的问题发生，带来许多麻烦。这就应了一句话：“江南为桔，江北为枳”，我们需要根据自身的实际情况来修改与定制脚本与Trigger。

第一步要确定配置管理的流程制度，这取决于我们要做一个什么样的软件，是一个项目，还是半定制的产品、或是产品线或其他类型，这些是配置管理系统的根基，配置管理系统的任务就是服务好这个目标；根据目标与组织结构确定开发的方式，不同的目标与组织结构要使用不同的开发方式，如果只是一个简单的项目，则没有必须进行并行开发，如果是产品线，则并行开发是不可避免的；目标、组织结构与开发方式共同决定了配置管理的流程与制度。

在流程与制度确定后，我们要看一下Rational ClearCase及UCM是否满足流程与制度的需要。在这里需要注意的是，工具只是配合流程与制度的，而不能决定流程与制度，一些配置管理的新手在这一阶段常常不由自主的根据工具来决定流程与制度。如果我们使用UCM，这时要决定Project和Stream，再根据组织结构与任务安排确定每个Project、Stream上的项目的配置Policy；最后在流程与制度中寻找当前UCM所不支持的部分，看一下是否需要应用Trigger或脚本来实现。

在定制流程时，如果要应用Trigger，则要对Trigger所针对的ClearCase 操作有深入的了解，这样才能写出有效的Trigger。例如：如果要针对deliver_start这个创建Trigger，则要了解deliver这个clearcase操作具体步骤，以下是我对deliver这个clearcase操作的理解：

1.        检查当前流上是否有一个Deliver或Rebase正在进行中，如果有，则提示当前正有一个Deliver或Rebase过程在运行中。

2.        检查目标流的Deliver policy，如果不符合Stream policy，则拒绝执行deliver并给出提示。

3.        检查源流的Deliver Policy，如果不符合Stream policy，则拒绝执行deliver并给出提示。

4.        选择要提交的活动，检查活动的依赖关系。

5.        确定将要进行操作的目标流的视图。

6.        检查确定的目标流操作视图上目前是否有Check out的配置项，如果有提示，在要提交的目标流的操作视图有Check out操作，退出。

7.        开始执行Deliver操作，这里是deliver_start的开始；创建Deliver活动，将要操作的目标流视图的当前活动设置为该Deliver活动，一般情况下，在Deliver没有完成前在图形界面下与命令行中不能修改该视图的当前活动，但是可以通过一些特殊方法进行修改。在这一步开始后，如果以后的任务失败，则要执行deliver –cancel才能删除Deliver活动，并对Check out的配置项进行Undo Check out操作。

8.        获取每个要提交的Activity的变更集。

9.        对所有需要在目标流上进行操作的配置项执行Check out操作，如果发现当前有配置项已经被Check out，记录错误并继续执行，在所有的Check out操作执行完毕后，给出在Deliver目标流操作视图上无法执行Check out的配置项列表并中止Deliver活动。注：在第6步检查的只是目标视图上是否有Check out，可能在其他视图上有Check out操作，执行Deliver时，要求配置项的Check out类型为Reserved类型，如果配置项已经在其他视图上进行了Check out操作，则不能进行Reserved类型Check out操作，无法保证在Deliver结束可以执行Check in操作，所以不能继续进行Deliver的归并。

10.    将要提交的配置项与目标流上已经Check out的配置项进行归并，根据设置进行自动归并或人工归并，如果自动归并失败，进行人工归并，如果某一配置项归并没 有完成，记录错误并继续执行，在所有的归并执行完毕后，给出归并失败的列表并中止Deliver活动。

11.    如果没有设置-force或是在图形界面下，归并完成后，提示用户Deliver操作归并完成。在此步还可以对Deliver操作进行回滚，到达第12步后，则不能进行回滚操作。

12.    在本步执行之前都可以执行deliver_cancel操作；本步活动是deliver_complete的开始；对所有Deliver操作的Check out的配置项进行Check in，在提交的源流打上一个隐藏的Delivered Label，同时结束对目标流操作视图当前活动的锁定，Deliver操作至此全部结束。

以上步骤是我对Deliver操作的理解，不是Rational ClearCase给出的指南，由于没有足够信息，所以可能和实际情况有一定偏差。从以上步骤可以看到，在前6步进行过检查的，不必设置deliver_start的Preop类型的 Trigger进行重复检查。

再次强调，不要完全依赖配置管理工具来做事情，有些情况下用纪律来约束。例如：要求不能在集成流上进行Check out操作，则不必设置Trigger，通知所有人员严禁在集成流上进行Check out操作，在集成流上所有的操作都有记录，如果有人进行了操作，按纪律处理即可。同时，可以不利用trigger的，尽量不用trigger，例如derliver的问题，如果目标流上只允许进行具有deliver权限的人员进行deliver操作，则不必设置trigger，简单的对流进行锁定即可，同时在exclude中加入允许操作的人员即可。

为了方便定制流程，Rational ClearCase提供了一系列的Trigger环境变量，例如：CLEARCASE_PN是当前element类型Trigger的操作对象。可以利用cleartool man mktrtype获取有哪些环境变量及这些环境变量的具体含义与使用方法。

Trigger的创建

创建Trigger时的参数

在前几节中描述了Trigger是什么，有什么用处以及Trigger的执行机制，但是如果要创建Trigger时，发现会有许多参数，这些参数怎么用，如何写这些小程序，初学者会有很多困惑。

在本节，我们讨论创建Trigger时的参数，在下一节我们会具体讲解根据组织的实际情况定制Trigger。

在前面几节的例子中我们提到了可以应用cleartool mktrtype命令去创建Trigger type；如果是创建针对type类型的Trigger，在执行完毕Cleartool mktrtype操作后，Trigger就会起作用，如果是创建针对配置项或UCM对象的Trigger，在执行cleartool mktrtype时没有选用-all选项，则在创建后要执行cleartool mktrigger与具体的对象进行关联后，Trigger才能起作用；创建时要注意，一般情况下要在view中的VOB目录下执行创建命令，这样该Trigger才可以针对当前VOB中element或PVOB中的ucmobject。

在创建trigger type时的参数可以分为以下九组：

1.        ClearCase操作的类型，有三个互斥选项：- element，- type，- ucmobject，为必选项；

a)        –element：定义针对element类型clearcase操作的Trigger，可以应用-all选项；在应用-all选项后，该Trigger已被隐含的关联到当前的VOB上，不必再执行cleartool mktrigger命令。

b)        –type：定义针对type类型clearcase操作的Trigger，不能应用-all选项，但是可以在范围列表中针对某一类的type应用-all选项，同时针对type类型的Trigger不用执行cleartool mktrigger命令，在执行完mktrtype后会关联到相应的type上。

c)        –ucmobject：定义针对ucmobject类型clearcase操作的Trigger，可以应用-all选项；在应用-all选项后，该Trigger已被隐含的关联到当前的PVOB上，不必再执行cleartool mktrigger命令。。

2.        确定某些用户的操作不会触发Trigger，参数为-nusers userlist；Userlist可以为多个用户，用逗号分隔，该参数为非必选项；一般应用于设定流程，可以设立一个事前触发的Trigger，缺省返回-1，再设置-nusers，这样除指定的几个用户外，其他用户的该操作都会触发Trigger，不能执行这个操作。

3.        针对什么操作定义Trigger，同时Trigger是事前触发或事后触发类型的；参数为- prepop operation或- postop operation；其中operation根据第一组参数的不同会有所不同；再次强调，虽然大多数的操作与Cleartool的子命令一致，但是所有的trigger都是针对ClearCase的操作，而不是针对ClearCase命令。

4.        是否更新已有的trigger type：-replace，这个选项可以更新已有的Trigger，即便Trigger已经关联到Element或Object也会被修改。

5.        是否对Trigger进行跟踪，大量的Trigger并不会产生交互过程，所以在最开始写Trigger时或Trigger没有产生预计的效果时，我们并不知道执行了哪些Trigger、Trigger的执行的结果以及执行中间的错误信息，我们可以在定义Trigger时使用-print参数，这个参数会在开始执行Trigger前给出Trigger的名字及相应的ClearCase的操作类型，中间的错误信息也会给出，最后给出Trigger的执行结果。我们可以不设置这个参数，但是可以设置ClearCase的一个环境变量CLEARCASE_TRACE_TRIGGER，来临时跟踪某个Trigger。

6.        是否对Trigger加以注释，可以应用以下一些参数，需要注意，这些参数是互斥的，如果没有设置这些参数，则缺省认为需要注释，会要求输入注释：

a)        –cfile comment-file-pname：注释部分取自某文本文件，需要注意，文件名要是全路径。

b)        –cq·uery：对所有受mktrtype命令所影响的event进行注释。

c)        –cqe·ach：对该Trigger进行注释，与cquery先项不同的是，cqeach针对的是所有mktrtype所影响的对象；需要注意：使用cquery与cqeach时，不要直接跟上注释，注释是命令执行后提示输入的，cquery与cqeach的注释是可以多行的，在UNIX下用Ctrl-D，在Windows下用Ctrl-Z或回车做为结束。如果在cquery或cqeach后加上字符串，cleartool 命令并不将它们视为注释，而视为定义的Trigger的名字。

d)        -nc·omment：不加以注释。

e)        -comment comment：对该Trigger进行注释，注释必须是单行的，如果中间有空格，必须要加上双引号。

7.        是否对Trigger的执行加以约束。一般情况下，element操作与UCM Object操作上定义了trigger并关联后，所有的操作都会触发Trigger，如果加上了约束，则只有符合条件的操作才会触发Trigger，如定义-eltype ms_word，则只有针对Word文档的操作才会引发Trigger，而针对源码的操作不会触发。对于type的操作的Trigger，一般情况下则是不触发Trigger，只有包含在约束中才会触发。对于element、type及UCM object不同类型的Trigger，约束也不同。

a)        Element：element型的Trigger约束条件可以有attype，brtype，htype，lbtype，trtype；参数格式为–att·ype attr-type-selector[,...], –brt·ype branch-type-selector[,...], –elt·ype elem-type-selector [,...], –hlt·ype hlink-type-selector[,...], –lbt·ype label-type-selector[,...], –trt·ype trigger-type-selector[,...] 。需要注意，不支持-all选项与通配符?与*。

b)        Type：type型的Trigger与Element和UCM object不同，缺省下不会触发Trigger，只有包含在inclusion-list中才会操作，列表参数同element类型的约束，但是支持-all选，同样不支持通配符。

c)        Ucmobject：UCMObject的约束与element较类似，都要是缺省会触发，设置了约束条件后，则只有符合约束才会触发，但是参数与elemetn和type有所不同，是–com·ponent component-selector[，…] –pro·ject project-selector[,…] –str·eam stream-selector[,...]。

d)        如果需要设置多个type，则在每个type之间用逗号分隔即可，但是注意不要使用全角的标点符号。

8.        Trigger创建执行的动作，具体描述请参见前一节Trigger的执行。

9.        Trigger的名称，这是必选项。

在创建完Trigger后，如果针对的是element或ucmobject类型的操作，并且没有使用 –all 参数，需要将Trigger类型与相应的对象关联，这需要使用 cleartool 的子命令 mktrigger 。cleartool mktrigger有以下参数：

a)        –comment，-cfile，-cquery，-cqeach，-ncomment：这几个是互斥选项，具体说明请看前面对mktrtype命令的解释。

b)        –recurse：如果mktrigger的命令针对的是目录配置项，则针对当前目录配置项及其下的子树递归的执行mktrigger命令，该命令只对element类型的trigger有效。如果是UNIX下的VOB，其中的symbolic links不会在递归队列中。如果没有-recurse选项，则Trigger只会关联所针对的目录配置项。

c)        –nin·herit，–nattach：互斥选项，这两个选项针对的是目录类型的element配置项。目录类型的配置项有两个Trigger list：Attached list与inherited list ，其中Attached list是针对目录本身的，而inherited是针对目录下以后新增加文件或目录配置项是否关联Trigger；缺省情况下关联到目录配置项的Trigger，会被关联到Attached list与inherited list中，这样Trigger即会目录配置项本身起作用，也会自动关联到该目录配置项下以后新建的文件或目录配置项。如果使用-nattach选项，则Trigger只会关联到该目录配置项的ingerited list中，对该目录配置项不起做用，如果没有使用-recurse，对当前该目录配置项下的文件与目录配置项也不会起作用，这个Trigger对以后这个目录下新建的配置项会起作用，包括文件配置项与目录配置项，其中对目录配置项会关联到目录配置项的attached list与inherited list，所以对新增目录配置项之下新增的配置项也起作用。如果这个Trigger只针对该目录配置项本身，而不想遗传给以后该目录配置项下以后新建的配置项，则可以应用-ninherit选项。需要注意，如果应用这两个选项之一，则mktrigger操作只会针对目录配置项。

d)        –force：如果在创建Trigger type操作，即mktrtype时用了约束选项，如-eltype file，text_file时，在执行mktrigger时，如果操作对象的条件不符合会所出大量的错误，同时不会将Trigger关联到相应的操作对象上，如果使用-force选项，则可以强制的将Trigger关联到操作对象上，不过这种情况下Trigger不会起作用，直到操作对象的类型发生改变，符合了trigger的约束条件或者使用mktrtype –replace将约束条件改变。

e)        要关联的Trigger类型，这是必选项。

f)         要进行关联的操作对象，只能是配置项或UCM Object，这也是必选项。

Trigger可以做什么？

所有的刚接触ClearCase的用户一般都认为Trigger是执行一个程序，实际并不是如此，这里我们给出一个例子，Trigger也可以执行一些ClearCase操作，如mklabel，mkattr等：

cleartool mktrtype -element -postop checkin –mklabel Release$Rel_num / -c "Check in Make Label" Checkin_mklabel

这个Trigger的作用是当Checkin操作之后，Element有新的版本产生时，打上label。需要注意，在环境变更中要有Rel_num的值，如果Rel_num为11，则在VOB中已定义了Label type：Release11，否则不会打上label。

Cleartool mktrtype的参数中有一组是定义Trigger的动作的：

1.        –exec command 执行指定的命令，如果命令是带参数的，则要将整个命令用单引号括起来，在这里定义的命令在所有的操作系统平台都有效，为了避免出现由于操作系统不兼容而造成Trigger失败，建议应用-exec command定义的命令中只使用ClearCase提供的命令与cleartool的子命令，不要使用UNIX的命令或Windows的命令，如ls，dir等；如果想要自己写一些应用脚本，则要保证在Windows与UNIX平台都可以执行。

2.        –execunix command  这里定义的命令只能在UNIX系统下有效，除了ClearCase的命令与子命令外，建议使用Shell脚本或Perl脚本。

3.        –execwin command 应用execwin 定义的操作只在Windows系统下有效，除了ClearCase的命令与子命令外，建议使用Perl脚本或VB脚本；在这里有一点要特别提醒注意的，如果在命令或脚本中应用了Windows的内置命令如dir，cd等，则要应用cmd /c，如下所示：

Cleartool mktrtype –element –postop checkin –execwin “cmd /c  copy %CLEARCASE_PN% //Bakckup/.” -nc

4.        –mklabel label 给当前的element或type等打上label，但是要求label必须已经定义了，所以建议在之前可以预定义一些label。

5.        –mkattr attribute 给当前的element或stream或component关联相应的attribute并赋值。

6.        mkhlink hlink 在引起Trigger操作相对应的element上执行mkhlink操作，可以应用to或from选项选择link的方向。

在第二节中讨论Trigger的优缺点时提到了针对同一个element、ucmobject或type操作可以定义多个trigger，一般情况下你可以看一下这个element的属性，在Windows环境下Trigger会按在属性中的顺序执行，但是在ClearCase文档提到不能保证执行顺序，所以尽量避免在一个element的同一操作的同一类型上关联多个Trigger。一般建议如果需要处理则将所有的Trigger并到一个Trigger中。

在以上的六项操作是非互斥的，但是需要注意mklabel、mkattr与mkhlink只支持事前触发类型的Trigger，即只有-postop的Trigger可以执行这几项操作。

最后有一个小技巧，当只定义了-execunix或-execwin时，如果当前的操作系统不是UNIX或Windows则默认为Trigger 失败，所以可以通过对checkin及checkout等操作设定只执行UNIX或Windows命令的Trigger来限制开发人员的开发平台，这样可以防止开发人员在不同开发平台的编译错误问题。

在创建完Trigger type后，一般需要执行cleartool mktrigger来进行关联。

Trigger的类型

哪些操作可以应用Trigger

在第一节我们谈到了Trigger的类型区分，在这节我们主要根据Trigger所针对的ClearCase操作对象来看一下，Trigger可以应用在ClearCase哪些操作。

这里我们从如何创建一个Trigger谈起。Trigger是一个Type，我们要应用Trigger首先要创建一个Trigger Type，和其他element type、branch type等不同的是我们只能应用cleartool mktrtype来创建trigger type，而不能应用GUI去创建。

在应用cleartool mktrtype创建trigger type时，我们可以应用-element、-type与-ucmobject来创建三种不同类型的trigger type。需要注意的是有些操作即可以应用于element，也可以应用于type，如lock，如果想要在每种ClearCase对象上都要进行流程的定义与检查，就要分别创建element与type对象的trigger。

首先是作用于Element对象的trigger，这类trigger就象label type或attribute type等一样，要被关联到具体的element上，这时要应用cleartool mktrigger命令，但是在创建时如果应用了-all选项，这个trigger就会关联到VOB，而不需要再用mktrigger去关联。一般来说象前文所述的保护配置项不会被未经批准的人删除这样的作用于整个VOB的Trigger要应用-all这个选项，这个trigger就可以这样建立：

Cleartool mktrtype -c "Only Cuibz could execute rmelem" -element -all -preop rmelem -nusers cuibz -execunix "Perl -e /"exit -1;/"" -execwin "ccperl -e /"exit (-1);/"" rmelem_check

不只是引起Element版本的变化的ClearCase操作可以定义Trigger，会引起Element的attribute type和状态变化等ClearCase操作也可以定义相应的Trigger，如修改注释、对锁定配置项或对配置项解除锁定与改变配置项的权限等，甚至关联与取消关联Trigger之类的ClearCase操作也可以定义要触发的Trigger。相应的ClearCase操作可以参见ClearCase参考手册。

在创建trigger type时，-type这个选项可以创建针对type对象ClearCase操作的Trigger，一般情况下要指定针对哪一种type对象触发Trigger，而对mktype这个ClearCase操作所定义的Trigger会针对所有的type。我们可以将第一节的例子修改一下，在创建所有的type对象之前检查权限，只允许某几个人进行操作如ccadmin，例子如下：

Cleartool mktrtype -c "Only ccadmin could execute mktype" -type -preop mktype -nusers ccadmin -execunix "Perl -e /"exit -1;/"" -execwin "ccperl -e /"exit (-1);/"" -attype -all -eltype -all -brtype -all -hltype -all –lbtype –all –trtype -all mktype_check

其实这种限制过于严格，在实际应用中一般建议只限制针对Trigger type，可以根据实际情况决定是否限制其他用户创建Branch type，可以根据修改为禁止ccadmin外所有用户创建type，我们可以用-replace这个选项修改已经创建好的Trigger，如下：

Cleartool mktrtype -c "Only ccadmin could execute mktype" -type –replace -preop mktype -nusers ccadmin -execunix "Perl -e /"exit -1;/"" -execwin "ccperl -e /"exit (-1);/"" -trtype -all mktype_check

针对type对象的ClearCase操作的Trigger与Element对象和UCM对象的Trigger相比有一点不同，这类Trigger不用再执行Cleartool mktrigger执行关联操作。

针对Element与type对象的ClearCase操作的trigger都是作用于一般的VOB，-ucmobject选项创建的Trigger是针对PVOB的，可以针对UCM中的流程进行一定的补充，如规定只有项目组的SCM才可以创建Stream，可以创建这样一个Trigger：

cleartool mktrtype -c "Only cuibz could create stream" -ucmobject -preop mkstream -nusers cuibz -execwin "ccperl -e/"exit(-1);/"" mkstream_check

之后我们可以应用cleartool mktrigger将这个Trigger关联到某个Project上，但是建议这样的Trigger最好与保护配置项的Trigger一样关联到整个PVOB，在mktrigger时，要指明UCM 对象的类型，如下所示：

cleartool mktrigger mkstream_check project:FrameIncrement