标签（Label）

    标签有太多种不同的使用方法，可以使你变得头晕。列出关于标签的所有可能问题是不可能的，但是如果你是负责任地并构建了一个表，这个表包含了在你的系统里的每种标签类型的信息，那你就是处于正确的道路上。在UCM里使用标签会有助于UCM使用模型。理解下面的问题总会是好的：

    标签如何使用？

    什么时候使用标签？（构造，合并，工作流控制）

    你的标签命名方案是什么？

    当标签不再被需要时，如何废弃和删除？

    分支（Branch）

    如果你正在使用base ClearCase而没有使用分支，那么你可能还是忽略下面的问题比较好，因为实质上你还没有一个base ClearCase的使用模型。如果是这种情况，你可以直接转换到UCM模型，而不用从你的当前模型进行映射。实际上，无论你当前有什么都必须抛弃掉。

    如果在你的模型里有分支，那么你有许多工作要做。UCM分支模型使用流的概念，我们稍后会讨论。有可能，你的分支模型将会彻底被抛弃。然而，另一方面，你的使用模型可能仍然是可用的。确保你花时间来理解下面的问题：

    什么时候创建一个分支类型？

    你的命名约定是什么？

    什么时候元素移动到分支？

    你的分支策略是什么？

    有多少人在同一个分支上工作？

    你有一个集成分支吗？

    你在“main”分支上做什么？

    你要让你的分支过时效吗？

    什么时候分支被弃用和删除？

    合并（Merging）

    与你的分支一样，你需要花一些时间在本节里理解关于合并的问题。UCM有集成点和新的命令来处理从一个分支到另一个分支的代码合并，这需要通过称为提交和变基的两个概念来完成。理解为什么合并以及何时进行合并是非常重要的。问问你自己：

    什么时候进行代码合并？是由一个事件引起触发？还是由时间引起触发？

    代码是自动合并还是手动合并？

    谁对代码合并负责？

    允许从集成分支合并到开发分支吗？

    从一个开发分支合并到一个集成分支的频率是怎样的？

    触发器（Trigger）

    在大多数的base ClearCase系统中，触发器是非常重要的，因为他们有助于工作流程和过程控制。UCM有一些方针，包括了ClearCase触发器的使用。确保你的配置管理计划描述了你的触发器和使用它们的VOB。理解这些问题是重要的：

    你使用的触发器是什么，为什么要使用它们？

    哪些VOB使用的哪些触发器？

    UCM中的基本对象

    Base ClearCase提出了一些很抽象的概念，例如分支，标签，超链接，元素，视图和版本对象库，UCM作出了更高级别的抽象，我们每天用于进行开发，集成和提交产品。这些更高层的概念是：

    项目（Project）

    流（Stream）

    活动（Activitie）

    基线（Baseline）

    构件（Component）

    如果你已经使用base ClearCase 有一段时间了，你会很快发现这些概念已经存在你的系统里了，要么是在文档中，要么在脚本中。可以把它认为是你的才华的一个证实，软件现在提供了你曾经创建脚本去做的所有事情－－现在你可以继续轻松下来，使用这些可利用的东西。

    项目（Project）

    项目用于为一组人在一个单一的项目上提供工作。它可以是一个产品的发布，一个完整项目的子系统，或者是集成一些产品形成一个套间。项目包含了一个集成流和零个和多个开发流。这是项目必须的开始计划。当开始创建项目前，尽管你需要和市场人员、软件开发团队、质量保证人员坐下来讨论，同时技术方面的作者开始确定你希望如何一起工作。

    有关项目的ClearCase 命令包括：mkproject, lsproject, chproject, 和rmproject。

    流（Stream）

    流可以比喻成开发的分支。流基本上是由元素的特定版本组成。普通分支和流主要的区别是在流里保存了附件的信息。比如，流里包含了基线，和一组活动。它也可以包含和其它流的关系，比如父流。基线，加上活动集，决定流里包括元素的哪些版本。 

    图1：流的例子

    在图1里，有两个活动－－活动1和活动2－－已经添加到了流里。基线由那些在图里显示为粗体线条的元素版本表示。两个活动包含表示为不同的模式的元素版本。