ClearCase 优缺点

ClearCase的缺点 - 对此处最深入的帖子的补充。

1. 合并工具不值得使用。它几乎没什么作用，不会记住您做出的任何决定，只是一个华丽的 diff 工具。

2. 合并工具必须检查目录，才能确定是否需要进行合并。这有点荒谬。

3. 我在工作中使用BitKeeper（假设为Git），即使存在冲突，合并两个存储库也是如此简单和用户友好，即使使用命令行也很容易。而 ClearCase 却有大量 GUI 工具的过程又漫长又费力，而且极易出错。

4. 所有 GUI 工具都需要大量的延迟。甚至查看文件上可执行的操作都需要高速连接。因此，即使在家中使用高速互联网，对 ClearCase 工具上的文件右键单击可能需要一两分钟，因为需要进行大量的网络操作。

5. 如果某人的视图规范与团队不同，他们可能会完全搞砸存储库或签入。这相当荒谬，因为没有人可以简单地检出一些分支；他们需要适当的视图规范，这将意外地为他们提供正确的内容。整个概念可以很好地灵活应用，但99%的时候它会带来很多痛苦。我是否提到过你不能通过 Microsoft Outlook 发送你的规范邮件，因为 CC 工具不接受 UTF-8，所以你无法复制粘贴它？

6. 我对CC绝对没有任何好话要说。在两个公司使用了 2 年，转投别处后感到非常开心。它也不可能在家中只是尝试自己的项目，所以你仍然需要在家学习 SVN 或 Git，并被迫在工作中经历 ClearCase 的痛苦。我认识的没有人是自愿使用 CC 的。他们只是因为某个经理在工作中决定 CC 是救赎之路，而强迫每个人都迁移到它。事实上，我的最后一家公司从 CVS 迁移到 ClearCase，一年后再从 ClearCase 迁移到 SVN。它是那么讨厌。

ClearCase 不仅是让你产生拒绝的一个因素。它就像住在遭受蚂蚁侵扰的房子里，每只蚂蚁最多只是轻微的不便，但是整个蚁群会让你发疯。

我正在尝试将一些评论整合成一个实际的帖子。我并不是来说服你哪个更好，只是想提出以下几点：

• 如果您正在比较git和ClearCase，我恭敬地建议您更好地定义自己的需求 - 如果您考虑使用ClearCase有一个“好”的原因，那么git可能甚至不在考虑范围内-就我的看法而言，它对于企业级源代码控制来说还太新。
• ClearCase在版本控制领域引入了许多其他系统没有的概念，因此可能会非常令人望而生畏和困惑。特别是如果您唯一的经验是阅读文档，这似乎是一些人的情况。
• 对于不在LAN上拥有VOB服务器的开发人员支持的大型代码库，ClearCase绝对不适用。您可以拥有许多复制（多站点）VOB服务器，以使它们靠近远程开发人员，但是如果那些远程站点只有一个开发人员，这未必可行。
• 您想要文件版本控制还是存储库版本控制？这是一个非常重要的问题，也将必然过滤出整个工具集，使您的工作更加轻松。存储库版本控制具有许多优点（它并不像一些帖子所声称的那样“新”-商业工具如Perforce已经存在了十多年，甚至可能存在于Perforce之前执行存储库版本控制的工具），但它并非治标药。
• 对于任何源代码控制系统的足够大的安装，您将需要帮助。在考虑工具时，您需要考虑寻找帮助的人员有多容易（具有经验的求职者或顾问将随时在那里解决任何问题）。没有无需维护的SCM系统，假设您有一个会给您带来更多麻烦，而不是选择需要“过多”管理的系统。

不要太在意那些谈论“动态视图”有多糟糕的人 - 不管你使用什么工具，糟糕的软件配置管理政策都是糟糕的。 你的配置管理政策和实践必须与你选择的工具分开 - 如果你没有定义合理的分支和合并政策，任何工具都无法阻止人们随意更改你的代码库。 如果有人建议开发人员直接提交到/main是一个明智的想法，你可能需要离开那个对话。

ClearCase 是一款好工具，但是它是一个复杂的工具。无论如何都无法避免这一点——它没有“简易安装”模式。从技术角度来看，git 或 SVN 无法做到 ClearCase 无法做到的事情（尽管术语通常不同，因为开源项目倾向于在已经存在的术语上发明新的分类），但是某些系统针对特定设计的一些事情肯定更容易/更难。ClearCase 的“快照”视图基本上与从 SVN 或 CVS 检出存储库时所拥有的视图相同——它是源代码在本地机器上的副本，具有指向中央服务器的指针，供工具查询版本历史等等。一旦创建了这些视图，您可以在没有与 ClearCase 服务器任何网络连接的情况下使用这些视图，并且您可以“回收利用”这些视图，以避免在要移动到另一个分支进行工作时重新下载整个存储库。 “动态视图”基本上是 ClearCase 的发明，并且是局域网的标准操作模式。它们看起来与检出 SVN 存储库相同，但是在您进行更改之前，它们实际上并未复制任何文件。通过这种方式，可以立即访问该视图，但是如果主要的 ClearCase 服务器不可用，则无法使用该视图，并且通过高延迟连接进行工作时很不愉快。它们还具有一些方便的功能，例如可以在任何拥有访问创建它们的服务器的机器上作为网络驱动器挂载它们，因此，如果您的 Windows 工作站崩溃了，您只需登录另一个工作站，挂载您的视图，然后继续工作，因为所有文件都存储在 VOB 服务器（对于您尚未在此分支上修改的文件）或 view_server 中（对于您在此视图中仅创建或修改的文件）。

此外，这值得单独一段...clearmerge 几乎完全值得购买费用。这是我使用过的最好的合并工具。我坚信，由于缺乏高质量的合并工具，SCM 中出现了许多不良实践，因此 CVS 用户从未学会正确使用分支，这种对分支的恐惧已经传播到了当前日子而没有特别好的原因。

好的，话虽如此，如果你正在寻找不使用ClearCase的原因，这并不难找到，尽管我认为这样做是错误的。实际上，你应该需要找出使用ClearCase的好理由，而不是找出不使用ClearCase的理由。在任何版本控制情况下，你都应该认为ClearCase是过于复杂的工具或者不适合这个工作，然后看看是否有一些情况鼓励你仍然使用它。仅仅因为拥有IBM或Rational的标志并不是一个好理由.. :-)

除非你能回答以下所有陈述的问题都是“是”，否则我甚至不会考虑使用ClearCase：

• 你现在或将来有超过50名开发人员在同一个代码库上工作。
• 其中大部分的开发人员位于中心位置，或者与中央位置之间具有高吞吐低延迟的连接。
• 你有一套SCM策略，并且可以确定如何使用ClearCase来执行这些策略（实际上，你应该为任何工具考虑这一点）
• 金钱真的不是问题

我的经验主要局限于CC、CVS和SVN。原则上，CC在技术上具备能力，企业准备就绪，并且与任何现代版本控制系统的功能相当。但它有一些缺点，使它在任何以人为本的环境下都无法使用。对于过程导向的环境来说，它可能更合适，尽管我怀疑这样的环境本身是否合适。也许，在军事、航天或医疗软件中，我不知道。无论如何，我相信即使对于这些领域，也有更合适、更友好的工具。
除了作为技术能力强大的版本控制系统外，CC还具有几个独特的优点：

• 动态视图
• 漂亮的版本树
• 触发器
• 良好的合并版本控制，包括重命名

在我看来，除了最后一个之外，它们的使用受到限制；而且它们无法弥补缺陷。动态视图在理论上很好，但在实践中并不总是可用。版本树在其他版本控制系统中的使用要少得多，而在CC中却必需，因为分支的数量很多（见6）。据我所知，触发器非常详细和有能力，但我认为对于大多数实际任务来说，SVN钩子已经足够好了。现在让我们谈谈主要涉及可用性的缺点：
CC在可用性方面完全失败了其主要用户群体：开发人员。这也是我认为它不应该在任何环境中使用的主要原因，无论是企业还是非企业。即使它是免费的，它仍然会浪费你公司开发人员的时间并让他们感到沮丧。这一点由以下几个方面组成：

1. “检入-检出”与严格锁定方法相结合 - 这是逆生产的，不利于重构，并且对于具有多个开发分支的存储库组织来说是危险的。与此同时，严格锁定的优点微不足道。
2. 性能差，负载高
3. 如果没有多站点（由于2），则实际上无法远程使用。多站点也很昂贵。ClearCase Remote客户端非常有限。它甚至没有cleartool（7.1版本之前），更别说动态视图了。
4. 它几乎无法脱机使用。动态视图根本不起作用。快照视图实际上只读，因为你不能在没有访问存储库的情况下检出（见1）。Hijack是一个糟糕的选择，事实上意味着CC放弃了对劫持文件的任何责任。而且CC无法在脱机时显示与以前版本的差异。SVN甚至能够在脱机时显示与以前版本的差异。
5. 过于复杂的模型，特别是UCM：VOBs，PVOBs，项目，流，分支，视图，交付，更新，加载，恢复，rebase，合并，基线，检入，检出。我认为这些概念中有一半是多余的，没有增加价值，同时增加了技术和概念上的复杂性。很少有开发人员理解关于CC的基本知识。
6. 分支的扩散。例如，存储库通常根据每个开发人员的流进行组织（由于1）。这在SVN或大多数其他VCS中是没有意义的。
7. 没有存储库范围的修订版。好吧，有一些理解的修订版，它们被称为基线。但是当我看到某个文件修订版并想要在该文件修订版的那一刻获取存储库快照时，我会遇到一些问题。我需要使用配置规范进行黑魔法来创建快照视图，或者通过动态视图找到某种方式（如果可用）。
8. 糟糕的用户GUI。版本树，即使很好看，也具有平庸的可用性。合并工具只是可怜。其他“功能”：不可调整大小的窗口，在某些地方没有增量搜索，以鼠标为中心的界面，外观和感觉都是1995年的风格，奇怪的工作流在客户端和项目资源管理器之间等。
9. CC会引发罕见且广泛的检入。你们都知道，检入必须是小型和频繁的。但开发人员通常避免与CC进行额外的交互，劫持文件并在本地VCS甚至没有使用VCS（不幸的是这更加普遍）。然后，在两周的开发之后，他们开始提交添加

ClearCase表面上看似极为强大，但实际上，你需要使用的基本工作流命令和选项数量非常之高，以至于这些命令被隐藏在几个别名或脚本后面，你最终得到的东西比CVS还不那么强大，而且可用性也不如Visual Source Safe。每当你想做一些比你的脚本允许的更复杂的事情时，你就会感到一种恶心的感觉。
相比之下，Git表面上看起来很复杂，但是在使用了一周之后，你会完全掌握它。存储库模型易于理解，而且极其强大。因为可以轻松地获取底层细节，所以挖掘日常工作流程下面的内容实际上是一件愉快的事情。
例如，找出一个微不足道的任务，比如如何只查看快照视图中文件的非HEAD版本，花费了我几个小时，最终我得到的是一个完整的hack。并不是一种愉快的hack。

在Git中，解决诸如如何交互式地提交一些更改（并将其余部分留待以后）这样看似复杂的任务非常有趣。我时刻感到版本控制系统允许我以适合自己的方式组织代码和历史记录，而不是历史记录是我们如何使用版本控制系统的偶然事件。"Git意味着永远不必说'你应该有'"。

在我的工作中，我使用Git处理各种轻量级任务，甚至在ClearCase内部也是如此。例如，我进行TDD，并在一堆测试通过并准备重构时提交到Git。当任务最终完成时，我会检入ClearCase，而Git则帮助我准确地查看我正在更改的内容。只需尝试让ClearCase对几个文件进行差异比较-它无法做到！使用谷歌来找出人们已尝试的各种黑科技。这是版本控制应该开箱即用并易于操作的功能！CVS已经拥有这个功能几十年了！

• 在安全环境下管理起来很麻烦
• 技术已经过时
• 非直观的图形用户界面
• 价格昂贵
• 占用资源巨大
• 出售给微软

我个人认为，唯一使用它的理由是如果你坚定地遵循RUP。

支持非常糟糕。我们已经开了几年的工单。我们的Eclipse专家通过反汇编Java文件在本地修复了其Eclipse插件中的一个错误，仅用了大约30分钟。但是该工单仍未经过一级支持。他们每隔一段时间就会试图偷偷关闭它或将其退回给我们“尝试最新版本”（尽管我们已经向他们发送了可供自己尝试的重现步骤）。不要接近它。

性能。

ClearCase很强大，稳定（如果得到适当的维护和监督），但速度较慢。有时候会像地质运动一样缓慢。

动态视图会导致可怕的构建时间，快照视图可能需要花费很长时间才能更新（对于大型项目来说可以用午餐时间来等待）或签出（可以回家休息一天）。

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/

• 开发人员将花费一半的时间在开始任何工作之前弄清楚Clearcase，一旦他们弄清楚了，他们会在本地安装Git，并仅在需要时推送到Clearcase repo。

• 您需要雇用一位专门的Clearcase管理员。

我最近也遇到了类似的情况。也许你可以从我的故事中学到一些东西。

我被分配到的团队在使用一个复杂笨重的工具，并且使用方式容易出错。我首先尝试向他们推销我自己喜欢的工具和流程，但是这次尝试失败了。我很惊讶他们会选择一个既繁琐又不够有效率的环境而不是更简单更有效的环境。原来他们想要有纪律性，在使用痛苦的流程时感觉到有纪律性。听起来很奇怪，但这是真的。他们还有很多其他误解。当我弄清楚他们的需求后，我们实际上仍然使用同样的工具套件（Serena），但是大规模地改变了它的配置。

我给你的建议是找出对你的团队最重要的事情。批评 ClearCase 并不能帮你任何忙，除非你能满足他们的兴趣。此外，找出他们为什么不想使用其他替代方案。基本上做一些需求收集并根据需要选择工具。根据你的选择，谁知道，Clear Case 最终可能成为最佳选择。