2 计划与准备

    2.1 计划

    配置管理切换大至可以划分为以下几个阶段：计划，准备，配置库的迁移，正式使用。

    配置管理切换计划的主要内容包括进度、资源等。

    项目的规模与所处的阶段不同，则配置管理切换所需要的时间也不同。一个20人左右，开发进度约达到计划的一半，代码量达到50K左右的项目，从开始计划到配置管理完全切换到ClearCase，最少需要3-4周时间。如果盲目的追求进度，想在1-2周内切换完成，则可能在切换后产生一系列后遗症，如版本丢失、版本错误甚至可能会有部分项目组成员抵制，从而使项目开发进程中部分工作不能纳入配置管理之下。

    进度安排建议：根据项目的情况用5-15个工作日进行准备，配置库的迁移需要5个工作日左右的时间，配置管理工程师要用5-10个工作日的跟进以使项目组成员熟悉并不再需要帮助。

    任何计划都有一个前提：资源，不同的资源会导致不同的进度与成本。在配置管理切换中三类资源非常重要：经过培训并且有ClearCase经验的配置管理工程师；经过培训并了解ClearCase UCM概念的项目经理与架构师；Rational工程师的及时支持。

    配置管理工程师在这3-4周时间内要没有其他的任务的打扰，全部的时间应用于该项目的配置切换；每个项目在配置切换的准备阶段如果有Rational工程师的现场支持会少走许多弯路。

    为了更好的完成工作，配置管理工程师必须经过系统的ClearCase的培训，同时为了提高配置管理工程师的能力，建议在内部建立一个独立的试验环境，可以让配置管理工程师从安装配置Server开始，进行ClearCase的各种功能的操作试验，以获得经验。

    2.2 准备

    如果决定应用ClearCase，好的计划与充分的准备会起到事半功倍的效果。一个项目从启动就应用ClearCase则相对于从其他配置管理解决方案迁移到ClearCase在准备上要容易的多，包括多个版本分支的产品的配置迁移则更加困难，如果准备不充分，可能会造成多次反复、严重降低工作效率，甚至可能会造成版本错误等严重后果。

    首先，要决定是应用ClearCase UCM还是Base ClearCase，UCM模式是基于Base ClearCase应用Activity管理变更的一种模式。如果项目组全部在UNIX上进行开发，比较熟悉CVS，对命令行及Shell很熟悉，项目团队配合时间较长，有专职配置管理工程师，建议应用Base ClearCase，但是需要自行开发脚本，以利于项目组成员的使用；跨平台项目、配置管理工程师是与其他项目共用的、需要对项目的进度与活动有较高的透明度等建议应用UCM模式。本文主要探讨UCM模式。

    在准备的时候要确定当前项目与其他的项目的关系，以确定PVOB的建立，如果项目和其他项目的关系不是很紧密，建议创建一个独立的PVOB。因为一般PVOB不占用过多的资源。

    2.2.1 配置模式

    PVOB建立完成后，要根据项目的实际情况确定项目的开发模式，这里给出一些建议。

    2.2.1.1 共享流模式

    项目只有一个单独的集成流，没有开发流。适用于调研项目或规模较小，且目标单一，不会同时有多个变更存在的项目。比较大的项目也可以在实际项目的初始阶段建立一个UCM Project，采用共享流模式，在需求完成后，在这个Project的Component上建立Final基线，在这个基线上建立一个新的多开发流模式的UCM Project进行设计与编码。

    优点：控制简单，如果设置的是Dynamic View，每个人的修改，其他人可以立即看到，不需要deliver，对有大量文档的项目较适合；不需要针对Deliver及Rebase设置大量的基线，配置管理人员的工作相对较少；同时项目配置管理的Policy也比较简单，不需要考虑太多。

    缺点：如果同时支持多个不同的客户或同时有多个变更，这些变更之间互相影响，则会产生开发的混乱。

    在Clearcase中共享流模式也支持同时多个用户对同一文件进行Check out操作，并在Check in时进行归并。但是如果多人对一个Element进行Check out操作时，只有一个人可以应用Reserved checkout，其他的项目组成员只能进行Unreserved Checkout。Reserved Checkout保证了开发人员是在最新的一个版本上进行Checkout，只有在Reserved Checkout的人Check in之后才可以Check in并进行归并。Reserved与Unreserved的区别可见图一。