ClearCase培训文档

ClearCase的使用方法这是本人在查看ClearCase使用帮助，根据自己的理解，整理，翻译出来的部分ClearCase帮助。

主要内容是一些基础的与ClearCase相关的概念，对理解ClearCase的工作方式有一定的作用。

希望这篇文档对大家有所帮助，随手翻译的文档可能存在不少错误之处，还请大家多多指教。

ClearCase的基本概念一、一、VOB(Versioned Object Base)：是文件，文件夹和元数据（ClearCase控制下的文件和文件夹叫做元素(Element)，每个元素Check In形成的修改叫做一个版本(Version)）的永久存储仓库。

以下是关VOB的基本概念：1．1．一般来说一个VOB中包含了每个元素的所有版本(Version)以及诸如用来描述每个版本的标签和CheckOut注释等元数据2．2．对一个既定的项目，依赖于管理员对项目数据的安排，可能需要访问位于不同VOB中的元素。

二、二、View：一个View为项目中所有文件的某一个版本提供一个目录树。

在View中你可以修改源文件，将他们编译成模块进行测试，将他们插入到文档中等活动。

三、三、流(Stream)：流是一个具有长生命周期的ClearCase对象。

它是单个UCM项目的成员，还是生成和记录配置的一种机制。

一个流标识了当前你可以查看，修改和编译的一系列版本。

UCM使用基线(Baseline)和活动(Activities)来描述一个流的配置。

当你创建一个流时，它的初始配置和基线一样（它包括某个组件的所有元素的单个版本）。

当你修改流的配置时，你将这些修改指定为一个或多个活动。

因此一个流就是一个给定的基线加上一个或多个活动。

以下活动将改变一个流的配置：1. 1.从相关联的View中CheckIn版本。

（一个流可以和多个View相关联）2. 2.基线更新(Rebase)，用更近的基线取代流配置中的基线。

3. 3.交付(Deliver)，通过向整合流(Integration Stream)中添加在此之前只有正在开发队伍可以进行的活动改变综合流。

一个项目包含以下两种流：1. 1.开发流(Development Stream);2. 2.整合流(Integration Stream);开发流：一般来说每个项目中包含多个开发流（每个项目中的开发人员一个），它们都从同一个基线开始，而当开发人员添加活动时相互之间没有关联。

整合流：每个项目都有一个单一的整合流来从开发队伍中成员的开发流中收集他们的提交(Deliver)。

为了方便提及过程，每个开发队伍中的成员都关联一个独立的整合View到项目的整合流。

通过该整合View，开发人员可以查看基线和所有提交活动。

四、四、项目(Project)：一般意义上项目指一群人为一个开发成果而工作，但在ClearCase中项目则是指一个说明了某一个重要开发成果中使用的一系列的开发策略(Development Policy)和一系列配置的对象。

你可以为你开发的每一个产品建一个项目，也可以为多个产品建一个项目，还可以为产品中的某个功能的实现建一个项目，甚至可以为你的某个产品的一个发行版本(Release)建一个项目。

一个项目的策略决定了开发人员如何访问，修改一系列的源文件和文件夹（以上叫做组件(Component)）。

为了记录和配置依赖于组件的开发成果，项目使用了以下的ClearCase对象：1．1．基线(Baseline)；2．2．一个整合流(Integration Stream)；3．3．开发流(Development Stream)；4．4．活动(Activity)；因为ClearCase支持平行开发，不同的项目可以相同的源文件的不同版本同步工作。

ClearCase将项目储存在叫做PVOB(Project Versioned Object Base)的数据仓库中。

五、五、基线(Baseline)：在UCM模型中，当一个ClearCase对象典型地代表一个或多个组件地稳定地源配置时，项目经理就生成基线。

基线标识了一个组件或多个组件中所有元素(Element)的某一个版本和这些元素的活动。

简单的说，基线就是组件的一个版本。

你可以从基线生成开发流或者为一个已有的开发流基线更新(Rebase)。

完善的基线(Recommended Baseline):一般来说基线会在测试和修改Bug之间不停的循环直至在稳定性上达到一个比较令人满意的程度。

当一个基线达到这种程度，项目经理就指定该基线为完善的基线。

六、六、合并(Merge)：合并是指将两个或两个以上的版本联合成一个版本，ClearCase的合并算法和下列版本相关：1．1．合并文件：一个开发流中的版本和一个整合流中的版本；2．2．基本合并文件：原版本的最常用的父亲版本；3．3．目标版本：合并的输出，在提交操作中成为整合流中的一个新的版本，而在基线更新操作中将成为开发流中的新版本。

七、七、提交(Deliver)：一个允许开发人员通过将他们的开发流中的工作成果合并(Merge)到项目的整合流中来和开发队伍中的其它成员共享他的工作成果。

假如需要的话提交需要用合并管理器(Merge Manager)来合并不同的版本。

ClearCase的提交操作使得在开发流中做的工作能在整合流中得到。

工作是通过活动的形式来提交的，整合流中已有的版本和提交的版本之间的差别通过合并管理器(Merge Manager)解决。

和活动相关的版本在提交之前必须CheckIn。

还要注意只有活动在上一次从该开发流中提交之后有改动之后的“提交”才能认为是真正的提交。

一个提交过程可以由以下几个阶段构成;1. 1.预览，列出流中有没有完成提交工作的活动；2. 2.开始提交，本阶段确定需要提交的活动，检查他们是否在上一次提交之后被修改过，要提交的版本是否已经被CheckIn到开发流中。

3. 3.合并差别，本阶段比较被提交的版本和整合流中相对应的版本，如果需要的话激活合并管理器进行合并。

4. 4.结束合并，本阶段校验合并，CheckIn整合流中的变化，进行其它一些管理工作。

八、八、基线更新(Rebase)：ClearCase中通过基线更新使得开发人员能用整合过的，测试过的，经过不同方面使用验收的工作成果来更新他们的开发范围内的工作成果从。

这些新的工作成果被成为基线。

由项目经理来将活动提交进基线。

UCM概念一、什么是UCMUCM(Unified Change Management)是Rational公司在软件系统开发中从需求到发行过程中对更改的管理方法。

UCM横跨整个软件开发的生命周期，定义了对需求，设计模型，文档，组件，测试用例，和源码的更改的管理。

UCM奇特的地方在于它连接了用来追踪和计划体现在工件(Artifact)的变化中的Rational项目进度的活动(Activity)。

UCM主要关注以下两个概念：1. 1.活动是你想要完成的工作。

活动可能产生于某个会议的一个文件，一个进入缺陷(Defect)库中的缺陷(Defect)，或者是客户新增加的功能。

事实上，整个开发过程就是一个活动。

2. 2.工件是一个你想进行版本控制的物体，通常是一个文件。

更具体的说，工件可以是需求，测试，可视化的模型，源码，项目计划等等。

配置管理（Configuration Management，简称CM）在UCM中是基于活动的，它允许将测试过的产品晋升基线。

基线是在某个时间点上的一个逻辑组的项目文件。

它允许开发团队在诸如发布和开发的跌代过程等关键的里程碑上把握软件进度。

组件管理(Component Management)在UCM是一种将一系列的文件版本作为一个命名的实体以产生和操作一致性的更改的方法。

UCM功能强大的地方在于它连接了用来追踪和计划体现在工件(Artifact)的变化中的Rational项目进度的活动(Activity)。

UCM由以下过程和工具支持：1. 1.Rational Unified Process 中的更改管理流程描述的使用UCM的过程；2. 2.Rational ClearQuest管理项目的活动：任务，缺陷(Defect)，请求和功能的增加，并提供了用以跟踪项目进度的报表和报告生成工具。

3. 3.Rational ClearCase 管理所有软件项目产生的工件。

二、UCM工作流的基本概况：无论项目经理还是开发人员，对一个软件开发项目需要什么都有一个非常良好的理解。

融合这种理解并体现了业界最好的实践经验，UCM支持了跌代的软件开发过程。

开发队伍的所有成员都在一个UCM项目(Project)中工作。

在UCM中项目(Project)是包含有诸如产品版本等用来管理开发成果的配置信息的对象。

一个项目包含一个共享的工作区和数个人工作区（或者叫流），个人工作区允许开发人员独立地通过活动的形式工作。

而项目经理的责任就是维护共享的程序开发区。

UCM工作流：UCM的项目经理和开发人员的工作流如下图所示。

图中小标签所代表的活动由小标签上的数字所表示的工作流摘要说明：UCM工作流摘要：1. 1.项目经理设计出项目的范围和项目的策略；2. 2.项目经理创建项目，设置项目的共享工作区（整合流），并为一个或多个组件(Component)确定初始的基线。

组件(Component)是在一起开发，整合，发行的一组相关联的文件和文件夹。

基线则是组件的一个版本。

3. 3.开发人员通过创建他们自己的工作区（开发流），并将项目的基线的内容导入到该工作区来加入到该项目中。

4. 4.开发人员创建一个活动，并在活动工作一段时间。

活动记录了开发人员为了完成诸如修改一个Bug等开发任务而修改或生成的一系列文件。

这些和活动相关联的文件叫做更改(Change Set)；5. 5.当开发人员在他们自己的私人工作区里完成活动，对他们工作成果的编译和测试之后，他们可以通过将该活动提交到共享工作区中来和整个开发组的其它成员共享他的新的工作成果。

6. 6.项目经理周期性地在共享工作区中通过合并已经提交的活动来生成新的基线。

7.7.开发人员用新的基线中的新的版本的更新私人工作区。

8.8.当基线的稳定性和质量得到改善之后，项目经理周期性地调整基线的提升级别为诸如BUILD和TESTED之类能提箱相应的项目里程碑的字眼。

开发人员在为活动工作，提交已经完成的活动，用新的基线更新自己的私人工作区中循环。

而项目经理则在不停地做创建新的基线和基线升级中循环。

这两个循环会持续到项目完成。

三、UCM项目中的数据流：1. 1.项目中用于标识和隔离不同开发人员的工作的活动(Activity)从多个开发流中迁移到标识一系列在整个项目中用于构造系统和测试用的共享版本的整合流(Integrator Stream)中。