ClearCase的优点/缺点

问题描述

因为我目前正在努力学习IBM Rational ClearCase，所以我想听听您的专业意见。

Because I'm currently struggling to learn IBM Rational ClearCase, I'd like to hear your professional opinion.

我对比较优点/缺点特别感兴趣

I'm particularly interested in advantages/disadvantages compared to other version-control-systems like Subversion or Git.

推荐答案

您可以在我的SO中找到ClearCase和Git之间的良好比较答案：

，说明一些主要差异（以及ClearCase的一些缺点）

You can find a good comparison between ClearCase and Git in my SO answer:
"What are the basic ClearCase concepts every developer should know?", illustrating some major differences (and some shortcomings of ClearCase)

ClearCase最重要的缺点是其旧的 以文件为中心方法（与SVN或Git或Perforce中以 存储库为中心相对）...

这意味着每个文件的每次签入或签入均已完成。操作的 atomicity 在文件级别。

将其与非常详细的协议以及开发者工作站与开发人员工作站之间可能具有多个节点的网络相结合。 VOB服务器，您最终可能会得到一个相当慢且效率低下的文件服务器（ClearCase是其核心）。

The most single important shortcoming of ClearCase is its old "file-centric" approach (as opposed to "repository-centric" like in SVN or Git or Perforce...)
That means each checkout or check-in is done file per file. The atomicity of operation is at file levels.
Combine that with a very verbose protocol and a network with potentially several nodes between the developer workstation and the VOB server, and you can end up with a fairly slow and inefficient file server (which ClearCase is at its core).

每个文件的操作意味着：慢速递归操作（例如或，甚至通过 clearfsimport ）。

必须使用快速LAN 来减轻该健谈协议的副作用。

File-per-file operations means: slow recursive operations (like recursive checkout or recursive "add to source control", even by clearfsimport).
A fast LAN is mandatory to mitigate the side-effects of that chatty protocol.

要考虑的另一个方面是它的集中方面（即使可以通过其多站点复制的VOB功能进行分发）
b $ b如果网络不允许访问VOB，则开发人员可以：

The other aspect to take into account is its centralized aspect (even though it can be "distributed" with its multi-site replicated VOB feature)
If the network does not allow access to the VOBs, the developers can:

仍可在快照视图中工作（但具有被劫持的文件）
如果它们使用动态视图，则等待网络恢复

您可以通过复制获得一些分布式VCS功能一个Vob。

但是：

You can have some distributed VCS feature by replicating a Vob.
But:

您需要特殊的许可证才能访问它。
该许可证价格昂贵，并增加了常规许可证的费用
使用复制的vob的任何vob（admin vob，admin pvob，...）必须也可以复制（意味着与分布式开发不直接相关的某些项目仍将需要支付多站点许可证...）

GUI非常老派，不切实际（90年代中期的MFC外观，完全同步的GUI，这意味着您必须等待刷新才能单击其他位置）：浏览基线时，您不能快速查找特定基线。
Unix上的GUI与Windows上的GUI并不完全相同（最新的7.1版本更好，但还没有）
安装过程非常复杂（尽管CC7.1引入的最新安装程序管理器现在在Windows或Unix上具有一致的GUI，并且确实简化了过程）
唯一为CCRC（远程客户端）开发的真正丰富的应用程序

the GUI is very old school and impractical (mid-90's MFC look, completely synchronous GUI, meaning you have to wait for a refresh before clicking elsewhere): when browsing baselines, you cannot quickly look for one in particular.the GUI on Unix is not exactly the same than on Windows (the latest 7.1 version is better but not there yet)the installation process is quite complicated (although the latest Installer Manager introduced by CC7.1 is now a coherent GUI on Windows or Unix and does simplify the procedure)the only real rich application has only been developed for CCRC (the Remote Client)

如 ，动态视图非常棒（一种通过网络查看数据而不必将其复制到磁盘的方法），但是主要功能仍然是 UCM ：它可以是如果您的大型项目具有复杂的工作流程，则为真实资产。

As mentioned in "How to Leverage ClearCase’s features", dynamic views are great (a way to see data through the network without having to copy them to the disk), but the main feature remain UCM: it can be a real asset if you have big project with complex workflow.

这方面的一些缺点：

对于组件之间的依赖关系，无法很好地管理深度（因为 ）
UCM仍具有一些一致性，并且

the dependencies between components is not well managed for a depth superior to one (because of the bug of "parasite baseline")UCM still has some in coherencies and inconsistencies as documented in CM Crossroads

在不使用UCM的情况下使用ClearCase意味着必须定义以下策略：

Using ClearCase without using UCM means having to define a policy to:

创建分支（否则任何人都可以创建任何分支，而合并工作流的噩梦最终会使它们变成一个gazillon）
放置 labels （否则，您会忘记为某些文件添加标签） ，或者将标签放在您不应该使用的位置，或者将标签从一个版本移动到另一个版本：至少不能移动UCM基准）
定义变更集。变更集仅与UCM活动一起存在。使用Base ClearCase，您将可以轻松处理 cleartool查找请求...

create branch (otherwise anyone can create any branch, and you end up with a gazillon of them, with merge workflow nightmare)put labels (otherwise you forget to label some files, or you put a label where you were not supposed to, or you "move" (gasp) a label from one version to another: at least UCM baselines cannot be moved)define changeset. ChangeSets only exist with UCM activities. With Base ClearCase, you are reduced to clever "cleartool find" requests...

ClearCase权限管理完全基于系统权限。

这意味着您需要将用户注册到正确的系统组，当您必须输入IT服务的票证以使其正确注册时，这并不总是那么容易。

添加到一个异构环境 （Windows用户和Unix服务器），并且您需要在Unix和Windows上注册用户！ （具有相同的登录名/组名）。除非您在两个世界之间放置了某种LDAP对应关系（例如）

ClearCase right management is entirely built on system rights.
That means you need to register your user to the correct system group, which is not always easy to do when you have to enter a ticket to your IT service in order for them to make the proper registration.
Add to that an heterogeneous environment (users on Windows, and server on Unix), and you need to register your user on Unix as well as Windows! (with the same login/group name). Unless you put some sort of LDAP correspondence between the two world (like Centrify)

仅完成CLI（ cleartool 是ClearCase命令行界面），意味着任何脚本（Perl或其他语言）都包含解析这些 cleartool 命令的输出）
，但非常有限
存在Java API，但仅适用于CCRC客户端的Web视图。

only CLI is complete ("cleartool" is the ClearCase Command Line Interface), meaning that any script (in Perl or other language) consists in parsing the output of those cleartool commands)ClearCase Automation Library (CAL) exists, but is quite limitedJava API exists, but only for web views for the CCRC client.

View存储相当于 SubVersion的 .svn，例如每个视图只有一个视图存储，而不是SubV的所有目录中都有许多 .svn ersion工作区。

The View storages are the equivalent of the ".svn" of SubVersion, exept there is only one "view storage" per view instead of many .svn in all the directories of a SubVersion workspace. That is good.

不好的是视图中的每个操作（一个简单的 ls ，结帐） ，检查...）将触发对管理您的视图服务器的 view_server 进程的网络请求。

2个选项：

What is bad is that each operations within a view (a simple "ls", checkout, checking, ...) will trigger a network request to the view_server process that manages your view server.
2 options:

在工作站上声明您的视图存储：对于可伸缩性非常有用，您可以在不增加LAN负担的情况下拥有任意数量的视图：所有通信都直接在您的工作站。但是如果该计算机死于您，您将丢失视图。
在集中式服务器上声明您的视图存储：这意味着将在此处创建所有view_server进程，然后任何用户对视图的所有操作都必须与该服务器进行通信。如果基础结构是正确的（专用高速LAN，专用服务器，持续监视），则可以完成此操作，但实际上，您的LAN将不支持此模式。

第一种模式意味着：您必须备份自己进行中的工作（私有文件或已签出的文件）

第二种模式意味着：您的工作站可能不可用，您只需登录另一个即可恢复视图（执行快照视图的私有文件的执行）

The first mode means: you have to backup yourself your work in progress (private files or checked-out files)
The second mode means: your workstation can be unavailable, you can just log on another a get back your views (execpt for the private files of a snapshot view)

侧面关于动态视图的讨论：

要添加到动态视图方面，它具有一个优点（它是动态的）和一个缺点（它是动态视图。

动态视图非常适合设置简单的环境，以便在 small 团队之间快速共享 small 开发：对于较小的开发工作，动态视图可以帮助2或3个开发人员不断保持彼此联系，当一个人的提交中断了某些工作时立即查看

对于更复杂的开发工作，快照视图提供的人为隔离是可取的（您只有在刷新时才看到更改-或更新快照视图）

对于真正不同的开发工作或课程，仍然需要一个分支来实现真正的代码隔离（有时需要合并，ClearCase处理得很好，尽管很慢，但逐个文件）

To add to the "dynamic view" aspect, it has one advantage (it's dynamic) and one shortcoming (it's dynamic).
Dynamic views are great for setting a simple environment to quickly share a small development between a small team: for a small development effort, a dynamic view can help 2 or 3 developers to constantly stay in touch one with another, seeing instantly when one's commit breaks something in the other views.
For more complex development effort, the artificial "isolation" provided by snapshot view is preferable (you see changes only when you refresh - or "update" - your snapshot view)
For real divergent development effort or course, a branch is still required to achieve true code isolation (merges will be required at some point, which ClearCase handles very well, albeit slowly, file-by-file)

重点是，出于正确的原因，您可以同时使用两者。

The point is, you can use both, for the right reasons.

注意：由小团队我的意思不是小项目。 ClearCase最适合用于大型项目，但如果要使用动态视图，则需要设置 任务分支以隔离较小的开发工作：每个分支机构都可以有效地工作，从而在其成员之间快速共享其工作。

如果您在主要部门上使用动态视图分支，每个人都在做什么，那么任何签入都会杀死您，因为它可能会引入一些与您当前的开发工作无关的构建中断。

那么，dynamic的用法很差。视图，而忘记了它的其他用法：

Note: by small team I do not mean "small project". ClearCase is best used for large project, but if you want to use dynamic views, you need to setup up "task branches in order to isolate a small development effort per branch: that way a "small team" (a subset of your large team) can work efficiently, sharing quickly its work between its members.
If you use dynamic views on a "main" branch where everyone is doing anything, then any check-in would "kill you" as it could introduced some "build breaks" unrelated with your current development effort.
That would then be a poor usage of dynamic views, and that would forget its other usages:

访问数据的其他方式， 快照视图，这意味着它是仅查看文件的好工具（例如，您可以使用动态视图来调整其配置规范，直到看到所需的内容，然后将这些选择规则复制到平时快照视图）
进行合并的侧视图：您可以使用快照视图，但是对于合并，可以使用动态的 sister-view（ sister，与 same config spec相同），以避免合并失败是由于检出的文件（当前正在使用快照文件进行操作）或由于快照视图不是最新的。合并完成后，您将更新常规快照视图并恢复工作。

additional way of accessing data, in addition of snapshot views, meaning it is a great tool to just "see" the files (you can for example use a dynamic view to tweak its config spec until you see what you want and then copy those select rules into your usual snapshot view)a side view to make merges: you work with your snapshot view, but for merges you can use your dynamic "sister-view" ("sister" as in "same config spec"), in order to avoid having a failed merge because of checked-out files (on which you would be currently working on your snapshot view), or because of a snapshot view not completely up-to-date. Once the merge is complete, you update your regular snapshot view and resume your work.

直接在动态视图中进行开发并不总是最好的选择，因为所有（未检出）文件都是通过网络读取的。。

这意味着IDE所需的dll，jar或exe将通过网络访问。 ，这会大大降低编译过程。

可能的解决方案：

Developing directly in a dynamic view is not always the best option since all (non-checked-out) files are read over the network.
That means the dll or jar or exe needed by your IDE would be accessed over the network, which can slow down considerably the compilation process.
Possible solutions:

一个快照视图，其中包含所有快照
其中包含dll或jar或exe的快照视图（文件每五分钟不变：每天更新一次），以及仅具有可见源的动态视图。

这篇关于ClearCase的优点/缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！