ClearCase 优缺点

Question

ClearCase 优缺点

version-controlclearcase

68

因为我目前在学习IBM Rational ClearCase方面遇到了困难，所以我想听听你的专业意见。

我特别关心与其他版本控制系统（如Subversion或Git）相比的优缺点。

- B.E.

3

硬件需求怎么样？上次我使用它时，需要非常可怕的硬件配置。不过，得承认那是1998年 :) - skaffman

31

理由=过于复杂的痛苦麻烦、可疑的垃圾。 - mP.

46

如果您正在考虑将CC集成到开发环境中，我只能给出一个建议：不要这样做。 - Dmitri Nesteruk

9

如果你需要一个说服人们不使用“clearcase”的论据，你可以说所有优秀的开发者都讨厌它。我知道，如果有任何地方使用clearcase作为他们的源代码控制系统，我都不会去那里工作。哪怕是为了避免使用clearcase，我也愿意忍受VSS的痛苦。 - SolutionYogi

5

我尚未决定的唯一事情是ClearCase是否比RCS更糟糕。可能如此。 - Thomas Owens

显示剩余4条评论

31个回答

35

成本是一个相当明显的缺点。不仅是许可证费用，而且还包括ClearCase专家的薪资成本。我知道的几乎每家使用ClearCase的公司似乎都至少有一个人的唯一目的是驯服这个难以控制的野兽。

它足够复杂，需要全职保姆照顾也值得警惕。

- Dónal

OP似乎不在意成本。 - Otávio Décio

5

软件、硬件和人员的成本并不一定通用。这些成本可能来自组织中的不同预算。此外，增加一个人员并不像预算薪水和零星开支那样简单。可能会出现其他问题，并且您可能会押注部门的能力，以便一个人员的可用性使其继续工作。我更喜欢一个不需要全职专家的系统，并且个人可以自己解决大多数问题的系统。 - David Thornley

是的，但你是否曾经在一个有50多个开发人员共同维护的代码库环境中工作过？你需要使用UCM和流式策略来处理这个问题。你可能会找到一些真正的专家为你编写一些脚本和工具，以便在你的软件配置管理系统之上进行操作，这样随着时间的推移，它们会开始运行得非常好。但到了某个时候，你就会拥有一堆杂乱无章的脚本，带有各种怪癖，而且难以维护。 - Spence

6

我不知道UCM是什么，但无论你使用哪种版本控制系统，都需要就流式处理/分支策略达成一致。你肯定永远不需要的是ClearCase。我是一个正在使用ClearCase的项目的人，我可以说它非常糟糕。 - Dónal

请允许我对上面的答案进行补充。我目前在一家组织中工作，我们有一个由5人组成的团队专门负责管理中央ClearCase仓库。这可能看起来很多，但对我来说，如果没有中央实体来管理200名开发人员使用Clearcase可能会变得混乱。这个问题在像git这样的分布式系统中不会（或者较少）出现。 - rahmu

27

一个绝对的系统噩梦。 它让我希望我们可以回到VSS！ （别提什么像Subversion或Git这样的现代源代码控制系统!）

它非常缓慢。
如果您使用动态视图并且网络中断，您无法访问源代码的工作副本。您只能坐等修复。
如果您使用快照视图，您似乎经常遇到冲突和"被劫持"文件，因此您工作副本中的文件与源库中的文件永远不完全相同。
每当尝试进行大型更新或交付操作时，由于各种原因，它总是失败，需要ClearCase专家花费几个小时/天来解决问题。哦，是的，您必须拥有一位专门的、全职的ClearCase专家！
当它失败时，您通常也无法回滚操作，因此您被困在正在进行的操作中，而开发人员被阻塞。
当您看过漂亮（？）的图标时，您会发现GUI非常差劲——甚至到无法调整窗口大小以查看完整文件路径的程度！
他们的支持工作人员非常不愿意修复任何问题。他们的第一个反应总是"这是设计如此"和"您能解决它吗？"如果他们最终提供修复措施（经过多次争论），那么它将是对最紧迫问题的最基本的可能的修复措施。

基本上，它非常缓慢、复杂且不可靠。哦，我提到了它价格昂贵得离谱吗？他们唯一可能卖出它的方法是与决策者交谈，而这些决策者从未使用过该产品，也永远不会使用！我敢肯定，世界上没有开发人员会购买它。

- EMP

当它失败时，通常无法回滚：这取决于您是否已开始进行检入。如果仍然只有检出文件，则回滚只需“撤消所有检出”。注意：对于预计为复杂的合并（由于自上次合并以来的重要时间间隔），“合并分支”可以是一个很好的选择，以便隔离合并工作。一旦在那里巩固了一切，将dev分支简单合并即可完成该过程（注释中的注释：最后一个建议不特定于ClearCase，并且适用于任何VCS工具）。 - VonC

25

原子提交和变更集是我对ClearCase最大的抱怨。假设您作为缺陷修复或重构的一部分检入了五个文件。但随后发现出了些问题，需要还原。要找到这五个文件以及每个版本需要用哪个版本进行还原，就会非常麻烦。但让我们退一步。你刚刚完成了编辑这五个文件，现在是提交的时间了。前四个文件都可以成功提交。但最后一个文件需要进行大规模合并。其他四个文件已经被检入。它们不等待您完成最后一个文件中必要的更改。我希望没有人更新或正在使用动态视图。连续集成构建服务器也将失败。

有时我们会创建一个全新的目录，并填充文件，但在完成前并不想将其检入。现在还很早，一切仍然不稳定，所以为什么要检查可能很快就会删除的东西呢？直到现在为止，一切都还好。现在是检入的时间了。您将新创建的文件夹添加到源代码控制中。好吧，ClearCase 不支持递归，因此只有这一个文件夹被检入。而 SVN 可以选择将该文件夹及其所有子文件夹一起添加。开发人员需要记得添加所有内容，否则会缺少很多文件。

ClearCase 拥有文件和文件夹，因此除非您首先将其检出，否则无法修改任何内容。Eclipse 插件在这里消除了很多麻烦。我无法告诉您有多少次我打开 vi 文件进行快速更改，结果发现自己忘记先将其检出。而且检出不是递归的。

没有变更集更新会非常缓慢。如果使用快照视图进行更新，则每个文件都会更新，而不仅仅是修改的文件。我曾参与一个拥有超过20,000个文件的项目。我远程登录到我的工作计算机，开始更新，然后开车去上班；喝咖啡；等它完成。这听起来可能有些夸张，但遗憾的是事实确实如此。

动态视图非常糟糕，除非你的团队非常小。如果是这种情况，那你为什么还要用ClearCase呢？我见过无数人的视图被损坏，因为有人提交了破坏其他人视图的文件。你应该总是在自己的视图上更新和合并任何冲突。这样，更改只影响你自己。使用动态视图，你不能在推回之前向下合并；你只能提交并希望成功。

我知道成本可能不是一个大问题，但是为公司赚钱的开发人员会喜欢花费5-10万美元（取决于ClearQuest许可证，这是一个常见的附加项）在有趣的活动或新设备（椅子、显示器等）上。IBM建议雇员来维护ClearCase系统。为什么不重新调整这些人的职责，让他们为公司创造收入，而不是确保系统正常运行呢？

以下是我听到的一些不换用其他版本控制工具的原因:

学习需要时间和金钱
- 学习SVN或Mercurial不应该超过一天。只有ClearCase建议在管理员与开发人员之间保持一定比例。
迁移会很痛苦
- 这就是工具存在的原因：cc2svn
- 但在Mercurial中并不容易.
安全性
- 据我所知，SVN中没有已知的漏洞，开发团队致力于快速修复任何发现的问题。国防部似乎对SVN也很满意。
没有真正的生产力提升
- 如果没有更改集，就要花费很长时间去跟踪错误。我喜欢能够回滚到看不到错误的时候。在ClearCase中你无法做到这一点。
多站点
- WANdisco解决了这个问题。但它不是免费的。

ClearCase唯一比其他工具做得更好的事情是对单个文件进行分支，同时保持其他文件与另一个分支在同一条轨道上。

- geowa4

2

如果我有时间，我会发布更多内容。 - geowa4

实现合并锁定将解决很多问题。而按时间回滚更改真的非常容易。是的，这是一种不同的工作方式，它可能比执行原子提交的工具更烦人，但是这些事情不应该妨碍你。在比你可能由于这些问题而浪费的时间少得多的时间内，你可以修复它们的合并策略。 - Nick Bastin

你也知道 Svn BLAME 吗？当你可以看到可能存在错误的每一行的最后编辑时，就不需要回滚了吧？ - Spence

20

我在Clearcase中所做的一切似乎总是很困难。而我从未对其他系统留下过这样的印象（除了可能偶尔使用CVS）。

我曾经使用过SVN、CVS、Clearcase和Mercurial。

- Paul Nathan

2

嗯，CVS 看起来总是很难的。但不像 ClearCase 那么难！+1 - EMP

15

所有我与ClearCase相关的经验都是低效、丑陋、过于复杂、缓慢、令人困惑、昂贵和不便利的。

似乎只有那些完全错了的管理者和工程师才会使用它。

该死，IBM和Rational一定有惊人的销售团队可以销售这样一个糟糕的产品。

- Alex Worden

5

我也曾想过，清晰软件销售人员所使用的宣传册是何等华丽，才能够销售这种东西。或许只是因为这确实是一个非常出色的系统，适用于那些没有真正使用它的人。 - Mattias Nilsson

15

我们正在将许多基于CC的IT项目迁移到Git，原因有很多。我想再加上一个避免使用CC或任何其他商业源代码管理系统的理由。

关键的商业数据被ClearCase扣为人质，你无法取出它。

你的商业数据是代码、版本历史和所有元数据，如提交评论，谁何时检查等。

所有软件都有一个有限的有用寿命。当你引入一个新的吞噬重要商业数据的系统时，不管是代码、错误、客户数据还是其他什么数据，你应该总是问自己一个问题：如何再次获取我的数据？如果你无法回答这个问题，那么你就不应该引入这个系统。

当我们迁移时，我们失去了大部分历史和所有元数据。基本上，我们只有与发布版本相对应的历史记录，但是有关根据什么客户请求进行的更改的信息丢失了（我们在客户支持和故障票系统中具有这些数据，因此它并没有完全丢失，但与源代码的耦合已经消失了）。

这对我们在近期到中程度上会造成一定的麻烦和问题。几年后，它就不重要了，但可能在1-3年内仍然很重要。

（有商业工具可以将CC迁移到其他版本控制系统，但它们被认为不适合我们的需求，我怀疑这是可行的。我们所做的最小导出已经花费了足够长的时间。）

教训是：永远不要将关键的商业数据托付给专有系统。

- simon

15

我使用ClearCase的经历非常糟糕，我同意Don的观点，它需要一个驻场专家--不幸的是我们有不止一个。我有使用CVS和其他版本控制系统的经验，我熟悉这些概念，但我发现ClearCase文档难以理解，必须多次寻求帮助；不同的专家给出的建议相互冲突，最终导致我们甚至破坏了cd命令。即在UNIX shell中发出ClearCase命令后，“cd”命令失败并显示错误消息。

版本控制系统的基本任务非常简单。老实说，我认为只需要半打命令，使用一个与其他系统兼容的文件方案就足够了。对我而言，ClearCase看起来像是营销人员故意把事情复杂化，使产品看起来 sophisticated 和功能强大。我听说可以将其配置为以简单、安全、可靠的方式运行，但再次需要专家的服务--开箱即用的状态就像一把机械式瑞士军刀。

- Beta

1

很抱歉听到这个消息。我们在Windows、Linux和Solaris（8和现在的10）上运行ClearCase（2002，然后是2003、2007和现在的7.1），没有任何问题。cd命令也非常好用 ;) （注：我还运行SVN和Git） - VonC

打破CD并不是很难。只需删除shell所在的目录即可。卸载/重新加载mvfs可以做到这一点。只需cd到/，然后再返回（如果目录又回来了）。话虽如此，我对ClearCase的实现没有任何辩护之词。不过概念很棒。 - kmarsh

是的，我知道cd到/或其他已知存在的地方 - 它没有起作用。那个shell非常不稳定。 - Beta

14

不支持原子提交

一旦您检入了文件，要恢复到某个状态就非常困难，因为ClearCase不支持原子提交。当检入多个文件时，每个文件都会获得一个新的版本号（类似于CVS），而不是检入本身。我认为这是一个至关重要的功能，因为您很少想要回滚单个文件，而是完整的提交操作（应该映射任务）。使用ClearCase，您只能通过使用标签来还原到某些状态。在实践中，为每个检入使用ClearCase标签是过度的，因此不会这样做。

差劲的用户界面

ClearCase Explorer的GUI简直是一个大笑话。可用性很差，看起来很丑。不提供不同的、通常必需的功能（例如递归地检入工作的文物）。使用cygwin和cleartool命令行工具要好得多，但仍有一些东西不可用，例如递归地将新文件/文件夹添加到源代码控制。如果我读到一个长达50行的脚本来解决这个问题，我就要笑翻了。

高管理成本

管理ClearCase兽很不明显或轻量化（与其他SCM系统如CVS、Subversion或Git不同）。需要投入相当多的专门的ClearCase专家来维持其运行。

性能差劲

让开发人员在与SCM工具交互时等待是最糟糕的，就像开着手刹驾车一样。它会减慢您的大脑和工作速度。获取10K件文物的新文件到您的快照视图需要大约30分钟。对于同样数量的更新（文物没有更改），需要大约5分钟。当进行反复实验并在不同的最新视图之间跳转时，需要等待很长时间。当您正在重构类型或方法的名称/移动时（可能会影响很多文件），情况变得更糟了。检出、检入和添加到源代码控制周期需要大约10-15秒，这显然是一个噩梦。

缺乏分布式开发支持

今天的软件开发往往是分布式的（开发人员遍布全球，共同处理同一个产品/项目）。ClearCase显然不适用于这种情况，因为它不适合离线工作。在执行检出操作（编辑文件/文件夹之前的操作）时需要网络连接。虽然可以使用劫持选项，但这只是一个临时解决方案而非功能（你基本上只是在文件系统上解锁文件）。如果你的开发站点远离ClearCase服务器，则检入/检出延迟甚至可能会增加到无法使用。有一些解决方法，例如使用ClearCase Multisite（scm数据库副本技术），但需要额外付费并且不容易管理。

作为替代方案，Git是一个不错的选择。虽然我是开源的忠实粉丝和支持者，但我仍然愿意为好的软件支付费用。但是看着IBM巨兽ClearCase，我不想在这里投资，因为它具有所有这些讨论过的缺点，而且IBM似乎没有投入足够的资金来显著改进他们的产品。最近我尝试了Git scm，它看起来非常不错，特别是对于分支+合并功能，这是ClearCase的主要优势所在。

本信息摘自http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/。

- joe

13

可能是有史以来最糟糕的软件。我不会为任何使用理性工具的公司工作。除了CC在动态构建过程中频繁地导致我的工作站崩溃之外。当你正在将某些东西推送到源代码控制时，如果CC像它擅长的那样崩溃会发生什么？你的代码是否被放在lost+found里，或者备份在其他地方？没有，它永远消失了。所以，如果你不得不使用这个昂贵的巨型软件，一定要保留一切的副本。好样的Rational/IBM。你成功地捕获了源代码控制最重要的部分-可靠性。慢慢死去吧。

- Ryan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

在我的SO答案中，你可以找到ClearCase和Git之间的良好比较：
"每个开发人员都应该了解哪些基本的ClearCase概念？",展示了一些主要差异（以及ClearCase的一些缺点）

以文件为中心的操作

ClearCase 最大的短板就是其老旧的"以文件为中心"方法（相对于 SVN 或 Git 或 Perforce 等"以仓库为中心"的方法）
这意味着每次检出或提交都是针对单个文件进行的。操作的原子性在文件级别上。
将此与非常冗长的协议和潜在的多个节点之间的网络相结合，从而可能导致文件服务器的速度缓慢和效率低下（这是 ClearCase 的核心问题）。

文件-每个文件的操作意味着：缓慢的递归操作（例如recursive checkout或recursive "add to source control"，即使通过 clearfsimport 也是如此）。
强制使用 快速的 LAN 可以缓解这种啰嗦协议的副作用。

集中式版本控制系统

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

仍然在快照视图中工作（但仅限于被劫持的文件）
等待网络恢复，如果他们正在使用动态视图

昂贵的分布式版本控制系统选项

你可以通过复制Vob来获得一些分布式版本控制功能。
但是：

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

老旧且不用户友好的GUI

图形用户界面非常老旧且不实用（中期90年代MFC外观，完全同步GUI，这意味着您必须在单击其他位置之前等待刷新）：浏览基线时，您无法快速查找特定的基线。
Unix上的GUI与Windows上的GUI并不完全相同（最新的7.1版本更好，但还没有到位）
安装过程相当复杂（尽管CC7.1引入的最新安装程序管理器现在在Windows或Unix上是一个连贯的GUI，并简化了该过程）
唯一真正的Rich应用程序仅为CCRC（远程客户端）开发

UCM不一致和不协调

如How to Leverage ClearCase’s features所述，动态视图非常棒（一种通过网络查看数据而无需将其复制到磁盘的方法），但主要功能仍然是 UCM ：如果您拥有具有复杂工作流程的大型项目，则可能是真正的资产。

在这方面存在一些缺点：

组件之间的依赖关系在深度高于一级时无法很好地管理（由于“寄生基线”的bug）

UCM仍存在一些不一致和矛盾，如在CM Crossroads中记录的那样

使用Base ClearCase的有限策略

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

创建分支（否则任何人都可以创建任何分支，你最终会得到大量分支，并且合并工作流程会变成噩梦）

放置标签（否则你会忘记给某些文件打标签，或者你会在不应该的地方放置标签，或者你会将标签“移动”（吸氧）从一个版本移到另一个版本：至少UCM基线无法移动）

定义变更集。ChangeSets仅与UCM活动一起存在。使用Base ClearCase，你只能减少聪明的“cleartool find”请求...

没有应用程序权限
ClearCase权限管理完全建立在系统权限上。这意味着您需要将用户注册到正确的系统组，但是当您必须提交工单给IT服务以进行适当的注册时，这并不总是容易的。加上异构环境（Windows上的用户和Unix上的服务器），您需要在Unix和Windows上注册您的用户！（使用相同的登录名/组名）。除非您在两个世界之间放置某种LDAP对应关系（如Centrify）
没有高级API
只有CLI是完整的（“cleartool”是ClearCase命令行界面），这意味着任何脚本（用Perl或其他语言编写）都包括解析这些cleartool命令的输出。 ClearCase Automation Library（CAL）存在，但功能相当有限。
Java API存在，但仅适用于CCRC客户端的Web视图。
视图存储不易集中/备份
视图存储是SubVersion的“.svn”的等效物，除了每个视图只有一个“视图存储”而不是SubVersion工作区所有目录中的许多.svn。这很好。
不好的是，视图中的每个操作（如简单的"ls"、检出、检查等）都会触发一个网络请求到管理视图服务器的view_server进程。
有两个选项：

在您的工作站上声明您的视图存储：非常适合可扩展性，您可以拥有尽可能多的视图而不会对局域网造成负担：所有通信都直接在您的工作站上完成。但是如果该机器失效，您将失去您的视图。

在集中式服务器上声明您的视图存储：这意味着所有的view_server进程都将在那里创建，并且任何用户对视图的所有操作都必须与该服务器通信。如果基础设施“正确”（特殊的高速局域网、专用服务器、持续监控），这是可以做到的，但实际上，您的局域网将无法支持此模式。

第一种模式意味着：您必须自己备份正在进行的工作（私有文件或已检出文件）
第二种模式意味着：您的工作站可能不可用，您只需登录另一个并获取回您的视图即可（除了快照视图的私有文件）

关于动态视图的讨论：

除了"动态视图"方面的优点（它是动态的）和缺点（它是动态的）之外，还有一个补充。
对于一个小型开发团队来说，动态视图非常适合设置一个简单的环境，以便快速共享一个小型开发项目：对于小型开发项目，动态视图可以帮助2或3个开发人员保持不断联系，即时查看一个人的提交是否会在其他视图中出现问题。
对于更复杂的开发项目，快照视图提供的人工“隔离”更可取（只有在刷新或“更新”快照视图时才能看到更改）。
对于真正的分歧开发项目或课程，仍需要一个分支来实现真正的代码隔离（在某些时候需要合并，ClearCase可以很好地处理这一点，尽管是逐个文件）。

重要的是，你可以根据正确的原因同时使用两种方法。

注：通过小团队，我并不是指“小项目”。ClearCase最适合用于大型项目，但如果你想使用动态视图，则需要在每个分支上设置"任务分支"，以便为每个分支隔离一个小型开发项目：这样，“小团队”（你的大型团队的子集）可以高效地工作，快速分享其成果。
如果在每个人都在做任何事情的“主”分支上使用动态视图，则任何提交都可能会“杀死你”，因为它可能会引入一些与当前开发项目无关的“构建破坏”。
那将是动态视图的不良使用，并且将忽略其其他用途：

动态视图提供了一种额外的访问数据的方式，除了快照视图之外，这意味着它是一个很好的工具，只需"查看"文件（例如，您可以使用动态视图来调整其配置规范，直到看到所需内容，然后将那些选择规则复制到您通常的快照视图中）。

用于合并的侧面视图：您使用快照视图工作，但对于合并操作，您可以使用动态的"姐妹视图"（"姐妹"指"相同的配置规范"），以避免由于已检出的文件（在快照视图上正在进行工作的文件）或快照视图未完全更新而导致合并失败。合并完成后，更新您的常规快照视图并恢复工作。

直接在动态视图中开发并不总是最佳选择，因为所有（非检出）文件都通过网络读取。
这意味着您的IDE所需的dll、jar或exe将通过网络访问，这可能会显著减慢编译过程。
可能的解决方案：

一个包含所有内容的快照视图

一个包含dll、jar或exe的快照视图（这些文件不会每五分钟更改一次：每天更新一次），以及仅显示源代码的动态视图。