1.      前言

我在深入了解ClearCase的过程中，发现Trigger是一个很有用的助手，但是我在学习的过程中也走过弯路，常常觉得如果有一个简要的文档给以指导会避免许多无谓的烦恼，所以完成本文，希望能够给ClearCase的初学者以帮助。

提醒：本文中所有的Trigger只是示例，不能直接应用到实际的配置管理系统中，如果直接应用可能产生不明后果；同时本文的所有示例都是基于ClearCase 2003.06.15 for Windows，其他版本与平台的ClearCase可能会有所不同。

本文草稿完成于2006年3月底，在草稿中提到了我对Deliver过程的被步了解，在之后的修改过程中，IBM于2006年6月23日发布了IBM Rational Software Development Platform – Team Version 7.0，新的ClearCase随机文档IBM Rational ClearCase Guide to Developing Software with UCM, 7.0中对Deliver过程进行了描述，基于新的文档本文进行了修订。
       2.ClearCase Trigger简介

在学习ClearCase的过程中，Rational ClearCase CCIUG讨论组给了我很大的帮助，刚接触ClearCase时，我提出了许多流程控制的问题，在ClearCase讨论组中许多人回答到这些问题用Trigger解决比较合适；由此带来了新的问题：Trigger是什么？在其他的软件中也有Trigger这个概念，例如：Oracle数据库；在ClearCase中Trigger与其他软件中的Trigger有什么不同吗，它能够起到什么作用呢？

顾名思义，Trigger就是触发器，符合条件时会触发一系列动作，在这里我们可以看一下Rational给出的标准解释（IBM Rational ClearCase Book cc_intro.pdf Page 63）：A monitor that specifies one or more standard programs or built-in actions to be executed whenever a certain ClearCase operation is performed.翻译过来大意为：监控某一指定的ClearCase操作时，当符合条件时，会触发一系列的动作，执行的这些动作可以是ClearCase内置命令或可执行的标准程序。

从Trigger的定义中，我们可以了解到，在ClearCase中，触发Trigger的条件是执行ClearCase的一些操作；在这里有一点要注意，虽然这些会触发Trigger的ClearCase操作的名称与ClearCase的一些命令或Cleartool的子命令相同，但是触发Trigger的ClearCase操作不等同于ClearCase的命令与Cleartool的子命令，所以初学者常会混淆这两者的区别；可以这么理解，ClearCase的操作相应于ClearCase底层的过程与函数，ClearCase的命令与Cleartool的子命令在其上做了一些交互操作等封装，例如checkout操作，cleartool checkout命令一定会引起这个操作，但是clearimport命令与cleartool findmerge，cleartool mkelem，cleartool mkbranch，cleartool relocate这些命令都可能会引起这个操作，所以如果建立了一个checkout的Trigger，有时我们没有执行Checkout命令时也会被触发。
Trigger触发的时机有两种：事前触发与事后触发；事前触发主要是验证一些条件或进行一些准备工作(参见图表1事前触发(Pre-Operation)Trigger)，事后触发则是进行收尾工作（参见图表 2 事后触发(Post-Operation)Trigger）
    （抱歉，图表是用Visio做的，无法显示）

从以上两个图可以看出，事前触发与事后触发最大的不同是定义了事后触发Trigger的ClearCase一定会被执行，在执行后再执行Trigger，而事前触发的Trigger则会根据Trigger的执行结果判断是否执行ClearCase操作。

根据Trigger定义还不能直接看出Trigger的作用，我们可以从一个具体的Trigger来看一下。在ClearCase中，如果一个用户是某个配置项的Owner，该配置项的所有的分支都是该用户所创建的，并且该配置项的任何一个版本没有关联ClearCase元数据，在这种情况下该用户可以执行cleartool rmelem命令彻底删除这个配置项；但是在实际工作中，一般用户执行这个操作可能会导致配置项丢失，一般要确保只有指定的用户才具有删除权限，我们就可以通过Trigger来禁止一般用户执行删除配置项的操作。

例如，我们只允许cuibz这个用户执行删除配置项的操作，首先我们要用cleartool mktrtype命令创建一个Trigger的Type：

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

在定义Trigger时，用了-preop，这表明这个Trigger是一个事前触发的Trigger，在执行rmelem操作前首先要执行这个Trigger，如果配置项已经被删除再检查权限就没有任何意义了；另一个参数-nusers cuibz保证了针对cuibz这个用户不会执行Trigger，而之后-execunix "Perl -e \"exit -1;\"" -execwin "ccperl -e \"exit (-1);\"的具体含义是给出trigger结果，拒绝执行之后的ClearCase操作。这个Trigger的目的是除了cuibz这个用户外，其他所有执行rmelem操作的用户都会被拒绝。

只建立了rmelem_check这个Trigger Type，而没有把这个Type关联到配置项，则Trigger并不会起任何做用；如果需要针对Test这个目录配置项及其下的所有配置项进行保护，我们需要执行以下命令：

cleartool mktrigger -nc -r rmelem_check Test

这样在Test这个目录配置项及其下的子目录下，如果要执行rmelem操作都会要先检查一下操作员是否是cuibz，如果是不执行Trigger，执行rmelem操作，删除配置项；如果不是，则执行Trigger，结果是拒绝执行rmelem操作，并给出提示：

cleartool: Warning: Trigger "rmelem_check" has refused to let rmelem proceed.

cleartool: Error: Unable to remove element "New Folder".

Trigger是ClearCase的元数据对象，ClearCase中除了Element外，UCM对象可以可以关联Trigger，而针对元数据的操作可以设置Trigger。具体有哪些操作可以定义Trigger可以参考IBM Rational ClearCase文档：Rational ClearCase Command Reference中mktrtype的描述。

ClearCase Trigger指南(2) Trigger不是万能的，要以合适的方式用在合适的地方


1.  如何更好的应用Trigger

-Trigger不是万能的，要将合适的Trigger用在合适的地方

应用rmelem_check这个Trigger，可以保护我们的软件资产不会被误操作或恶意删除；从Trigger的定义中我们可以看到，Trigger触发的动作除了ClearCase内置命令，可以是任何可执行程序；这就意味我们可以根据需要进行扩展。

在我的周围，有一群ClearCase的狂热爱好者，我也是其中之一；刚了解ClearCase Trigger时，我们有这样的想法：虽然Rational ClearCase提供的UCM模式中，已经提供了一个很方便的支持多用户并行开发的流程，但是这些远远不够，我要用Trigger建立一个完美的自动控制流程，开发人员按流程走就可以了；另一些ClearCase管理员则会说UCM好是好，但是我们用的是Base ClearCase，我们要用Trigger来控制流程。可是设立了一系列Trigger后发现，理想是美好的，现实是残酷的，开发人员更多的提到的是Trigger所引起的僵化的流程、极糟的性能、层出不穷的问题，配置管理人员到处救火解决Trigger的问题，这到底是为什么呢？

这里我们就要谈到如何更好的应用Trigger来改善我们的工作，并不是所有的情况都适用于Trigger，也没有一个Trigger可以用于所有的组织。

首先，在第一节中我们谈到了Trigger会有相应的操作，这些操作对于不同的组织，甚至同一组织的不同项目都可能会有差异；同时我们也要注意到Trigger的主要目的是为不同的组织提供一个柔性的可控制的流程，而一个僵化的流程显然不符合大多数组织的愿望。

其次，在流程中也有轻重缓急之分，在同一个操作会有不同的检查项，如果将所有的要求都做到一个Trigger中，这个Trigger会很复杂，如果分开，Trigger的执行顺序又会对结果有很大的影响。

第三，每个Trigger都是一个小程序，Trigger多了，对性能会有一定的影响。

最后，一个完整的软件配置管理系统不只是工具与流程，还要有规范与纪律。

Trigger的最佳应用场景在于保护组织的软件资产不被未经允许的人员删除这样的地方，因为如果一旦操作可能会有毁灭性的后果，而其他如Check in时注释多少个字之类的不一定都通过Trigger来限制，可以在项目组中规定纪律，进行抽查就可以了。

综上所述，Trigger主要用于流程控制中一旦违反会造成不可挽回的损失或者恢复时所付出的代价过高以至于难以承受的地方，其他一些锦上添花的地方使用脚本就可以了。

请大家提出意见，我对这部分也不是很满意，但是没有修改的头绪，请给出意见。

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
想要在FrameIncrement这个Project上关联Trigger，则要标明project:FrameIncrement。

ClearCase Trigger指南(4)-Trigger可以做什么


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的执行机制，但是如果要创建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，支持配置管理流程

配置管理是一个系统，包括三部分：工具、人员、配置管理的流程与纪律，工具的目的是在流程与纪律的约束下，配合人员、简化人员的工作；经常有这样的情况发生，我们可以找到许多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 rmtrigger，该命令参数与mktrigger类似，只是没有-force选项，同时要注意的是，这个命令只是取消操作对象是关联的Trigger类型，并没有删除Trigger，同时对于Type类型的Trigger，这个命令是无效的，rmtrigger只针对配置项及UCM Object类型的Trigger类型。

如果Trigger只是有一些问题，修改之后可以继续使用，则要使用cleartool mktrtypr –replace来修改trigger，在修改过程中可以加上-print参数以进行调试。

如果不再需要这个Trigger，则可以执行cleartool rmtype来删除Trigger。

可以设置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实现。

多谢A6，之前我没有想到呀

不客气 你专心写 吾等帮你转下 没关系滴

HOHO，