下载文档原格式
ClearCase使用手册(V1.0)目录前言 (4)1配置管理工具介绍 (5)1.1 V ISUAL S OURCE S AFE(VSS） (5)1.2 C ONCURRENT V ERSION S YSTEM(CVS） (5)1.3 C LEAR C ASE (6)1.4 配置管理工具对比 (6)2CLEARCASE介绍 (7)2.1 C LEAR C ASE基本概念 (7)2.2 C LEAR C ASE特点 (8)2.2.1基本组成形式 (8)2.2.2开发模式 (8)2.2.3ClearCase特点 (9)3环境准备 (9)3.1 C LEARCASE系统客户端配置方案 (9)3.1.1客户端支持的操作系统包括 (9)3.1.2客户端环境要求 (9)3.2 C LEARCASE的服务器 (10)3.2.1网络要求 (10)3.2.2操作系统要求 (10)3.2.3硬件要求 (10)3.3 C LEARCASE安装前检查 (10)3.3.1ClearCase部署准备工作 (10)3.3.2Clercase安装前检查 (11)4服务器使用手册 (12)4.1 安装C LERCASE (12)4.1.1环境检查 (12)4.1.2安装ClearCase (12)4.2 UCM使用 (24)4.2.1VOB建立 (24)4.2.2COMP建立 (28)4.2.3Project建立 (30)4.2.4Stream建立 (33)4.2.5View建立 (35)4.2.6Security设置 (38)4.2.7数据初始化 (39)4.2.7.1 VSS数据初始化 (39)4.2.7.2 CVS数据初始化 (41)4.2.7.3 File数据初始化 (44)4.2.7.4 ClearCase数据初始化 (44)4.2.8常用命令 (45)5客户端使用手册 (46)5.1 安装C LEAR C ASE (46)5.1.1安装前准备 (46)5.1.2客户端安装 (49)5.1.3安装完毕检查 (53)5.2 参加P ROJECT (54)5.3 日常变更操作 (58)5.4 提交开发任务 (61)5.5 版本同步 (64)5.6 使用技巧 (68)6日常操作 (69)6.1 C LEAR C ASE备份 (69)6.1.1VOB备份 (69)6.1.2VIEW备份 (70)6.1.3注册项备份 (70)6.2 C LEAR C ASE恢复 (70)7项目实例 (77)前言本手册是公司内部使用IBM Rational配置管理工具ClearCase的统一变更管理流程UCM 的用户使用手册。
Clearcase安装配置操作手册裸奔的蚂蚁西安软件测评中心二〇〇七年三月1前言1.1工具介绍ClearCase是一种配置管理工具，由Rational公司开发，是开发小组用来跟踪、管理软件开发过程各个工件的配置管理系统， ClearCase可以协助开发组织更好地管理软件开发进程。
ClearCase可以和Rational公司的其他软件紧密结合，例如UCM、ClearQuest等等。
ClearCase包括两套：ClearCase LT和ClearCase (MultiSite)。
前者可以用于在同一个局域网的开发小组，适合于中小型开发组织；ClearCase (MultiSite)则适应于分布于不同地理位置、不同局域网的开发小组，适合于大型的开发组织。
1.2工具特点ClearCase的核心功能是版本控制，它是对软件开发进程中一个文件或一个目录发展过程进行追踪的手段。
在软件开发环境中，ClearCase可以对每一种对象类型（包括源代码、二进制文件、目录内容、可执行文件、文档、测试包、编译器、库文件等）实现版本控制，同时还提供了先进的版本分支和归并功能用于支持并行开发。
＊支持广泛的文件类型ClearCase不仅可以对软件组件的版本进行维护和控制，也可以对一个非文本文件、目录的版本进行维护。
用户可以定义自己的元件类型，也可以使用ClearCase中的预定义类型。
在存储时，ClearCase可以利用增量算法将文本文件存储在一个特殊结构的文件容器中，或采用标准的压缩技术控制任何操作系统文件。
（这比以往的存储形式节省了50％－70％的存储空间。
）＊在版本树中观察元件发展的过程在ClearCase中，文件版本的组织体现在版本树结构中。
每一个文件都可以通过checkout－edit－checkin的命令形成多个版本，还可以包含多层分支和子分支。
＊对目录和子目录进行版本控制ClearCase可以对目录和子目录进行版本控制，允许开发者对其数据的组织发展过程进行追踪。
ClearCase指南-基础篇（连载一）第1章前言.本文档凡斜体字即代表高级内容、高级概念、或可选内容，仅作粗略了解用，暂不必深入理会。
.如下如无特别说明，缩写“CC”即代表Rational ClearCase；缩写“VS”即代表Microsoft Visual Studio 2003/2005/Whidbey；缩写“VSS”即代表Microsoft Visual Source Safe。
. 对于代码开发人员，绝大部分配置管理工作是通过集成了ClearCase的来进行的，除却部分操作，大部分操作在VS集成环境下进行应该更便当些。
但本文档是CC的基础，也包含部分VS集成环境无法进行的操作，所以，开发人员必须仔细阅读本文档–单纯依靠集成了ClearCase的是无法解决所有问题的。
第2章 ClearCase安装2.1 准备工作. 客户机器必须加入Windwos域，客户必须用Windows域账户登录到自己的机器（即登录到域中），你的ClearCase客户端才可以正常访问ClearCase服务器、你的ClearCase客户端才可以正常工作。
ClearCase使用Windows账户作为自己权限管理的基础，切！. 网络部分、WINS设置：网络连接、属性、TCP/IP、属性、高级、WINS、添加(A)…，加入2个WINS地址：192.168.8.4、192.168.8.6。
否则安装可能失败，提示如下：. 如果客户端是Windows 2000 Advanced Server，可能因为权限问题而无法创建视图，这是我们公司域服务器帐号同步故障所致。
请先退出PDOMAIN域，然后再加入PDOMAIN域，问题应该可以解决。
注：其他类型操作系统也可能出类似故障（有时报告“…与域服务器的信任关系失败…”），解决办法同此。
. 工作方便起见，你的Windows域账户应该同时是你本机的管理员（Administrators组）。
一切Ok，开始安装工作。
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)中。
