因为我目前正在努力学习IBM Rational ClearCase，所以我想听听你的专业意见。
与其他版本控制系统（如Subversion或Git）相比，我对优缺点特别感兴趣。
答案 0 :(得分：110)
答案 1 :(得分：35)
成本是一个相当明显的劣势。不仅是许可证成本，还包括ClearCase大师的工资成本。我所知道的几乎所有使用ClearCase的公司似乎至少有一个人的唯一目的是驯服不守规矩的野兽。
事实上，要求全职保姆足够复杂，这也令人担忧。
答案 2 :(得分：27)
系统的绝对噩梦。 这让我希望我们可以回到VSS！（别介意像Subversion或Git这样的现代源代码控制系统！）
基本上，它是缓慢，复杂和不可靠的地狱。哦，我提到这是非常昂贵的？他们可能出售的唯一方法是与从未使用过该产品的决策者交谈，永远不会！我很确定世界上没有开发商会买它。
答案 3 :(得分：25)
原子提交和变更集是我对ClearCase最大的抱怨。假设你签入了五个文件，作为错误修复或重构的一部分。然后发现有些东西搞砸了，你需要还原。祝你好运，找到它们的五个文件以及每个一个版本需要使用的版本。但让我们退后一步。您刚刚完成了对这五个文件的编辑，是时候提交了。前四个通过就好了。最后一个需要大规模合并。其他四个文件已经签入。他们不会等你在最后一个文件中完成必要的更改。我当然希望没有人更新或使用动态视图。持续集成构建服务器也将失败。
有时我们会创建一个完整的新目录，其中包含需要检入的文件，但我们不希望在完成之前检查它们。这是早期的，一切都仍然不稳定，那么为什么要检查一下你可能会很快删除？好的，到目前为止很好。现在是时候办理登机手续了。您将新创建的文件夹添加到源代码管理中。好吧，ClearCase不是递归的，所以只签入单个文件夹。使用SVN，你可以选择添加该文件夹及其下面的所有内容。开发人员需要记住添加所有内容，否则会丢失许多文件。
ClearCase拥有文件和文件夹，因此除非您先检查过，否则无法修改任何内容。 eclipse插件在这里消除了很多麻烦。我无法告诉你有多少次我在vi中打开一个文件进行快速更改，却发现我忘了先检查一下。 Checkout也不是递归的。
如果没有更改集，更新可能会非常缓慢。使用快照视图进行更新时，每个文件都会更新，而不仅仅是修改后的文件。我参与了一个包含20,000多个文件的项目。我会远程到我的工作机器，开始更新，然后开车上班;喝咖啡;在它结束时去我的办公桌。这可能听起来有点夸张，但遗憾的是不是。
动态视图很糟糕，除非你是一个非常小的团队。如果是这样的话，为什么你甚至有ClearCase？我看到无数人的观点变得模糊，因为有人检查了破坏其他人观点的文件。您应该始终更新并合并您自己视图上的任何冲突。这样，更改只会影响您。使用动态视图，在推回之前无法合并;你只是承诺并希望。
我知道成本可能不是一个大问题，但为公司赚钱的开发商会喜欢花费5万到10万美元（取决于ClearQuest许可证，这是一个常见的补充），无论是有趣的活动还是新设备（椅子，监视器等）。 IBM建议让员工继续使用ClearCase。为什么不重新利用这些人为公司创收，而不是确保事情不会崩溃和燃烧？
我听说过没有切换的一些原因：
ClearCase唯一比其他文件做得更好的是分支单个文件，同时将其他文件保持在与另一个分支相同的轨道上。
答案 4 :(得分：20)
我在Clearcase中所做的一切似乎都是 hard 。然而，我从未对其他系统产生这种印象（有时候除了CVS之外）。
我使用过SVN，CVS，Clearcase和Mercurial。
答案 5 :(得分：15)
我使用ClearCase的经历是一场灾难，我将在Don的声明中说它需要一位常驻专家 - 不幸的是我们不止一个。我有CVS和其他版本控制系统的经验，我熟悉这些概念，但我发现ClearCase文档难以理解，不得不多次寻求帮助;不同的专家给了我相互矛盾的建议，其中我们实际上打破了cd 。也就是说，在UNIX shell中发出ClearCase命令后，“cd”命令失败并显示错误消息。
版本控制系统的基本任务非常简单。老实说，我认为六个命令就足够了，使用的文件方案可以很好地与其他人一起使用。对我来说，ClearCase看起来像是营销执行官故意使事情变得复杂化的结果，使产品看起来更加精致和强大。我听说它可以被配置为以简单，安全，可靠的方式运行，但同样需要专家的服务 - 开箱即用它就像一把机动瑞士军刀。
答案 6 :(得分：15)
由于这里给出的许多原因，我们只是将CC迁移到Git上。我想补充一个理由，远离CC或任何其他商业源控制系统。
您的重要业务数据是代码，其版本历史记录以及所有元数据，例如提交注释，签入时和时间。
所有软件的使用寿命都有限。当您引入一个吞噬重要业务数据的新系统时，您应该总是问自己，无论是代码，错误，客户数据还是什么不是：我如何再次获取数据？如果你不能回答这个问题，你就不应该引入那个系统。
当我们迁出时，我们丢失了大部分历史记录和所有元数据。基本上我们只有与发布版本相对应的历史记录，但是有关为响应客户请求丢失而做了哪些更改的信息（我们在客户支持和错误提单系统中有这些数据，所以它并没有完全丢失，而是与源代码消失了。
在短期到中期内，这将介于我们的麻烦和问题之间。在几年的时间里，它不再重要了，但也许1到3年就很重要了。
（有一些商业工具可以将CC迁移到其他SCM，但它们不足以满足我们的需求，我怀疑它是否可行。我们做的最小出口时间足够长。）
吸取的教训是：永远不要将重要的业务数据委托给专有系统。
答案 7 :(得分：15)
我所经历的所有与ClearCase相关的任何能力都是低效，丑陋，过于复杂，缓慢，混乱，昂贵且不方便的。
它似乎吸引了管理人员和工程师，他们一切都错了。
该死的，IBM和Rational必须有出色的销售人员来销售这样一款糟糕的产品。
答案 8 :(得分：14)
无原子提交
一旦签入文件，很难恢复到某个状态，因为不支持原子提交。签入多个文件时，每个文件都会获得一个新版本（类似于CVS），而不是签入本身。我认为这是一个至关重要的功能，因为您几乎不想恢复单个文件，而是完成提交操作（应该映射任务）。使用ClearCase，您只能使用标签恢复到某些状态。实际上，每次办理登机手续时使用ClearCase标签都是过度杀伤，因此没有完成。
糟糕的用户界面
ClearCase Explorer的GUI只是个大笑话。糟糕的可用性和难看的外观。不提供不同且通常必需的功能（例如，递归地检查工件上的工件）。与cygwin一起使用的命令行工具cleartool要好得多，但仍有一些东西不可用，比如递归添加新的文件/文件夹到源代码控制。如果我阅读了50行代码长脚本来解决这个问题，我不得不大笑。
高度管理
管理ClearCase野兽远非明显或轻量级（与CVS，subversion或Git等其他scm系统不同）。预计会有相当多的专业ClearCase专家让它继续运行。
表现糟糕
让您的开发人员在与SCM工具接口时等待更糟糕的是，这就像启用手刹一样驾驶。它会减慢你的大脑和你的工作。将新鲜文件添加到快照视图大约需要30分钟才能获得10K工件。相同数量的更新（没有更改工件）大约需要5分钟。在进行大量实验并在不同的最新视图之间跳转意味着需要等待很多时间。更糟糕的是，当您处理文件并且想要签入或更新它们时。签出，签到和添加源控制周期大约需要10-15秒，这显然是一场噩梦。当您重构重命名/移动类型或方法时（许多文件可能会受到影响），它会变得非常烦人。
缺乏对分布式开发的支持
今天，软件开发通常是分布式的东西（开发人员遍布全球，致力于同一产品/项目）。 ClearCase definetely不适用于此，因为它非常适合离线工作。执行签出（在编辑文件/文件夹之前执行操作）需要您进行网络连接。在这里你可以使用劫持选项，但这是一个解决方法作为一个功能（你基本上只是解锁文件系统上的文件）。如果您的开发站点远离ClearCase服务器，则签入/签出延迟甚至会大幅增加，根本无法使用。有一些解决方法，比如使用ClearCase Multisite（scm DB副本技术），但是你必须支付额外费用，并且管理起来并不容易。
Git as alternative
虽然我是开源的忠实粉丝和支持者，但我仍然愿意为优质软件付钱。但是看看IBM怪物ClearCase我不会在这里投入资金，它有所有这些讨论的缺点，而且IBM似乎并没有投入大量资金来显着改善他们的产品。最近我看了一个看起来非常好的Git scm，特别是它的分支+合并功能，其中ClearCase有其主要优势。
此信息取自http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/
答案 9 :(得分：13)
可能是有史以来最糟糕的软件。我不会为任何使用理性的公司工作。除了CC在动态构建中经常崩溃并重新启动我的工作站。当你推动某些东西来源控制而CC会做它最擅长的事情时会发生什么，崩溃？你的代码然后被丢失+发现，可能在某处备份吗？不，它永远消失了。因此，如果您处于使用这一巨大昂贵软件的可怕情况，请保留所有内容的重复。干得好Rational / IBM。捕获源控制最重要部分的方法，可靠性。死得很慢。
答案 10 :(得分：12)
ClearCase的下行 - 这是此处最深入的帖子的补充。
合并工具不值得。它几乎没有帮助你，记得你做出的决定，只是一个美化的差异。
如果需要合并，合并工具必须检查目录甚至CHECK。它有点疯狂。
我在工作中使用BitKeeper（让我们假设Git），并且即使存在冲突也合并两个存储库即使使用命令行也是如此微不足道和用户友好，而具有大量GUI工具的ClearCase是一个漫长而费力的过程这也非常容易出错。
所有GUI工具都需要大量的延迟。即使看到可以对文件执行的操作也需要高速连接。因此，在家中工作的文件上右键单击ClearCase工具可能需要一两分钟的高速互联网，因为网络需求极大。
如果他们的观点规格与团队不同，有人可能会完全搞乱存储库或签到。对于没有人可以查看某个分支而言，这是非常疯狂的;他们需要适当的视图规范，偶然会给他们正确的东西。整个概念可以很好而且灵活，但99％的时间只会造成很多痛苦。我提到你不能通过Microsoft Outlook发送你的规范，因为CC工具不接受UTF-8所以你不能复制粘贴吗？
我对CC很绝对没什么很好。我在2家公司使用了2年，并且在整个时间内心情愉快地放弃了它。在家里用自己的项目进行实验也是不可能的，所以你仍然会在家里学习SVN或Git，并被迫在工作中经历ClearCase的痛苦。我认识的任何人都没有自愿使用过CC。他们只使用它，因为一些工作经理决定CC是救赎之路，并迫使每个人都迁移到它。事实上，我的最后一家公司从CVS迁移到了ClearCase，一年后从ClearCase迁移到了SVN。那是讨厌的。
ClearCase不只是让你说不的一件事。就像生活在充满蚂蚁的房子里一样。每只蚂蚁充其量只是一个小小的不便，但感染会让你发疯。
答案 11 :(得分：11)
答案 12 :(得分：9)
我的经验主要受到CC，CVS和SVN的限制。原则上，CC具有技术能力，企业就绪，可与任何现代VCS的功能相媲美。但它有几个缺陷，使其无法在任何以人为本的环境中使用。对于面向流程的环境，它可能更合适，但我怀疑这样的环境本身是合适的。也许，在军事，宇宙或医疗软件中，我不知道。无论如何，我相信即使对于这些领域，也有适当的，更友好的工具。
除了具备技术能力的VCS之外，CC还有几个独特的优势：
在我看来，他们的使用是有限的，除了最后一个;他们不补偿缺陷。动态视图在理论上很好，但在实践中并不总是可用。版本树在其他VCS中的使用要少得多，而在CC中由于分支的扩散而必需（见6）。据我所知，触发器非常详细和有能力，但我认为对于大多数实际任务而言，SVN钩子已经足够好了。现在主要关注可用性的缺点：
cleartool（在7.1版之前），只留下动态视图。答案 13 :(得分：8)
ClearCase从外部看起来非常强大。但实际上，只需要为基本工作流程使用的命令和选项的数量如此之高以至于它们隐藏在一些别名或脚本背后，并且最终得到的功能不如CVS，具有Visual Source的可用性安全。任何时候你想要做一些比你的脚本允许更复杂的事情，你的胃就会感到恶心。
将此与Git相比较，Git从外部看起来很复杂，但在使用它一周后，您会感到完全掌控。存储库模型易于理解，并且非常强大。因为很容易掌握螺母和螺栓，所以在日常工作流程的表面下挖掘真的很有趣。
例如，找出一个简单的任务，例如如何在快照视图中查看文件的非HEAD版本花了我几个小时，我最终得到的是a complete hack。不是那种令人愉快的黑客攻击。
但是在Git中，找出一个看似复杂的任务，例如如何交互式地只提交一些更改，（以及以后留待其余部分）非常有趣，而且我一直觉得VCS允许我以适合我的方式组织代码和历史，而不是历史是我们如何使用VCS的意外。 "Git means never having to say 'you should have'"
在我的工作中，我使用Git进行各种轻量级任务，即使在ClearCase中也是如此。例如，我做TDD，每当一堆测试通过并且我即将重构时，我就会承诺使用Git。当任务最终完成时，我会检查ClearCase，Git帮我查看我正在改变的内容。试着让ClearCase在几个文件中产生差异 - 它不能！使用谷歌找出人们试图解决的各种黑客攻击。这是版本控制应该开箱即用的东西，应该很容易！ CVS已经有这么几十年了！
答案 14 :(得分：7)
在我看来？只有理由拥有它？如果你虔诚地跟随RUP。
答案 15 :(得分：6)
支持很糟糕。我们已经开了多年票。我们的eclipse大师实际上通过反汇编java文件在大约30分钟内修复了他们的eclipse插件中的错误。但是机票还没有超过一级支持。每隔一段时间他们就会试图偷偷地将它关闭或者回到我们面前“尝试使用最新版本”（即使我们向他们发送了可以自己尝试的复制配方。）。
请勿使用驳船杆接触。
答案 16 :(得分：5)
性能。
ClearCase功能强大，稳定（IF维护和监督得当），但速度很慢。 地质有时。
动态视图视图导致可怕的构建时间，快照视图可能需要很长时间才能更新（大型项目的午休时间）或结帐（当天回家）。
答案 17 :(得分：4)
在开始任何工作之前，开发人员将花费1/2的时间计算出clearcase，一旦他们弄明白，他们将在本地安装git并根据需要推送到clearcase repo。
您必须聘请专门的Clearcase管理员。
答案 18 :(得分：4)
Clearcase太烦人了，实际上是让人们开始写诗：
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/
答案 19 :(得分：3)
我最近不得不面对类似的情况。也许你可以从我的故事中学习。
我新分配的团队正在以一种错综复杂的，容易出错的方式使用重量级工具。我首先尝试用我选择的工具和流程来销售它们。这次尝试失败了。我惊讶地发现，他们会选择一个既简单又有效的繁琐环境。事实证明，他们希望自己受到纪律处分，并且使用痛苦的过程会让他们受到纪律处分。这听起来很奇怪，但这是真的。他们也有很多其他误解。在我弄清楚他们追求的是什么后，我们实际上坚持使用相同的工具套件（Serena），但是大大改变了它的配置方式。
我的建议是弄清楚对你的团队有什么影响。除非你说出他们的兴趣，否则翻录ClearCase不会让你到任何地方。另外，找出他们不想使用替代品的原因。基本上需要收集一些需求并根据您的需求调整工具选择。根据您的选择，谁知道，Clear Case可能最终成为最佳选择。
答案 20 :(得分：3)
我建议SVN用于工具集，Git用于缩放/工作流程。我还建议尽可能避免使用CC。 （不算钱，事实上使用它是一件非常痛苦的事情需要一个全职管理员才是一个完全的笑话）
答案 21 :(得分：2)
我并不完全反对ClearCase（它确实有它的优点），但列出了缺点：
答案 22 :(得分：1)
如果您愿意在其上使用另一个版本控制系统，ClearCase是完全可用的！我个人觉得使用CC的mercurial ontop可以很好地工作。
答案 23 :(得分：1)
从版本7.1的新版本开始，如果您愿意，CC提供原子签入作为功能。就个人而言，我真的不想要它，但显然有些人认为这是“一个必不可少的特征”。我绝不会想要一次性大批量生产。然后再次......如果你想要它只是打开它。
所以...不再是争论。
答案 24 :(得分：1)
过去4年，我们使用UCM ClearCase与ClearQuest（DR跟踪/变更请求系统）集成，共有50多名开发人员。我们有超过50个UCM项目，数千个流，处理超过35K的DR和变更请求。在此期间，我们已正式完成600多个集成交付，同时最多可同时进行6个开发和发布工作。
我是拥有备份的主要CM / ClearCase人员，能够执行常规交付/合并和集成构建。 IT团队支持网络和服务器。我可以说的是，我们从这个巨大的开发工作的CM方面几乎没有任何问题，并且从来不是一个显示阻止。每当根据项目管理的要求创建新项目（分支）时，我们的开发人员只需要基本的东西和简单的步骤进行培训。
太多开发人员抱怨ClearCase，因为他们缺乏正确的CM / IT / ClearCase / Process / Management支持。开发人员应该专注于开发而不是SCM或成为工具专家。对于大型软件开发，至少应将5-7％的预算用于CM和工具支持。
答案 25 :(得分：1)
对我来说，最大的挫折是性能（特别是如果您的VOB是多站点或非现场），以及可能很长的停机时间。
如果你像我一样在大型公司的一个相对较小的办公室工作（没有现场IT），那么Clearcase服务器停机可能会让您在非生产力和工作日中花费更多的工作时间。合适的人来解决它。
最重要的是，只有当你真正需要它时才使用它，并确保你有足够的IT预算来维护它。
答案 26 :(得分：0)
在Linux中从VOB运行JDK。
尝试一下，你需要玩LD_PRELOAD变量（我知道！）
答案 27 :(得分：0)
“它需要一个专注的人”和“它很复杂”等......
此处发现此问题的核心问题是您必须定义是否要在组织中执行配置管理（这不是版本管理）。配置管理就像项目管理：即使没有工具，您仍然可以进行项目管理，如果没有工具，您可以进行配置管理。许多人很难理解这一点，许多人认为配置管理等同于一个版本软件源或其他东西的工具......（因此与颠覆或其他VERSION管理系统进行比较）
ClearCase是一个构建用于配置管理环境的解决方案ERGO：有一个配置管理器（就像“有一个项目经理”）。
所以...如果你认为有专门的人来管理工具，我认为有一些非常错误的东西。在我看来，有一个专门的人进行配置管理，他们从最终用户的角度出现只在工具出现问题时出现，但认为这仅仅是他工作的1％。
所以你需要做什么（就像在任何其他软件项目中一样）回到你的要求，并将需求列表放在你的组织想要的配置管理上。和YES一样，在任何其他软件项目中，您将拥有完全不同意某些要求的其他用户（例如管理层）的用户（例如开发人员）。关于我在这里读到的一些反应，关键在于它。
恕我直言，如果你有组织的要求清单和混合中的配置管理器......选择非常明确（另见www.cmcrossroads.com上的论坛）
ClearCase不仅仅是最终用户在版本控制下输入源代码的工具，如subversion或git。这只是配置管理器真正需要成熟配置管理工具的原因的1％。
并且......我认为CM系统的选择永远不应该与开发人员等同于选择正确的项目管理工具或正确的CRM系统。开发人员是该工具功能的某个部分的最终用户。
答案 28 :(得分：-1)
我可能会独自一人，但ClearCase并不是每个人都说的那么糟糕。它可以处理 巨大的 repositeories。动态视图也很酷很强大。它是可靠的，可以通过在pef文件的基础上添加触发器和约束，权限等来定制。
不幸的是，它带有价格，很高的价格。这是昂贵的，并且需要由专门的IT团队正确配置和维护正常运行。这对BigCo来说真的很好，但对于SmallFirm来说却不是那么明智的选择。
我是DVCS和git的忠实粉丝，但可以理解为什么BigCo会选择ClearCase而不是SVN和Git。我无法理解为什么有人会选择SVN而不是Git;＆gt;
答案 29 :(得分：-1)
动态视图。必须佩服功能齐全的半透明文件系统。
一个很大的好处是知识产权始终在企业网络中。笔记本电脑可能丢失/被盗，没有源代码处于危险之中。
另一个是即时访问源代码和更改的文件，没有时间花在下载任何东西上。
它有利于它的目的。
答案 30 :(得分：-3)
管理。我不得不安排多天的停机时间来执行从6到7的升级，并将半大规模（159GB）VOBS从旧服务器移动到SAN存储。使用像git或svn + svk这样的系统，这可以在一夜之间完成，几乎是自动完成的，对用户没有影响 - 他们从来没有注意到。他们不能在上游推动变革，但他们可以继续发挥作用。使用ClearCase或原始SVN，它们受存储库服务器的支配。
ClearCase UCM是一个很棒的工具，我喜欢它并认为可以做些什么来为SVN / mercurial / git / bzr添加类似的功能 - 而不是你不能用钩子脚本实现它，但这是一个自定义的 - 每个站点的关闭。 UCM是如此普遍，每个人都这样做，但几乎没有人在存储库中跟踪它。 ： - /