基本概念
ClearCase有时候缩写为CC。
它是IBM Rational 出品的大型商用软件配置管理工具。其核心是版本控制。
尽管能够听到对ClearCase的很多抱怨，比如昂贵、复杂、不好用，但它仍然是收费的版本控制系统中市场份额最大的。
它有两个版本：Base ClearCase和ClearCase UCM。
Base ClearCase向你提供的是文件、目录、版本、标签、分支、触发器和链接等“裸露”的环境。
在此基础上，你可以比较自由的进行设置和二次开发，以满足你实际项目的需要。
它的优点是灵活。
ClearCase UCM是开箱即用（Out of the box）的，它提供了基于Base ClearCase的一套不错的封装。
你只要做一些简单的设置，就可以在实际项目中直接使用了。
它的一些性能指标也比Base ClearCase优异。
版本库
ClearCase将版本库叫做版本对象库（Versioned Object Base,VOB）。
工作区大致对应于视图（View）这个概念。
视图分为两种，静态视图（Snapshot View）和动态视图（Dynamic View）。
静态视图是位于本机的一个目录树，这个其他工具很像。
动态视图有点像虚拟盘符，看着是在本机上，实际上是连到了服务器。
签入和签出
在ClearCase的世界里，签出（Check Out）和签入（Check in）都是针对某个文件的。
尽管工作区里已经塞满了从版本库下载的文件，但在着手修改某个文件前，先要以该文件名为参数调用签出命令，不得偷懒省略这一步。修改好了，再以文件名为参数调用签入命令。
而在ClearCase UCM里，还有Delivery、Rebase这一对词儿。
变更集
ClearCase UCM用相对复杂的方法支持变更集。在ClearCase UCM里，变更集大致对应于活动（Activity）。
活动有标题，在活动创建时输入。而每个文件的修改又可以有注释。
支持工作中文件中间版本的保存：在工作区后面，对应着一个开发人员私有流（Stream）。
中间版本和最终版本都保存（checkin命令）在私有流上，不会给别人捣乱。
而把变更集从私有流提交（deliver命令）到公共流后，大家就都能看到啦。
总之，提交包括两步，从工作区到私有流，再从私有流到公有流。
流这个概念，类似于分支。
更新
ClearCase UCM这里所说的更新，大致对应于ClearCase UCM里的变基（Rebase）私有流，并相应的更新私有流对应的工作区。这里的变基是指用公共流的一个基线来更新私有流的起点，因此改变了工作区的基础。嗯，ClearCase确实有点复杂。
提交到公共流之前，不需要因为CLearCase UCM的工作原理本身的缘故而更新私有流及对应的工作区。
因为除了开发人员自己的私有流有对应的工作区，公共流也有对应的工作区，提交到公共流时，可以在那儿完成代码合并工作。
标签
Base ClearCase是以文件为单位进行版本管理的。因此打标签可能会成为一个 费时间的工作。
当然，使用一些技巧，比如增量打标签（只在自上次整体版本以来有变化的文件上打标签），可以改善性能，但同时也增加了复杂性。
ClearCase UCM是基于Base ClearCase的封装，它使用类似的技巧来改善性能，常常能在几秒钟之内完成打标签的工作。
触发器
ClearCase UCM除了设置触发器外，
还可以锁定公共的地盘（公共流）、仅特定的用户可写，可以提交活动，而对其他人只读；
或者在创建基线时，对包含的活动有所选择；
或者不让开发人员提交到公共流，而是让集成人员在活动被批准时，提交执行活动；
或者同时使用CLearCase和ClearQuest。ClearQuest是IBM Ratinal出品的变更请求管理工具。
还原
ClearCase想把已提交的内容剔出去是比较困难的。
在Base ClearCase里，需要找到每个相关的文件，分别运行合并命令，跟上若干参数。
在ClearCase UCM里，有个叫cset.pl的脚本能让这个事儿方便一点，但这个脚本并不是“官方”的。
分支
在Base ClearCase里，只有文件级分支。
在CLearCase UCM里，用流（Stream）来支持产品级分支。
摘自【未雨绸缪：理解软件配置管理 / 董越著】
(adsbygoogle = window.adsbygoogle || []).push({});
