你想过将ClearCase由base方式转移到UCM方式吗？你的base配置支持你的组织当前的使用模型吗？你可能想考虑何时决定转移到UCM方式，这里有来自Christian Buckley和Darren Pulsipher的一些想法。
什么是统一变更管理(UCM)，以及它如何应用于IBM? Rational ClearCase?

UCM被发展出来，使得人们从一个有效的使用模型开始使用ClearCase变得更容易了。这是由于"base" ClearCase配置非常灵活，以至于很多组织发现使用这个软件比较困难。为了让ClearCase对于他们的特殊需求更加有用，他们编写了自己的脚本和过程。UCM在确定ClearCase使用模型的大多数公共元素上进行了努力，并创建了使应用软件更加有效的对象和方法。

如果你现在正在运行base ClearCase方式，你可能在某些点上考虑升级至UCM。但是从什么地方开始呢？涉及哪些内容呢？区别在什么地方？在考虑从你当前的ClearCase系统迁移到UCM系统之前，你应该首先理解你当前的使用模型－－以及你的组织自从安装以来如何使用Basic ClearCase对象。这个变化的过程非常类似于第一次迁移到ClearCase系统的过程。对于任何新的项目，你需要弄明白在你可以向前走时你处于什么位置。

首先，你应该回顾一下当前使用的基本ClearCase对象。通过回顾当前的对象，你将能够了解你的基础装置和UCM方式之间的区别，更好地理解新的UCM对象带给你的ClearCase系统的新功能。进行此变更的大多数组织发现，他们已经编写了许多自己的脚本来执行由一些UCM对象包含的功能。象这样的一些情况，采用UCM对象会很好。这会使你受益，因为此时ClerCase与你的定制开发有相同的功能，在系统里你会有更少的必须支持的脚本，使得你可以花更多的时间关注实际的工作。

基本的ClearCase对象
如果你已经完成了一个配置管理(CM)计划，同样可以做。如果你还没有一个计划，请参见IBM Rational Unified Process 方法论选择一个合适的模板。一个好的配置管理 (CM)计划应该包括非常概括的工作流程条款，和特定的ClearCase规划。如果你已经有了自己系统详细的规划，将会发现UCM的变化将会相当直接。至少你将会容易地能够看到无论是否是UCM对于你的实施都是一个很好的适合。那是你希望有一个对于已有对象和你当前的对象的清除的理解－－仅仅因为UCM是可用的，不必要地意义你将会使用它。

UCM主要是对你已经一直在使用的base ClearCase 对象增加了额外的对象和工作流。因此，在你着手这些变更前，首先看一下关于当前使用的ClearCase对象的一些问题：

VOB（版本对象库）
版本对象库（VOB）在UCM中如同在base ClearCase使用模型中一样重要。你有可能在你当前的系统里继续使用相同的VOB结构。当你可能改变少量东西使其在UCM中更有效时，你可能希望什么也不做。当然，你将会需要回答一些有关你的VOB结构的基本问题，这些问题的大多数可能已经在你的配置管理计划里进行了回答：

你的VOBs是如何计划的？
你有admin VOBs吗？
VOBs之间的关系是怎样的？
在VOBs里包含哪些种类信息，以及它们的目录是如何组织的？
视图（View）
UCM使用视图做一些有趣的事情。他们通常较之于基础ClearCase方式执行有更长的持续时间。回答关于视图如何创建和删除是很重要的。另外，配置规格（config specs）自动地在UCM里产生，并且它们可能不是你所希望的。重要的是你也可以描述配置规格，因而理解从原有旧系统到新系统的映射。问问你自己：

谁能创建视图？
视图创建的频率是如何的？
视图创建是自动地还是手动地？
视图保留多长时间？
什么时候删除视图？
配置规格是自动创建的吗？
配置规格是共享的吗？
标签（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）
项目用于为一组人在一个单一的项目上提供工作。它可以是一个产品的发布，一个完整项目的子系统，或者是集成一些产品形成一个套间。项目包含了一个集成流和零个和多个开发流。这是项目必须的开始计划。当开始创建项目前，尽管你需要和市场人员、软件开发团队、质量保证人员坐下来讨论，同时技术方面的作者开始确定你希望如何一起工作。