ClearCase优点/缺点

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

与其他版本控制系统（如Subversion或Git）相比，我对优势/劣势特别感兴趣。

Answer 1

你可以find一个很好的比较ClearCase和Git在我的回答：
“ 每个开发人员应该知道的ClearCase的基本概念是什么？ ”，说明了ClearCase的一些主要差异（以及一些缺点）

---

以文件为中心的操作

ClearCase最重要的一个缺点就是它以前的“以文件为中心 ”的方法（与SVN，Git或Perforce中的“以存储库 为中心 ”相反）
这意味着每个签出或签入都是按文件完成的。 操作的primefaces性在文件级别。
将它与一个非常详细的协议以及可能在开发人员工作站和VOB服务器之间可能有几个节点的networking结合起来，最终会产生一个相当缓慢且效率低下的文件服务器（ClearCase是其核心）。

文件每文件操作的意思是： 缓慢的recursion操作（如recursion检出或recursion“添加到源代码pipe理” ，即使通过clearfsimport ）。
快速的LAN是强制性的，以减轻该聊天协议的副作用。

集中式VCS

另一个要考虑的方面是它的集中化方面 （即使它可以通过其多站点复制的VOBfunction“分布”），
如果networking不允许访问VOB，开发人员可以：

• 仍然在快照视图内工作（但只有被劫持的文件）
• 如果他们正在使用dynamic视图，请等待networking的恢复

昂贵的分布式VCS选项

您可以通过复制Vob来获得一些分布式VCSfunction。
但：

• 你需要一个特殊的许可来访问它。
• 该许可证是昂贵的，并增加了常规许可证的成本
• 任何使用复制的vob（admin vob，admin pvob，…）的vob也必须复制（意味着一些不直接涉及分布式开发的项目仍然需要支付多站点许可证…）

旧的，而不是用户友好的GUI

• GUI是非常古老的学校和不切实际的（90年代中期的MFC的外观，完全同步的GUI，这意味着你必须等待刷新，然后再点击其他地方）：当浏览基线，你不能快速寻找一个特别的。
• Unix上的graphics用户界面与Windows不一样（最新的7.1版本更好，但还没有）
• 安装过程相当复杂（虽然CC7.1引入的最新安装pipe理器现在是Windows或Unix上一致的GUI，并且简化了过程）
• 唯一真正的丰富的应用程序只为CCRC（远程客户端）

UCM不一致性和共同性

正如在“ 如何利用ClearCase的function ”中所提到的 ，dynamic视图非常好（通过networking查看数据而不必将其复制到磁盘上的方式），但主要function仍然是UCM ：如果您拥有大工程复杂的工作stream程。

这方面的一些缺点：

• 组件之间的依赖性没有得到很好的pipe理，因为它比一个更深（因为“ 寄生基线 ”的缺陷）
• UCM 在CM Crossroads中仍然有一些共同点和不一致之处

基于ClearCase的有限策略

使用ClearCase而不使用UCM意味着必须定义一个策略来：

• 创build分支 （否则任何人都可以创build任何分支，并最终与他们gazillon，与合并工作stream恶梦）
• 放标签 （否则你忘记标签一些文件，或者你把一个标签放在你不应该的地方，或者你从一个版本到另一个版本“移动”（标签）：至lessUCM基线不能移动）
• 定义变更集 。 只有UCM活动存在ChangeSets。 使用Base ClearCase，您可以简化为“ cleartool find ”请求…

没有申请权利

ClearCase权限pipe理完全基于系统权限。
这意味着您需要将您的用户注册到正确的系统组中，当您必须为IT服务input票据才能正确注册时，这并不总是很容易。
再加上一个异构的环境 （Windows上的用户和Unix上的服务器），你需要在Unix和Windows上注册你的用户！ （使用相同的login名/组名）。 除非你把两个世界之间的某种LDAP通信（比如Centrify ）

没有高级API

• 只有CLI是完整的（“ cleartool ”是ClearCase命令行界面），这意味着任何脚本（使用Perl或其他语言）都包含在parsing这些cleartool命令的输出中）
• ClearCase自动化库（CAL）存在，但相当有限
• 存在Java API，但仅适用于CCRC客户端的Web视图。

查看存储不容易集中/备份

视图存储相当于SubVersion的“.svn”，在每个视图中只有一个“视图存储”，而不是SubVersion工作空间的所有目录中的许多.svn。 那很好。

有什么不好的是，视图中的每个操作（简单的“ ls ”，checkout，checking，…）都会触发一个networking请求到pipe理你的视图服务器的view_server进程。
2个选项：

• 在您的工作站上声明您的视图存储空间：对于可伸缩性非常重要，您可以根据需要添加尽可能多的视图，而不必为局域网征税：所有通信都直接在工作站上完成。 但是， 如果那台机器死在你身上，你放松了你的观点 。
• 在一个集中的服务器上声明你的视图存储：这意味着所有view_server进程都将在那里创build，并且任何用户在视图上的所有操作都必须与该服务器进行通信。 如果基础架构是“正确的”（专用高速LAN，专用服务器，持续监控），则可以完成，但实际上，您的LAN不支持该模式。

第一种模式意味着：您必须备份自己正在进行的工作（私人文件或签出文件）
第二种模式意味着：您的工作站可以不可用，您可以login另一个取回您的视图（执行快照视图的私人文件）

---

关于dynamic视图的侧面讨论：

为了增加“dynamic视图”方面，它有一个优点（dynamic）和一个缺点（dynamic）。
dynamic视图非常适合设置一个简单的环境，以便在一个小团队之间快速分享一个小型的开发：对于一个小的开发工作，dynamic视图可以帮助2或3个开发人员不断地保持联系，在其他观点的东西。
对于更复杂的开发工作，快照视图提供的人造“隔离”是可取的（只有在刷新时才会看到更改 – 或者更新快照视图）
对于真正的差异化开发工作或课程，仍然需要一个分支来实现真正的代码隔离（在某些时候需要合并，ClearCase处理得非常好，尽pipe缓慢，逐个文件）

关键是，你可以使用两个，正确的原因。

注： 小队我不是指“小项目”。 ClearCase最适用于大型项目，但是如果您想使用dynamic视图，则需要设置“ 任务分支” ，以便为每个分支分离出一个小的开发工作 ：这样一个“小团队”（您的大团队的一个子集）可以高效工作，快速分享其成员之间的工作。
如果你在一个“主”分支上使用dynamic视图，每个人都在做任何事情，那么任何检入都会“杀了你”，因为它可能会引入一些与你当前的开发工作无关的“构build中断”。
那么dynamic视图的使用就会很糟糕，而且会忘记其他的用法：

• 除了快照视图之外 ， 还有其他 访问数据的方式，这意味着它是一个很好的工具来“看”文件（例如，您可以使用dynamic视图来调整其configuration规范，直到看到您想要的内容，然后复制这些select规则到你平常的快照视图）
• 一个侧视图进行合并：你使用快照视图，但是为了合并，你可以使用dynamic的“姐妹视图”（“姐妹”在“相同的configuration规范”），以避免由于签出的文件（您当前正在处理您的快照视图），或者由于快照视图不完全是最新的。 合并完成后，您将更新常规快照视图并恢复您的工作。

在dynamic视图中直接开发并不总是最好的select，因为所有（未签出）的文件都是通过networking读取的 。
这意味着您的IDE所需的dll或jar或exe将通过networking访问，这可能会大大减慢编译过程。
可能的解决scheme：

• 所有的快照视图
• 包含dll或jar或exe的快照视图（每五分钟不更改一次的文件：每天更新一次）以及只有源可见的dynamic视图。

Answer 2

成本是一个相当明显的缺点。 不仅仅是许可证费用，还包括ClearCase专家工资的成本。 几乎我所知道的所有使用ClearCase的公司似乎都至less有一个人，其唯一目的就是驯服这个不守规矩的野兽。

事实上，需要一个全职保姆是很复杂的也是令人担忧的。

Answer 3

一个系统的绝对噩梦。 这让我希望我们可以回到VSS！ （不要介意任何现代的源代码控制系统，如Subversion或Git！）

• 这是slooooow 。
• 如果您使用dynamic视图，networking出现故障， 则无法访问源的工作副本 。 你什么都不能做，只能静坐等待 。
• 如果使用快照视图，您似乎总是遇到冲突和“劫持”文件，因此工作副本中的文件永远不会与源资源库中的文件完全相同 。
• 无论何时您尝试大量更新或交付操作， 都会出于某种原因而失败 ，因此要求您的ClearCase专家每天花几个小时计算出来。 哦，是的，你必须有一个专职的全职ClearCase专家！
• 当它失败的时候，你也经常无法回滚操作，所以你被困在正在进行的操作中， 开发人员被阻止 。
• 当你浏览漂亮的图标时， graphics用户界面非常差 – 无法调整窗口大小以查看完整的文件path！
• 他们的支持人员很不情愿解决任何问题。 他们的第一个回应总是“ 这是devise ”，“你能解决吗？ 如果他们最终提供了一个解决scheme（经过多次辩论），这将是最直接的问题最基本的解决scheme。

基本上，它是缓慢，复杂和不可靠的地狱。 哦，我提到它是可笑的昂贵 ？ 他们可能卖的唯一方法就是和决策者谈话，他们从来没有使用过产品，决不会这么做！ 我很确定世界上没有开发商会购买它。

Answer 4

primefaces提交和更改集是我对ClearCase最大的抱怨。 假设您将五个文件作为错误修复或重构的一部分进行检查。 然后发现有些东西搞砸了，你需要恢复。 祝你好运，find他们是哪五个文件， 每个人需要在哪个版本。 但让我们退后一步。 你刚完成编辑这五个文件，现在是时候提交了。 前四个就好了。 最后一个需要大规模合并。 其他四个文件已经签入。他们不等你在最后一个文件中完成必要的更改。 我当然希望没有人更新或使用dynamic视图。 持续集成构build服务器也将失败。

有时我们会创build一个全新的目录，其中包含需要检入的文件，但是我们不想在完成之前检查它们。 这很早，一切都还是波动，为什么要检查一下你可能会很快删除的东西呢？ 好，到目前为止。 现在是时候登记了。您将新创build的文件夹添加到源代码pipe理。 那么，ClearCase不是recursion的，所以只有那个文件夹被检入。有了SVN，那个文件夹和它下面的所有东西都会被添加。 开发人员需要记住添加所有内容，否则很多文件将会丢失。

ClearCase拥有这些文件和文件夹，所以你不能修改任何东西，除非你先检查出来。 eclipse插件在这里带走了很多麻烦。 我不能告诉你我在vi上打了多less文件来快速修改，只是发现我忘了先检查一下。 结帐也不是recursion的。

无需更改，更新可能会非常缓慢。 当您使用快照视图进行更新时， 每个文件都会更新，而不仅仅是已修改的文件。 我从事的项目有20,000多个文件。 我会远程到我的工作机器，开始更新，然后开车上class; 得到咖啡 在完成时去我的桌子。 这听起来可能是夸张的，但可悲的是没有。

dynamic视图是可怕的，除非你是一个非常小的团队。 如果是这样的话，为什么你甚至有ClearCase？ 我看到无数人的观点被破坏，因为有人检查了打破别人观点的文件。 您应该始终更新并合并您自己视图中的任何冲突。 这样，变化只会影响你。 有了dynamic的观点，在推倒之前不能合并， 你只是承诺和希望。

我知道成本可能不是一个大问题，但为公司赚钱的开发人员会喜欢在有趣的事件或新设备上花费5万到10万美元（取决于ClearQuest许可，这是常见的增加）椅子，监视器等）。 IBMbuild议让员工继续使用ClearCase。 为什么不重新让这些人为公司创造收入，而不是确保事情不会崩溃和燃烧？

---

我曾经听说过的一些原因是：

• 学习需要时间和金钱
  • 学习SVN或Mercurial应该不超过一天。 只有ClearCasebuild议拥有一定比例的pipe理员与开发人员。
• 迁移将是痛苦的
  • 这就是为什么存在工具： cc2svn
  • Mercurial并不容易
• 安全
  • SVN AFAIK没有已知的漏洞，开发团队致力于解决任何被发现的问题。 国防部似乎与SVN确定。
• 事后没有实际的生产力增长
  • 它需要永远试图追踪没有变更集的错误。 我喜欢能够回滚，直到我看不到错误。 你不能在ClearCase中做到这一点。
• 多站点
  • WANdisco解决了这个问题。 这不是免费的。

ClearCase比其他的更好的做法是分支单个文件，同时保持其他分支在同一轨道上。

Answer 5

我在ClearCase中所做的一切似乎都很难 。 而我从来没有与其他系统的印象（有时可能除外CVS）。

我使用过SVN，CVS，Clearcase和Mercurial。

Answer 6

我对ClearCase的经验是一场灾难，我会继续介绍Don需要一名常驻专家的意见 – 不幸的是我们有不止一个。 我有CVS和其他版本控制系统的经验，我对这些概念很熟悉，但是我发现ClearCase的文档是不可理解的，不得不多次寻求帮助; 不同的专家给我提出了相互矛盾的build议，以至于我们实际上破坏了cd 。 也就是说，在UNIX shell中发出ClearCase命令之后，“cd”命令失败并显示一条错误消息。

版本控制系统的基本任务非常简单。 老实说，我认为六七个命令就足够了，使用一个可以和别人玩的好的文件系统。 对我来说，ClearCase看起来像是一个营销执行官故意让事情复杂化的结果，使产品看起来复杂和强大。 我听说它可以configuration为以一种简单，安全，可靠的方式运行，但是又需要专家的服务 – 开箱即用，就像电动瑞士军刀。

Answer 7

我所经历的任何与ClearCase相关的事情都是低效，丑陋，过于复杂，缓慢，混乱，昂贵和不方便的。

这似乎吸引了pipe理人员和工程师，只知道这是错误的。

该死，IBM和Rational必须有惊人的销售人员销售这样一个糟糕的产品。

Answer 8

由于这里给出的许多原因，我们只是将CC从CC移植到Git上。 我想补充一个理由，远离CC或任何其他商业来源的控制系统。

您的重要业务数据是ClearCase的人质。 你不能把它弄出来。

您的重要业务数据是代码，其版本历史logging以及所有元数据（如提交评论），签入人员和时间。

所有软件的使用寿命都会有限制。 当你引入一个吞噬重要业务数据的新系统，无论是代码，错误，客户数据还是不是什么的时候，你总是应该问自己：我怎样才能重新获得我的数据？ 如果你不能回答这个问题，你就不应该引入这个系统。

当我们迁移时，我们失去了大部分的历史和所有的元数据。 从本质上讲，我们只有历史版本对应于已发布的版本，但是关于什么样的更改是针对客户请求丢失而做的信息（我们在客户支持和错误票系统中有这些数据，所以它不会完全丢失，源代码不见了）。

在短期到中期，这对我们来说是一个滋扰和问题。 在几年的时间里，这已经不再重要了，但是也许在1 – 3年之内就会变得重要。

（有把商业工具迁移到其他供应链pipe理的商业工具，但它们不足以满足我们的需求，我怀疑这是否可行，我们所做的最小出口花了足够的时间。

吸取的教训是：永远不要把重要的业务数据委托给专有系统。

Answer 9

没有primefaces提交

一旦你签入文件，很难恢复到某个状态，因为primefaces提交不被支持。 当检入多个文件时，每个文件都会得到一个新的版本（类似于CVS），而不是签入本身。 我认为这是一个关键function，因为你几乎不想恢复单个文件，而是完成提交操作（应该映射任务）。 使用ClearCase，只能使用标签恢复到某些状态。 在实践中使用ClearCase标签为每个签入是矫枉过正，因此没有完成。

糟糕的用户界面

ClearCase Explorer的GUI只是一个大玩笑。 糟糕的可用性和丑陋的外观。 不提供不同且经常需要的function（例如，对工件进行recursion检查）。 与cygwin一起使用的命令行工具cleartool要好得多，但还是有些东西是不可用的，例如recursion地添加新的文件/文件夹到源代码控制。 如果我读了50行代码长的脚本来解决这个问题，我必须笑我的头。

高pipe理努力

对ClearCase野兽的pipe理远非明显或轻量级（与CVS，Subversion或Git等其他scm系统不同）。 希望将不less专门的ClearCase专家放在一起运行。

可怕的performance

没有什么比在与SCM-tool接口的情况下让开发人员等待更糟糕的了，就好像驾驶手刹一样。 它减慢你的大脑，也减慢你的工作。 获取全新的文件到快照视图需要大约30分钟的10K文物。 一个更新（没有文物被改变）相同的数额大约需要5分钟。 当进行大量的实验并且在不同的最新视图之间跳转意味着很多等待。 它变得更糟糕，当你正在处理文件，你想检入或更新它们。 退房，签入和添加源控制周期大约需要10-15秒，这显然是一场噩梦。 当你重构重命名/移动types或方法（很多文件可能会受到影响）时，会变得非常烦人。

缺乏对分布式开发的支持

今天，软件开发往往是一个分布式的东西（开发人员遍布世界各地，在同一个产品/项目上工作）。 ClearCase definetely不适合这个，因为它非常适合离线工作。 进行退房（在可以编辑文件/文件夹之前执行操作）需要连接networking。 在这里，你可以使用劫持选项，但这是一个相当于一个function的解决方法（你基本上只是解锁文件系统上的文件）。 如果您的开发站点距离您的ClearCase服务器很远，那么入住/退房延迟甚至会大大增加，以至于根本无法使用。 像使用ClearCase Multisite（scm数据库副本技术）一样，有一些解决方法，但是您必须为此付出额外的费用，而且对于pipe理员来说并不是微不足道的。

Git作为替代

虽然作为开源的大粉丝+支持者，我仍然愿意为好软件付钱。 但是看看IBM的怪物ClearCase，我不会在这里投资，所有这些讨论的缺点，更进一步的IBM似乎没有投入大量资金来改善他们的产品。 最近我看了一个Git SCM，看起来非常好，特别是它的分支+合并function，ClearCase有其主要优势。

这些信息来自http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/

Answer 10

可能是有史以来最糟糕的软件。 我不会为任何使用理性的公司工作。 除了CC完全崩溃，并经常dynamic构build我的工作站重新启动。 当你推动某些东西来源控制时，会发生什么呢？ 是你的代码然后放在丢失+find，备份在某个地方也许？ 不，它永远消失了。 所以，如果你使用这个巨大的昂贵的软件的情况下，保持重复的一切。 好的Rational / IBM。 捕捉源代码控制的最重要部分的方法，可靠性。 死缓。

Answer 11

ClearCase的缺点 – 这里是最深入的post的补充。

1. 合并工具是不值得的。 它几乎没有帮助你，记住你做的决定，它只是一个荣耀的差异。

2. 合并工具必须检出目录甚至检查是否需要合并。 它有点疯狂。

3. 我在工作中使用BitKeeper（让我们假设为Git），即使存在冲突，也可以合并两个存储库，即使使用命令行也是如此简单和易于使用，而具有大量GUI工具的ClearCase是一个漫长而费力的过程， 。

4. 所有GUI工具都需要大量的延迟。 即使看到文件上可以做什么，也需要高速连接。 因此，在家中使用的文件上的ClearCase工具右键单击可能需要一两分钟的高速互联网，因为networking需求量非常大。

5. 如果他们的视图规格与团队不同，有人可以完全搞乱仓库或者签入。 这是非常疯狂的，没有人可以检查一些分支; 他们需要适当的视图规范，这将顺便给他们正确的东西。 整个概念可以很好而灵活，但99％的时间只是造成很大的痛苦。 我提到你不能通过Microsoft Outlook通过电子邮件发送你的规范，因为CC工具不接受UTF-8，所以你不能复制粘贴它？

6. 我完全没有什么好说的CC。 我在2家公司使用了2年，并在整个时间心情愉快。 也不可能只在家里用自己的项目进行实验，所以你仍然会在家里学习SVN或Git，并被迫在工作中经历ClearCase的痛苦。 没有人知道曾经自愿使用CC。 他们只使用它，因为在工作的一些经理决定CC是救赎的道路，迫使每个人都迁移到它。 事实上，我上一个公司从CVS迁移到ClearCase，从ClearCase到SVN一年之后。 那是讨厌的。

7. ClearCase不只是让你说不的一件事。 就像住在一个被ant侵扰的房子里。 每只ant最好只是一个小小的不便，但这种感染会让你发疯。

Answer 12

我正在尝试在这里整理一些实际的post。 我并不是真的在这里说服你，一个人比另一个人好，除了以下几点：

• 如果您正在比较git和ClearCase，我恭敬地提出您需要更好地定义您的需求 – 如果您考虑将ClearCase用于“好”的理由，那么git可能甚至不在公式之中 – 对于企业级的源代码pipe理，imo。
• ClearCase将许多概念引入到其他系统所没有的版本控制空间中，所以它可能相当令人生畏和困惑。 特别是如果你有唯一的经验是阅读文档，这似乎是less数人在这里的情况。
• ClearCase绝对不适合庞大的代码库，由不在局域网上的VOB服务器开发人员支持。 你可以有许多复制的（多站点）VOB服务器让它们靠近远程开发者，但是如果这些远程站点只是一个开发者，这不一定实际可行。
• 你想要文件版本或存储库版本？ 这是一个非常重要的问题，必须筛选出一整套工具，使工作更轻松。 版本库的版本pipe理有很多优点（像一些海报宣称的那样，它不是“新的”），像Perforce这样的商业工具已经存在了十几年了，甚至可能有一些工具可以在Perforce之前进行版本库的更新）它不是万能的。
• With a sufficiently large installation of any source control system, you're going to need help. When considering tools, you need to consider how easy it will be to find people to help you (either job applicants who have experience, or consultants who will be there at a moments' notice to address any issues). There's no such thing as a maintenance-free SCM system, and assuming you have one will get you into more trouble than picking one that requires "too much" administration.
• Don't pay too much attention to people who talk about how bad "dynamic views" are – bad SCM policies are bad, regardless of the tool you're using. Your configuration management policies and practices have to be separate from your choice of tool – no tool will stop people from smashing all over your codebase if you don't define sensible branching and merging policies. If someone suggests that having developers directly commit onto /main is ever a sensible idea, you might want to walk away from that conversation.

ClearCase is a fine tool, but it is a complicated tool. There is no getting around this – it does not have an "easy install" mode. 🙂 From a technical standpoint, there's nothing that git or SVN can do that ClearCase cannot (although often the terminology is different, since Open Source projects tend to just invent new taxonomy where there already existed one), but some things are definitely easier/harder for a given system, depending on their design. ClearCase "snapshot" views are basically the same thing you would have if you checked out a repository from SVN or CVS – it's a local copy of the source code on your machine, with pointers back into the central server for tools to query version history, etc. You can work with these views without any network connection to the ClearCase server at all once they have been created, and you can "recycle" them to avoid downloading your entire repository again when you want to move to work on another branch, for example. "Dynamic Views" are basically a ClearCase invention, and the standard operating mode for a LAN. They appear the same as checking out an SVN repository, but they don't actually copy any files until you make changes. In this way the view is available immediately, but it obviously cannot be worked with if the main clearcase server is unavailable, and is unpleasant to work with over a high-latency connection. They also have the convenience of being able to be mounted as a network drive on any machine with access to the server on which they were created, so if your windows workstation dies, you can just log onto another one, mount your view, and get back to work, since all the files are stored either in the VOB server (for files you haven't modified on this branch), or the view_server (for files you have created or modified just in this view).

Also, and this deserves its' own paragraph….clearmerge is nearly worth the price of admission alone. It's hands down the best merge tool that I've ever used in my life. I firmly believe a lot of bad practice in SCM has developed because of a lack of high-quality merge tools, so CVS users never learned to use branches properly and this fear of branching has propagated to the current day for no particularly good reason.

Ok, all that being said, if you're looking for reasons not to use ClearCase, they're not hard to find, although I think that's the wrong way to go about it. Really you should need to come up with good reasons TO use ClearCase, not reasons for NOT using ClearCase. You should come into any SCM situation assuming that ClearCase is too much tool or too complicated a tool for the job, and then see if you have some situation that encourages you to use it anyhow. Having IBM or Rational logos is not a good reason.. 🙂

I would not even consider ClearCase unless you could say yes to all the following statements:

• You do now, or will eventually have, more than 50 developers working on the same codebase.
• Most of those developers are centrally located, or have high-throughput low-latency connections to a central location.
• You have a set of SCM policies and can identify how to use ClearCase to enforce those policies (really you should consider this for any tool)
• Money really is no object

Answer 13

My experience is mostly limited by CC, CVS and SVN. In principle, CC is technologically capable, enterprise ready and comparable by features with any modern VCS. But it has several flaws that make it unusable in any people-oriented environment. For process oriented environments it is probably more appropriate, though I doubt that such environments are appropriate by themselves. Maybe, in military, cosmic or medical software, I don't know. Anyway, I believe that even for these domains there are appropriate and still more friendly tools.

Beside being technically capable VCS, CC has several distinctive advantages:

• Dynamic views
• Nice version tree
• Triggers
• Good merge versioning, including renames

In my opinion, their use is limited excepting last one; and they don't compensate flaws. Dynamic view nice in theory, but not always available in practice. Version tree has much less use in other VCS, while necessary in CC because of proliferation of branches (see 6). Triggers, as I know, very detailed and capable, but I think that for most practical tasks SVN hooks are good enough. And now about disadvantages that mostly concerns usability:

• CC totally fails in sense of usability for main user group: for developers. And that is the main reason why I think that it should never be used in any environment, be it enterprise or not. Even if it were free, it would nevertheless suck your company's money by wasting time of your developers and frustrating them. This point is composed from:
  1. "Check out-Check In" with strict locking approach – it is counter-productive, refactoring unfriendly, and dangerous in repository organizations with single development branch for multiple developers. Meanwhile, the advantages of strict locking are negligible.
  2. Poor performance and high load
  3. It effectively cannot be used remotely without multi-site (due to 2). Multisite is expensive too. ClearCase Remote client is very limited. It don't even have cleartool (before version 7.1), leaving alone dynamic views.
  4. It can hardly be used offline. Dynamic views are just not work. Snapshot views are effectively read only, because you cannot check out without access to repository (see 1). Hijack is poor option which in fact means that CC gives up any responsibility for hijacked file. And CC cannot show you difference with previous revision when offline. SVN is able to show difference with previous revision even being offline.
  5. Overly complicated model, especially with UCM: VOBs, PVOBs, Projects, streams, branches, views, deliver, update, load, restore, rebase, merge, baseline, check in, check out. I think that half of this concepts are just superfluous and doesn't add value, while increasing both technical and conceptual complexity. Few developers understand even basic stuff about CC.
  6. Proliferation of branches. For example, repository often organized with stream per developer (due to 1). It just has no sense in SVN or most other VCSs.
  7. No repository wide revisions. Well, there are such revisions as understand, they called baselines. But when I see some file revision and want to get repository snapshot at the moment of that file revision, I will get some problems. I will need to do black magic with config spec to create a snapshot view, or find somehow through dynamic view if it is available.
  8. Crappy user GUI. Version tree, even being nice, has mediocre usability. Merge tool is just a pity. Other "features": not resizeable windows, absence of incremental search in some places, mouse-centric interface, look and feel in 1995 style, strange work flow distributed between Client and Project Explorer etc.
  9. CC provokes rare and vast check ins. You all know, that check ins must be small and frequent. But developers usually refrains from additional interactions with CC, hijack files and work in local VCS or even without VCS at all (which is more often, unfortunately). And then, after two weeks of development they begin commit comlex feature that adds 20 files and affects another 20 files. It lasts for a day or two, because they hijacked files and now need to perform manual merge with all new changes from repo and resolve all conflicts and discrepancies. During that process, code lies not compilable, because several files successfully got checked in and others do not. And after that it still lies not compilable because they forgot to add another 2 files to CC.
• It is very expensive
• It is very complex in terms of infrastructure and requires dedicated administrators

Answer 14

ClearCase seems extremely powerful, from the outside. But really, it's just that the number of commands and options you need to use for basic workflow is so high that these get hidden behind a few aliases or scripts, and you end up with something less powerful than CVS, with the usability of Visual Source Safe. And any time you want to do something a little more complicated than your scripts allow, you get a sick feeling in your stomach.

Compare this with Git, which seems complicated from the outside, but after a week working with it you feel completely in control. The repository model is simple to understand, and incredibly powerful. Because it's easy to get at the nuts and bolts, it's actually enjoyable to dig below the surface of your daily workflow.

For example, figuring out a trivial task such as how to just view a non-HEAD version of a file in a snapshot view took me a couple of hours and what I ended up with was a complete hack . Not the enjoyable sort of hack either.

But in Git, figuring out a seemingly complicated task such as how to interactively commit only some changes, (and leave the rest for later) was great fun, and all the time I have the feeling that the VCS is allowing me to organise code and history in a way that suits me, rather than history being an accident of how we used the VCS. "Git means never having to say 'you should have'" .

At my work, I use Git for all sorts of lightweight tasks, even within ClearCase. For instance, I do TDD, and I commit to Git whenever a bunch of tests pass and I'm about to refactor. When the task's eventually done, I check in to ClearCase, and Git helps me review exactly what I'm changing. Just try to get ClearCase to produce a diff across a couple of files – it can't! Use Google to find out the various hacks people have tried to work around this. This is something version control should do out of the box, and it should be easy! CVS has had this for decades!

Answer 15

• Nightmare to administer in secure environments
• Outdated technology
• Non-intuitive GUI
• Expensive
• Resource monster
• Sellout to Microsoft

In my opinion? Only reason to have it? If you are religiously following RUP.

Answer 16

The support is terrible. We've had tickets open for years. Our eclipse guru actually fixed a bug in their eclipse plugin locally in about 30 minutes by disassembling the java file. But the ticket still hasn't got past level one support. Every so often they either try to sneakily close it or ping it back to us 'to try on the latest version' (even though we sent them a reproduction recipe which they could try for themselves.).

Do not touch with a barge pole.

Answer 17

性能。

ClearCase is powerful, stable (IF properly maintained and supervised) but it's slow. Geological sometimes.

Dynamic views views lead to horrible build times, snapshot views can take ages to update (lunch break for large projects) or checkout (go home for the day).

Answer 18

Clearcase is so annoying it actually drives people to write poetry about it:

http://digital-compulsion.blogspot.com/2007/01/poetic-pathetic-version-control.html

http://grahamis.com/blog/2007/01/24/if-it-was-free-no-one-would-download-it/

Answer 19

• The developers will spend 1/2 their time figuring out clearcase before doing any work and once they've figured it out they'll install git locally and only push to the clearcase repo as needed.

• You'll have to employ a dedicated Clearcase admin.

Answer 20

I would suggest SVN for toolset and Git for scaling/workflow. I'd also suggest avoiding CC where possible. (Not counting money, the fact it is such a pain to use that is requires a full time admin is a total joke)

Answer 21

I recently had to wrangle with a similar situation. Maybe you can learn from my story.

The team I was newly assigned to was using a heavyweight tool in an convoluted, error-prone manner. I first attempted to sell them on my tools and processes of choice. This attempt failed miserably. I was flabbergasted that they would pick such a burdensome environment over one that was both easier and more effective. Turns out that they wanted to be disciplined, and using a painful process felt disciplined to them. It sounds wierd, but it's true. They had a lot of other misconceptions too. After I figured out what they were after, we actually stuck with the same tool suite (Serena), but massively changed how it was configured.

My advice to you is to figure out what matters to your team. Ripping on ClearCase won't get you anywhere unless you speak to their interests. Also, find out why they don't want to use alternatives. Basically do a little requirements gathering and fit your tool choices to your needs. Depending on your options, who knows, Clear Case may end up being the best option after all.

Answer 22

I'm not totally against ClearCase ( it does have it's advantages ), but to list out the disadvantages:

• License Limitations – I can't easily work from home, because I don't have access to the license server. Even with a snapshot view on my laptop I have to play tricks because I can't get a license. There is a special remote client, but adds tons of its own limitations to the mix
• License Limitations again – Only so many seats to go around, and then no one can use it.
• Unix tools out of date – ClearCase seems to run best on Unix systems, but the GUI tools suck there. Windows/Unix integration of ClearCase introduces all sorts of its own pains.

Answer 23

The biggest downfall for me is both the performance (especially if your VOB is multisite or offsite), and potentially lengthy downtimes.

If you're like me and work in a relatively small office as part of a large company (with no onsite IT), Clearcase servers going down can cost you the better part of a workday in non-productivity as well as getting the right people to get it fixed.

Bottom line, use it only if you really need it for what you are doing and make sure you have a beefy IT budget to maintain it.

Answer 24

ClearCase is perfectly usable if your willing to also use another version control system on top of it! personally I find using mercurial ontop of CC to work quite well.

Answer 25

1. no atomic checkins

As of the new version of version 7.1 CC provides atomic checkin as functionality IF you like that. Personally I would really not want it but apparently some people see that as "an essential feature". I NEVER would want one big bulk in one go as a sort of massive version. Then again… if you want it just turn it on.

so… no longer an argument.

Answer 26

We used UCM ClearCase integrated with ClearQuest (DR Tracking/change request system) for the last 4 years with more than 50 developers. We have over 50 UCM projects over thousand of streams that handled over 35K DRs and change requests. During this period we have officially made over 600 integration deliveries and while having up to 6 concurrent development and release efforts.

I am the main CM/ClearCase guy with a backup who is able to perform the regular delivery/merge and integration builds. The network and servers are supported by the IT team. All I can say is we have had virtually no problems coming from the CM side of this huge development effort and were never a show stopper. Our developers where trained with just the basic stuff and a simple steps were given to them whenever a new project (branch) was created at the request from the project management.

Too many developer complained about ClearCase because they lack the proper CM/IT/ClearCase/Process/Management support. Developers should focus on development not SCM or be a tool specialist. For a large software development, at least 5-7% of the budget should be spent on CM and tool support.

Answer 27

Running a JDK from a VOB in Linux.

Try it, you need to play with the LD_PRELOAD variable (I know!)

Answer 28

the point of "it needs a dedicated person" and "it is complicated" etc….

The core issue here with finding this a problem is that you have to define if you want to have configuration management performed in your organization (which is NOT version management). Configuration Management is like Project Management: even without a tool you still can do project managment and without a tool you can do Configuration Management. Lots of people have a hard time understanding this and lots of people think Configuration Management is equal to a tool which versions sources of software or something…… (therefore comparisons with subversions or other VERSION management systems)

ClearCase is a solution that is build for usage in a Configuration Management environment ERGO: there is a configuration manager (just like "there is a project manager").

So… if in your perception that dedicated person is there to manage a tool I think there is something very wrong. In my perception there is a dedicated person who does configuration management who from an end-user perpective only shows up when there is a problem with the tool but regards this as only 1% of his job.

So what you need to do (like in any other software project) go back to your requirements and put a list of requirements together on what your organisation wants with configuration management. AND YES like in any other software project you will have users (like eg developers) who totally not agree with other users (like eg management) on certain requirements. There lies the key imho on some reactions I read here.

And IMHO if you have the organization list of requirements AND a configuration manager in the mix…. the choice is pretty clear (see also the forum on http://www.cmcrossroads.com)

ClearCase is not a tool only for end-users entering their sources under version control like subversion or git. That is only 1% of why a configuration manager really wants a mature configuration management tool.

And… I think the choice of a CM system should never lay with developers equal to choosing the right project management tool or the right CRM system. Developers are end-users of a certain part of the functionality of the tool.

Answer 29

I will be maybe alone here, but ClearCase is not that bad as everyone says. It can handle huge repositeories. Dynamic view are pretty cool and powerful feature too. It is reliable, can be customized by adding triggers and constraints on a pef file basis, permissions, etc.

Unfortunatelly, it comes with a price, big price. It is costly, and to operate properly needs to be properly configured and maintained by dedicated IT team. It makes it really good for BigCo, but not so wise choice for SmallFirm.

I'm a big fan of DVCS and git, but can understand why would BigCo choose ClearCase over SVN and Git. What I can't understand why would anyone choose SVN over Git ;>

Answer 30

Dynamic Views. Must admire a fully functional translucent file system.

One big benefit is that the Intellectual Property is always in the corporate network. A laptop can be lost/stolen and no source code in jeopardy.

Another is the instant access to source code and changed files, no time is ever spent downloading anything.

It serves well for the purpose it has.