ClearCase完全攻略（三） UCM下的一些概念全解析1

上篇文章中的链接搞错，

clearcase的实施方案 ，Base的。其实就是较多的使用分支和标签两种策略

用来初步明白Base项目差不多。深入的还需要看更多的资料

 

 

先讲下UCM的发展历史，1999就提出了，然后到现在已经10多年了。所以算是相当成熟了，IBM官方出了一些文章讲述UCM，介绍的非常好。 好文章1 ， 好文章 2， 网友的一个文章 ，

看下概念：（黑色下划线粗体是UCM特有的）

 

UCM ： Unified Changed Management 的缩写 ，统一变更管理模式，如果Base是灵活的自动相机，UCM就是手动一体化相机，因为已经非常集成。UCM通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次根据活动（activity）来管理变更。通过UCM，一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，这样避免了管理人员手动跟踪所有文件变更。

 

 

 

VOB ，全称：version object base，版本对象库。UCM这里分两种VOB，component VOB和PVOB

 

Project VOB(PVOB)（新增） ： 是存储 UCM 所需要的一些特殊的信息，如 Proejcts ， Stream ， Activity 及 Change Sets 等，一个 PVOB 可以包含多个 Project 的信息， Project 的信息必须保存在 PVOB 中。实际项目的数据也可以放在PVOB中。不过不推荐，一般放在component VOB。

 

 

view,视图 ，有个形象的比喻，。大家熟悉相机，通过调节相机的镜头（view）来观察事物，类似Clearcase也是通过view来观察和操作VOB中的内容，view通过某些规则来获取VOB中元素的某个版本，并组成了操作系统中的目录结构。view其实是“开发者的工作空间”，

 

view的config spec ，config spec就是上面说的特定的规则，可以抽象比喻成“滤镜”。他可以帮我们选择vob中的某个元素的特定版本来供我们观察和操作。UCM里面config spec根据stream的配置自动生成，不需要手工干预。

 

 

Project （新增） ： 是 ClearCase UCM 的一个概念，包含了配置管理所需要的一些配置信息，如果 Component 、 Baseline ， Stream 等，每个 Project 都有一个 Integration Stream 。
project是基于compoent创建出来的

 

 

ntegration Stream （新增） ： UCM的概念，可以理解为项目的主干，每个开发流都是集成流的一个分支，在开发流上完成工作后，再提交到主干，项目的 Build 环境建议采用集成流。

在一个项目的干流上（UCM称之为集成流）可以拉出很多的子流，这些子流根据不同的需要安排不同的人员在上面开发。（如此看来stream和base模式的branch作用一样的），每个子流开发到一定程度以后可以把子流上的开发成果提交到集成流上去，在集成流上集成管理员根据提交的内容进行编译，测试以后在集成流上打上基线（baseline），等所有的测试通过以后可以推荐基线，

 

Development Stream （新增） ： UCM的概念，可以理解为一个独立的开发环境，包含了在这个开发流上的 Activity 与修改的配置项的版本， UCM 通过开发流简化了并行开发的配置管理工作。  

 

 

 

Activity （新增） ： Activity是 ClearCase UCM 模式中的一个概念，通过变更集 (Change Set) 跟踪完成一项开发任务所引起的所有配置项的变更。在 UCM 模式下所有的 Check Out 、 Check In 、 Add to Source Control 等引起配置项发生变化的操作必须关联到一个 Activity 。

 

 

 update：2010-07-08：活动，也就是项目中的任务，赋予一组修改以一个明确的理由，包含一组change set。通俗讲应该是项目里面只要发生了变化（产生变更集），就必须给个理由。也就是关联个activity

 

update：2010-07-22：摘自CCRC7.0IDE插件中文帮助文档

活动
在 ClearCase UCM 视图中，您在任何时候要向源控制添加资源或修改已经处于源控制之下的资源，都必须将操作与某个 UCM 活动相关联 ，从而确定在特定开发任务期间创建的一组版本。当对 Rational ClearQuest® 启用 UCM 项目时，将创建活动并在 Rational ClearQuest 数据库中作为记录对其进行维护。当未对 Rational ClearQuest 启用 UCM 项目时，将创建活动并在 ClearCase 项目 VOB 中作为元数据对其进行维护。

每个活动都包含标题、活动标识和变更集。标题是一个文本字符串，活动标识是一个由 ClearQuest 或 ClearCase 生成的唯一标识，而变更集指定在处理活动时修改（或添加到源控制）的每个文件的一个版本。

当您创建新活动或选择现有活动来与某个操作关联时，该活动就成为您正在工作的 ClearCase 视图的当前活动。每个 ClearCase UCM 视图可以具有的当前活动不能超过一个。

虽然 UCM 项目经理通常制定用来帮助用户向活动分配工作的准则，但是活动并不限于特定的工作范围。例如，项目经理可能决定由您在修正缺陷或添加新功能部件时创建的版本来构成一个活动。活动还可以包含将应用程序移植到新的操作系统或硬件平台所需的所有更改。

您可以使用 ClearCase 元数据浏览器导航器来查看 UCM 视图中的活动。

 

 

 

Component（新增） ： 可以理解为一些代码、文档、 Model 等按一定的目录结构组织成的完成某些功能的可以重用的集合。这是 UCM 所引入的概念， Component 与 UCM Project 相关联，不可拆分，便于重用。。有人比喻成复写纸。非常贴切。其他project想引用马上可以复制进去。

既然一个comonent是一组文件，那么它可以把一个普通的vob库构成component，也可以把一个VOB库的某个文件夹看做component，但是必须是vob库的一级目录

 

update：2010-07-22：摘自CCRC7.0IDE插件中文帮助文档
UCM 用户依靠项目经理来创建项目、将项目的共享资源（文件和目录）组织到组件中，然后指定用来指导团队修改和集成组件的基线、活动和流。

UCM 组件是团队将之作为一个整体进行开发、集成和发布的共享资源集合（例如类库或用户界面模块）。 UCM 项目包含一个或（通常）多个组件，这些组件经常为其他项目所共享。通常组件作为 VOB 中的顶级目录创建。VOB 可以包含一个或多个组件，但是一个组件不能包含其他组件。

注： 您不能使用 ClearCase Remote Client 来创建、修改或查看现有组件。要处理组件，您必须使用仅在本机 Rational ClearCase 客户端上可用的工具。有关组件的更多信息，请参阅 ClearCase 文档。

Change Set（新增） ： Change Set 记录了 Activity 所关联的所有的配置项的版本变更，每个 Activity 都有一个 Change Set 。

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

 

baseline = code + documents

baseline1  + changesets = baseline2
基线有双重的身份，大家可以在下图我画的简略图中发现一条基线 从compoent的角度看它是属于某个comopent的基线，如果从流的角度看，基线是在某个流中产生的基线，我们有一点要记住，基线的产生是通过流创建的，但是我们从隶属的角度上看他是属于某个component的基线。

 

 

 

 

 

Deliver （新增） ： UCM的概念，是一个从开发流向 UCM Project 集成流或其他开发流提交工作的一个动作。

 

 

 

 

Rebase （新增） ： UCM模式的一个操作，让当前 Stream 的 View 的内容与 Integration Stream 推荐基线同步。并且只工作在基线（非活动）的粒度上。

Snapshot view ： Snapshot View 是对 VOB 的一个静态视图，将相关的 VOB 的选定的版本下载到本地保存，需要经常进行 Update View 操作以保证与关联的 stream 同步。

 

 

 

 

Dynamic View ： Dynamic View 是对 VOB 的一个动态视图， VOB 的变化会及时反应到 Dynamic View 上，每个 Dynamic View 都关联到一个 Stream 上，在 Dynamic View 上会有一些 View 的私有文件，这些 View 私有文件不会被同一个 Stream 上的其他 View 所见到。

 

 

 

 

 

 

UCM概念和BASE的对应，看完基本上知道什么回事了。

 

 

 

update：2010-07-08：上图中说的神似的几对概念，从实现的功能角度确实差不多。不过具体的实现机制等还是有很多不同。

这个在后面的文章中有讨论

 其他一些比较

图

 

update 2010-07-07，来源 地址 ，作者：grantlee

一、基线不是基于组件的，而是基于流的；基线和流的关系犹如工件和文件的关系，因为：
1、工件是文件的一个版本，一般用file.no形式描述。
2、工件是活动产生的结果，工件是不可编辑的（因为编辑也是活动，又产生新的工件，原有的工件没有变化）。
所以：
1、基线是流的一个版本，默认用stream＋date的形式来描述。
2、基线是一组工件的集合，工件覆盖了流中所有的文件。

上面是不是还是有些糊涂？因为没有讨论组件、流、文件三者之间的关系。
1、组件是一组文件（目录）的集合；
2、流是组件的一个工作分支；
3、流中包含了组件中的所有文件；

是不是还没有说清楚？越来越糊涂了？^_^
将组件想象成一张纸，目录树和文件名就可以写在上面了，这个就是组件和文件（目录）的关系；
将这张纸复印一下，所有的目录和文件也有了，复印出来的流了；
反过来说原来的也是一张纸了，那么也是流了？
不错，原来的那张纸也是流，是主流（Main），一般都不用的。最后归结：组件原来是一沓复印出来的纸，只是每张纸上都可以再手工修改，最奇妙的是手工修改过的还可以复印到其他指定的纸上！哈哈，原来是复写纸。

 

update 2010-07-15 来源 地址 ，作者：lin85210

vob就是仓库，component是工具箱（还有其他类别的工具箱），element就是钳子，扳子，斧头等等，我们就是工人。

 

update：2010-07-22：摘自CCRC7.0IDE插件中文帮助文档

无论您使用的是 UCM 还是基本 ClearCase，都存在这些分支、版本和标签；在 UCM 中，您不必直接对它们进行处理。

update 2010-08-03 UCM中同时使用Baseline和label

UCM更有彈性的應用方式

為了配合客戶所提出的需求，依據MR狀態來建立不同的Build，同步到對應的測試環境，原先的UCM建立baseline模式已不敷使用！
引入base clearcase apply label的觀念，再加上make baseline by import label，就可以達到依據不同的label建立不同的baseline，而不會侷限在有變更才可以建立baseline！這樣的方式相對彈性許多！

 實際會用到的指令如下，之後可以用程式的方式作到自動化：

cleartool lsbl -short -comp doc@/twm_vob
列出某個component中，所有的baseline

cleartool lsbl -short -comp doc@/twm_vob -stream twm_eva_developer@/twm_vob
列出某個component中，位於某個stream中所有的baseline

cleartool rmbl UT_Test_Passed_doc_IMPORT@/twm_vob
移除某一條baseline(這個動作會將對應的label type也一併移除)

cleartool mkbl -nc -import -comp doc@/twm_vob,src@/twm_vob UT_Test_Passed@/twm_vob
以import label的方式建立baseline，這邊要特別注意，最小的單位是component，也就是說label要貼到某個component中所有的檔案，否則無法建立
baseline baseline的naming rule是 __IMPORT，還沒找到可以在哪邊修改naming rule

cleartool rename lbtype:UT_Test_Passed_doc_IMPORT@/twm_vob lbtype:UT_Test_Passed_20070816@/twm_vob
將label type改名，對應所有的instance(label)會自動更新

cleartool rename baseline:UT_Test_Passed_doc_IMPORT.8278@/twm_vob baseline:UT_Test_Passed_doc_20070816@/twm_vob
將baseline改名

cleartool rebase
label與baseline都改名後，再進行rebase，若是先rebase再改label type的話，檔案會看不見，要重新rebase一次才可以(先rebase到別條，再rebase回來)