ClearCase Deliver过程解析

 本文部分写作于2006年3月，当时主要的目的是明确Deliver步骤，了解如果写针对Deliver写Trigger脚本，最近下载了新的ClearCase 7.0文档，其中有了对Deliver的官方解释，在此做一个对比。

我的理解原文：
   

如果要针对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进行重复检查。

在ClearCase 7.0文档中的官方解释如下（简单的翻译，不保证完全无误，另需要注意的是这份文档针对的ClearCase 7.0，并不一定对ClearCase 6.0兼容）：

1. 启动Deliver操作后，将要Deliver的流的状态将会被置为deliver-in-progress，注意不是目标流。
2. 检查所有提交的活动之前的依赖关系
3. 检查所有的目录配置项，如果发现提交流与目标流有不同，则在目标流上Checkout并进行Merge，如果由于目标流上已经对目标项进行了Reserved Check out ，Merge失败，则提交停止；这时所有已经归并成功的目录配置项在目标流上保存Merge结果。
4. 对所有需要归并的配置项进行Checkout，如果不能进行Reserved类型的Check out，跳过该配置项，继续尝试对其他需要归并的配置进行Check out
5. 如果不能将所有的配置项Checkout，则以下步骤不会进行，有两种选择
1. 回退你的Deliver
2. 解决不能Checkout的问题，例如由于其他人正在进行Deliver操作，所以不能Checkout，则等其他人Deliver完成或回退后再执行Deliver
6. 所有需要提交的配置项都要Checkout成功后，开始Merge，如果自动Merge不成功，则需要手工Merge
7. 所有Merge成功后，建议在目标流是进行Build并测试
8. Build没有问题，Complete提交流，将提交流的状态deliver-in-progress取消

从新的ClearCase文档来看，我的描述基本正确，但是有些深层的，如提交流的状态我没有注意，还有许多需要学习