文章标题

ClearCase的基本概念

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

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

View：
一个View为项目中所有文件的某一个版本提供一个目录树。在View中你可以修改源文件，将他们编译成模块进行测试，将他们插入到文档中等活动。

流(Stream)：
流是一个具有长生命周期的ClearCase对象。它是单个UCM项目的成员，还是生成和记录配置的一种机制。一个流标识了当前你可以查看，修改和编译的一系列版本。
UCM使用基线(Baseline)和活动(Activities)来描述一个流的配置。当你创建一个流时，它的初始配置和基线一样（它包括某个组件的所有元素的单个版本）。当你修改流的配置时，你将这些修改指定为一个或多个活动。因此一个流就是一个给定的基线加上一个或多个活动。

以下活动将改变一个流的配置：

1. 从相关联的View中CheckIn版本。（一个流可以和多个View相关联）2. 基线更新 (Rebase)，用更近的基线取代流配置中的基线。3. 交付(Deliver)，通过向整合流(Integration Stream)中添加在此之前只有正在开发队伍可以进行的活动改变综合流。

一个项目包含以下两种流：
* 开发流(Development Stream)：一般来说每个项目中包含多个开发流（每个项目中的开发人员一个），它们都从同一个基线开始，而当开发人员添加活动时相互之间没有关联。
* 整合流(Integration Stream)：每个项目都有一个单一的整合流来从开发队伍中成员的开发流中收集他们的提交(Deliver)。为了方便提及过程，每个开发队伍中的成员都关联一个独立的整合View到项目的整合流。通过该整合View，开发人员可以查看基线和所有提交活动。

项目(Project)：
一般意义上项目指一群人为一个开发成果而工作，但在ClearCase中项目则是指一个说明了某一个重要开发成果中使用的一系列的 开发策略(Development Policy)和一系列配置的对象。你可以为你开发的每一个产品建一个项目，也可以为多个产品建一个项目，还可以为产品中的某个功能的实现建一个项目，甚至可以为你的某个产品的一个发行版本(Release)建一个项目。

 一个项目的策略决定了开发人员如何访问，修改一系列的源文件和文件夹（以上叫做组件(Component)）。为了记录和配置依赖于组件的开发成果，项目使用了以下的ClearCase对象：1. 基线(Baseline)；2. 一个整合流(Integration Stream)；3. 开发流(Development Stream)；4. 活动(Activity)；*      因为ClearCase支持平行开发，不同的项目可以相同的源文件的不同版本同步工作。*      ClearCase将项目储存在叫做PVOB(Project Versioned Object Base)的数据仓库中。

基线(Baseline)：
在UCM模型中，当一个ClearCase对象典型地代表一个或多个组件地稳定地源配置时，项目经理就生成基线。基线标识了一个组件或多个组件中所有元素(Element)的某一个版本和这些元素的活动。简单的说，基线就是组件的一个版本。你可以从基线生成开发流或者为一个已有的开发流基线更新(Rebase)。

完善的基线(Recommended Baseline):
一般来说基线会在测试和修改Bug之间不停的循环直至在稳定性上达到一个比较令人满意的程度。当一个基线达到这种程度，项目经理就指定该基线为完善的基线。

合并(Merge)：
合并是指将两个或两个以上的版本联合成一个版本，ClearCase的合并算法和下列版本相关：

1. 合并文件：一个开发流中的版本和一个整合流中的版本；2. 基本合并文件：原版本的最常用的父亲版本；3. 目标版本：合并的输出，在提交操作中成为整合流中的一个新的版本，而在基线更新操作中将成为开发流中的新版本。

提交(Deliver)：
一个允许开发人员通过将他们的开发流中的工作成果合并(Merge)到项目的整合流中来和开发队伍中的其它成员共享他的工作成果。假如需要的话提交需要用合并管理器(Merge Manager)来合并不同的版本。
ClearCase的提交操作使得在开发流中做的工作能在整合流中得到。工作是通过活动的形式来提交的，整合流中已有的版本和提交的版本之间的差别通过合并管理器(Merge Manager)解决。和活动相关的版本在提交之前必须CheckIn。还要注意只有活动在上一次从该开发流中提交之后有改动之后的“提交”才能认为是真正的提交。

一个提交过程可以由以下几个阶段构成;

1. 预览，列出流中有没有完成提交工作的活动；2. 开始提交，本阶段确定需要提交的活动，检查他们是否在上一次提交之后被修改过，要提交的版本是否已经被CheckIn到开发流中。3. 合并差别，本阶段比较被提交的版本和整合流中相对应的版本，如果需要的话激活合并管理器进行合并。4. 结束合并，本阶段校验合并，CheckIn整合流中的变化，进行其它一些管理工作。

基线更新(Rebase)：
ClearCase中通过基线更新使得开发人员能用整合过的，测试过的，经过不同方面使用验收的工作成果来更新他们的开发范围内的工作成果从。这些新的工作成果被成为基线。由项目经理来将活动提交进基线。