ClearCase优点/缺点[关闭]

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

与Subversion或Git之类的其他版本控制系统相比，我对优点/缺点特别感兴趣。

您可以在我的SO答案中找到ClearCase和Git之间的良好比较：
“每个开发人员都应该了解ClearCase的基本概念是什么？ ”，说明了一些主要差异（以及ClearCase的一些缺点）

以文件为中心的操作

ClearCase最重要的缺点是其旧的“以文件为中心”的方法（与SVN或Git或Perforce等中的“以存储库为中心”的方法相反），
这意味着每个文件的每次签入或签入都是完成的。操作的原子性在文件级别。
将其与非常冗长的协议以及开发人员工作站和VOB服务器之间可能具有多个节点的网络结合起来，您最终可能会得到一个相当慢且效率低下的文件服务器（ClearCase是其核心）。

每个文件的文件操作意味着：缓慢的递归操作（例如，递归检出或递归“添加到源代码管理”，即使按clearfsimport）。
甲快速LAN是强制性的，以减轻健谈协议的副作用。

集中式VCS

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

• 仍可在快照视图中使用（但仅适用于被劫持的文件）
• 如果他们使用动态视图，请等待网络的恢复

昂贵的分布式VCS选项

您可以通过复制Vob来具有一些分布式VCS功能。
但：

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

旧的且不友好的GUI

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

UCM不一致和连贯性

如“如何利用ClearCase的功能”中所述，动态视图很棒（一种通过网络查看数据而不必将其复制到磁盘的方法），但是主要功能仍然是UCM：如果您拥有，则可以成为真正的资产。具有复杂工作流程的大型项目。

在这方面的一些缺点：

• 不能很好地管理组件之间的依赖关系（因为“寄生虫基线”的错误）
• UCM仍然有一些coherencies和不一致性中记录CM十字路口

Base ClearCase的受限策略

不使用UCM而使用ClearCase意味着必须定义以下策略：

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

没有申请权

ClearCase权限管理完全基于系统权限。
这意味着您需要将用户注册到正确的系统组，这在您必须输入IT服务票证以便他们进行正确注册时并不总是那么容易。
再加上异构环境（Windows上的用户和Unix上的服务器），您需要在Unix和Windows上注册用户！（具有相同的登录名/组名）。除非您在两个世界之间放置某种LDAP对应关系（例如Centrify）

没有高级API

• 仅CLI是完整的（“ cleartool”是ClearCase命令行界面），表示任何脚本（使用Perl或其他语言）都由解析这些cleartool命令的输出组成
• ClearCase自动化库（CAL） 存在，但是非常有限
• Java API存在，但仅用于CCRC客户端的Web视图。

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

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

不好的是，视图中的每个操作（简单的“ ls”，检出，检查等）都会触发网络请求，该请求请求管理视图服务器的view_server进程。
2种选择：

• 在工作站上声明您的视图存储：非常适合可扩展性，您可以在不增加LAN负担的情况下拥有任意数量的视图：所有通信都直接在工作站上完成。但是如果那台机器死在你身上，那你就失去了看法。
• 在集中式服务器上声明您的视图存储：这意味着将在此处创建所有view_server进程，并且任何用户对视图的所有操作都必须与该服务器进行通信。如果基础结构是“正确的”（专用高速LAN，专用服务器，持续监视），则可以完成此操作，但是实际上，您的LAN将不支持此模式。

第一种模式意味着：您必须备份自己进行中的工作（私有文件或已检出文件）
，第二种模式意味着：您的工作站可能不可用，您可以仅登录另一个以获取视图（对于私有文件执行）快照视图的文件）

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

要添加到“动态视图”方面，它具有一个优点（动态）和一个缺点（动态）。
动态视图非常适合设置一个简单的环境，以便在一个小型团队之间快速共享一个小型开发：动态视图可以帮助2或3个开发人员持续保持联系，并在提交中断时立即查看其他观点中的某些东西。
对于更复杂的开发工作，快照视图提供的人为“隔离”是可取的（您只有在刷新或“更新”快照视图时才能看到更改）
对于真正不同的开发工作或过程，仍然需要一个分支来实现真正的代码隔离（有时需要合并，ClearCase处理得很好，尽管很慢，但逐个文件）

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

注意：小团队并不是指“小项目”。ClearCase最适合用于大型项目，但如果要使用动态视图，则需要设置“任务分支”以隔离每个分支的少量开发工作：这样，“小型团队”（大型团队的子集） ）可以高效地工作，并在其成员之间快速共享其工作。
如果您在每个人都在做什么的“主”分支上使用动态视图，则任何签入都会“杀死您”，因为它可能会引入一些无关的“构建中断”用您当前的开发工作，
那将是动态视图的不良用法，并且会忘记其其他用法：

• 除了快照视图之外，还有其他访问数据的方式，这意味着它是仅“查看”文件的好工具（例如，您可以使用动态视图来调整其配置规范，直到看到所需的内容，然后将其复制常规快照视图中的规则）
• 进行合并的侧视图：您可以使用快照视图，但是对于合并，可以使用动态的“ sister-view”（“ sister”，与“ same config spec”相同），以避免由于以下原因导致合并失败检出的文件（您当前将在其中使用快照视图），或者由于快照视图不是最新的。合并完成后，您将更新常规快照视图并继续工作。

在动态视图中直接进行开发并不总是最好的选择，因为所有（未检出）文件都是通过网络读取的。
这意味着可以通过网络访问IDE所需的dll，jar或exe，这会大大降低编译速度。
可能的解决方案：

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

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

它非常复杂，需要专职保姆，这一事实也令人担忧。

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

• 它是slooooow。
• 如果使用动态视图，并且网络断开，则无法访问源的工作副本。您只能坐下来等待其修复，而您什么也不能做。
• 如果使用快照视图，似乎总是会遇到冲突并“劫持”文件，因此，工作副本中的文件永远不会与源存储库中的文件完全相同。
• 每当您尝试进行较大的更新或交付操作时，由于某种原因或其他原因，它总是会 失败，这需要您的ClearCase专家花费数小时/天来弄清楚。哦，是的，您必须有一个专门的全职ClearCase专家！
• 当它失败时，您通常也无法回滚该操作，因此您将无法进行正在进行的操作，并且开发人员被阻止了。
• 当您翻过漂亮的（？）图标时，GUI非常差-诸如无法调整窗口大小以查看完整文件路径之类的东西！
• 他们的支持人员非常不愿意解决任何问题。他们的第一反应始终是“这是设计使然”，“您能解决这个问题吗？” 如果他们最终提供了解决方案（经过大量争论），它将是针对最紧迫问题的最基本的解决方案。

基本上，它像地狱一样缓慢，复杂且不可靠。哦，我有提到它贵得离谱吗？他们可能出售该产品的唯一方法是与从未使用过该产品且从未使用过的决策者进行交谈！我很确定世界上没有开发商会购买它。

原子提交和变更集是我对ClearCase的最大抱怨。假设您作为错误修复或重构的一部分签入了五个文件。然后发现有些东西弄乱了，您需要还原。祝您好运，找到它们是五个文件以及每个文件需要使用的版本。但是，让我们退后一步。您刚刚完成了对这五个文件的编辑，现在该提交了。前四个通过都很好。最后一个需要大规模合并。其他四个文件已经签入。它们不会等待您在上一个文件中完成必要的更改。我希望没有人更新或使用动态视图。持续集成构建服务器也将失败。

有时，我们会在一个全新的目录中放入所有需要检入的文件，但是直到完成后，我们才希望将其检入。现在还很早，一切仍然不稳定，所以为什么要检查一下内容以便很快删除？好的，到目前为止。现在是时候签入了。您将新创建的文件夹添加到源代码管理中。好吧，ClearCase不是递归的，因此只能签入单个文件夹。使用SVN，可以选择该文件夹及其下的所有内容。开发人员需要记住添加所有内容，否则，将丢失许多文件。

ClearCase拥有文件和文件夹，因此除非您先将其签出，否则您无法修改任何内容。eclipse插件在这里消除了很多麻烦。我无法告诉您我在vi中打开文件进行几次更改的次数，只是发现自己忘记先将其签出。结帐也不是递归的。

没有变更集，更新可能会非常缓慢。使用快照视图更新时，每个文件都会更新，而不仅仅是已修改的文件。我从事的项目超过20,000个。我将远程进入我的工作机，开始更新，然后开车去上班；喝咖啡 正在整理时去我的办公桌。听起来可能有点夸张，但事实并非如此。

除非您的团队很小，否则动态视图非常糟糕。如果是这样，为什么还要使用ClearCase？我看到无数人的观点被削弱，因为有人签入了破坏其他所有人观点的文件。您应该始终根据自己的观点更新和合并所有冲突。这样，更改只会影响您。使用动态视图时，您不能在向下推之前合并下来；你只是承诺和希望。

我知道成本可能不是大问题，但是为公司赚钱的开发人员将喜欢在有趣的活动或新设备上花费$ 50k- $ 100k（取决于ClearQuest许可，这是常见的补充）（椅子，监视器等）。IBM建议配备人员以保持ClearCase的正常运行。为什么不重新安排这些人的目的来为公司创造收入，而不是确保事情不会崩溃和燃烧呢？

我听说过不切换的一些原因：

• 学习需要时间和金钱
  • 学习SVN或Mercurial应该不超过一天。只有ClearCase建议管理员与开发人员的比例一定。
• 迁移将是痛苦的
  • 这就是存在工具的原因：cc2svn
  • 使用Mercurial并不容易
• 安全
  • SVN AFAIK中没有已知的漏洞，开发团队致力于解决所有快速发现的问题。国防部对SVN似乎还行。
• 之后实际生产力没有增加
  • 它永远需要尝试跟踪没有变更集的错误。我喜欢能够回滚，直到看不到错误为止。您不能在ClearCase中做到这一点。
• 多站点
  • WANdisco解决了这个问题。它不是免费的。

ClearCase唯一优于其他文件的是分支单个文件，同时使其他文件与另一个分支保持相同的轨道。

我在Clearcase中所做的一切似乎总是 很难。而我从未在其他系统上留下过印象（有时可能是CVS除外）。

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

我在ClearCase上的经历是一场灾难，我将在Don的第二句话中说，这需要一位常驻专家-不幸的是，我们有不止一位。我曾经使用过CVS和其他版本控制系统，对这些概念很熟悉，但是我发现ClearCase文档令人费解，不得不多次寻求帮助。不同的专家给我提出了相互矛盾的建议，以至于我们实际上打破了CD。也就是说，在UNIX shell中发出ClearCase命令后，“ cd”命令失败，并显示一条错误消息。

版本控制系统的基本任务非常简单。坦率地说，我认为使用与他人配合使用的文件方案，只要打六个命令就足够了。在我看来，ClearCase似乎是营销主管故意使事情复杂化的结果，以使该产品看起来精致而强大。我听说它可以配置为以简单，安全，可靠的方式运行，但是再次需要专家的服务-开箱即用，就像电动瑞士军刀。

我所经历的一切与ClearCase的能力有关的一切都是效率低下，丑陋，过于复杂，缓慢，令人困惑，昂贵且不便。

似乎吸引了管理人员和工程师的只是一切都错了。

该死的，IBM和Rational必须有惊人的销售人员来销售如此糟糕的产品。

由于此处给出的许多原因，我们只是从CC迁移到Git。我想补充一个理由，避免使用CC或任何其他商业源代码控制系统。

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

您的重要业务数据是代码，其版本历史以及所有元数据（例如，提交注释，谁签入以及何时签入）。

所有软件的使用寿命有限。当您引入一个吞噬重要业务数据的新系统时（无论是代码，错误，客户数据还是其他），您应该总是问自己：如何再次获取数据？如果您不能回答该问题，则不应引入该系统。

当我们迁移出去时，我们失去了大部分历史和所有元数据。本质上，我们只有对应于已发布版本的历史记录，但是有关丢失了哪些更改以响应客户的请求的信息（我们在客户支持和错误凭单系统中拥有该数据，因此并没有完全丢失这些数据，而是与源代码不见了）。

从短期到中期，这对于我们来说将是一件令人烦恼的问题。在几年的时间里，它不再重要了，但是也许在1-3年内就变得重要了。

（有一些商业工具可以将CC迁移到其他SCM，但是它们不能满足我们的需求，我怀疑这样做是否可行。我们所做的最小限度的出口花费了足够长的时间。）

得到的教训是：切勿将重要的业务数据委托给专有系统。

没有原子提交

签入文件后，由于不支持原子提交，很难恢复到特定状态。检入多个文件时，每个文件都会得到一个新的修订版（类似于CVS），而不是检入本身。我认为这是一项至关重要的功能，因为您几乎不希望还原单个文件，而是完成提交操作（应映射任务）。使用ClearCase，您只能通过使用Labels恢复到某些状态。在实践中，每次签入都使用ClearCase标签是过大的，因此无法完成。

笨拙的用户界面

ClearCase Explorer的GUI只是一个大笑话。易用性和难看的外观。没有提供不同且通常必要的功能（例如，递归检查工件上的工作）。与cygwin一起使用的命令行工具cleartool更好，但是仍然有些功能不可用，例如以递归方式将新文件/文件夹添加到源代码管理中。如果我读了50行代码长的脚本来解决此问题，我就不得不笑了。

高级管理工作

管理ClearCase野兽远非显而易见或轻巧（与其他SCM系统（例如CVS，Subversion或Git）不同）。期望有大量的专用ClearCase专家来保持运行。

糟糕的表现

没有什么比让您的开发人员在与SCM工具进行接口连接时等待更糟糕的了，就像在启用手刹的情况下驾驶一样。它减慢了您的大脑以及您的工作速度。10K工件需要大约30分钟才能获取到快照视图中的新文件。相同数量的更新（未更改构件）大约需要5分钟。在进行大量实验并在不同的最新视图之间切换时，意味着要等待很多时间。当您处理文件并想要签入或更新它们时，情况甚至更糟。检出，检入和添加到源代码控制周期大约需要10-15秒，这显然是一场噩梦。当您重构重命名/移动类型或方法时，它会变得很烦人（许多文件可能会受到影响）。

缺乏对分布式开发的支持

如今，软件开发通常是分布式的（开发人员遍布全球，从事同一产品/项目）。ClearCase绝对不适合此操作，因为它非常不适用于离线工作。进行检出（在可以编辑文件/文件夹之前进行的操作）要求您已网络连接。在这里，您可以使用hijack选项，但这是一项变通办法，它是一项功能（您基本上只是在文件系统上解锁文件）。如果您的开发站点离ClearCase服务器很远，那么签入/签出延迟可能会大大增加，以致根本无法使用。有一些解决方法，例如使用ClearCase Multisite（scm DB复制技术），但是您必须为此支付额外费用，并且管理起来并不容易。

git替代

尽管是开放源代码的狂热拥护者和支持者，但我仍然愿意为优质软件付费。但是，看看IBM怪兽ClearCase，我不会在这里投入我的钱，它具有所有这些已讨论的缺点，此外，IBM似乎也没有投资来显着改善其产品。最近，我看了一看Git scm，它看起来非常好，特别是因为它的分支+合并功能，其中ClearCase具有主要优势。

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

可能是有史以来最糟糕的软件。我不会为任何使用理性事物的公司工作。除了CC完全崩溃，而且在动态构建中经常重启我的工作站。当您将某些内容推到源代码控制中并且CC发挥其最大作用而崩溃时，会发生什么情况？然后将您的代码放入lost + found中，然后备份到某个地方吗？不，它永远消失了。因此，如果您处在使用该巨型昂贵软件的可怕境地中，请保留所有内容的副本。做好Rational / IBM。捕获源代码控制最重要部分的方式是可靠性。慢一点

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

1. 合并工具不值得。它几乎对您没有帮助，记住您所做的任何决定，只是一个荣耀的区别。

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

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

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

5. 如果某人的视图规格与团队不同，则可以完全搞乱存储库或签到。真是太疯狂了，没人能只签出一些分支。他们需要适当的视图规范，这些规范会附带给他们合适的东西。整个概念可以很好且灵活，但是在99％的时间中，它只会引起很多痛苦。我是否提到过，由于CC工具不接受UTF-8，所以您无法通过Microsoft Outlook通过电子邮件发送您的规范，因此您不能将其复制粘贴？

6. 关于CC，我绝对无话可说。我在2家公司使用了2年，然后心跳下来，一直感到很高兴。仅在家中尝试自己的项目也是不可能的，因此您仍将在家中学习SVN或Git，并被迫在工作中经历ClearCase的痛苦。我认识的人都没有自愿使用CC。他们之所以使用它，是因为某个工作中的经理认为CC是拯救之路，并迫使所有人都迁移到它。实际上，我的上一家公司是从CVS迁移到ClearCase的，然后是从ClearCase迁移到SVN的一年。就是那个讨厌。

7. ClearCase不仅仅是让您拒绝的一件事。这就像住在充满蚂蚁的房子里。每只蚂蚁充其量只是给他们带来的不便，但这种侵扰会使您发疯。

我正在尝试将一些评论整合到此处的实际帖子中。我不是真的要在这里说服您，一个要比另一个好，除了要提出几点：

• 如果您要比较git和ClearCase，我谨此提出，您需要更好地定义自己的需求-如果您出于“良好”的理由考虑使用ClearCase，则git可能甚至不在等式中-它太新了，无法信任用于企业级源代码管理，imo。
• ClearCase在其他系统没有的版本控制空间中引入了很多概念，因此可能会令人生畏和困惑。特别是如果您仅有的经验是阅读文档，那么这里的一些人就是如此。
• ClearCase绝对不是非常适合那些不在VOB服务器所在LAN上的开发人员所支持的庞大代码库。您可以具有许多复制的（多站点）VOB服务器，以使它们与远程开发人员保持联系，但是，如果这些远程站点只是一个开发人员，则不一定实用。
• 您要文件版本控制还是存储库版本控制？这是一个非常重要的问题，必将过滤掉整套工具，使您的工作更加轻松。存储库版本控制具有很多优点（而且，正如某些海报所宣称的那样，它不是“新的”-诸如Perforce之类的商业工具已经存在了十几年，甚至在Perforce之前就有可能进行存储库版本化的工具），但是这不是万能药。
• 安装足够多的任何源代码管理系统后，您将需要帮助。在考虑工具时，您需要考虑找到帮助您的人有多容易（有经验的求职者，或随时通知您以解决任何问题的顾问）。没有免维护的SCM系统，要想拥有一个系统，比选择一个需要“太多”管理的系统会给您带来更多的麻烦。
• 不要过多地谈论那些谈论“动态视图”有多糟糕的人-糟糕的SCM策略是糟糕的，无论您使用什么工具。您的配置管理策略和实践必须与工具选择区分开-如果您没有定义明智的分支和合并策略，则没有任何一种工具可以阻止人们破坏整个代码库。如果有人建议让开发人员直接提交到/ main是一个明智的主意，那么您可能想摆脱这种对话。

ClearCase是一个很好的工具，但是它很复杂工具。没有解决方法-它没有“轻松安装”模式。:-)从技术的角度来看，git或SVN不能做ClearCase不能做的（尽管术语经常不同，因为开放源代码项目往往只是发明已经存在的新分类法），但是某些事情肯定更容易/难于给定系统，具体取决于其设计。如果您从SVN或CVS中检出存储库，则ClearCase的“快照”视图基本上是相同的-它是计算机上源代码的本地副本，并带有指向中央服务器的指针，这些指针用于查询版本历史的工具，创建这些视图后，便无需使用任何与ClearCase服务器的网络连接，就可以使用这些视图，并且可以“回收” 例如，当您要移到另一个分支上工作时，它们可以避免再次下载整个存储库。“动态视图”基本上是ClearCase的发明，并且是LAN的标准操作模式。它们看起来与签出SVN信息库的方式相同，但是它们实际上不会复制任何文件，除非您进行更改。这样，视图立即可用，但是如果主Clearcase服务器不可用，并且显然不适合通过高延迟连接使用，则显然无法使用该视图。它们还具有能够作为网络驱动器安装在任何可以访问创建它们的服务器的机器上的便利，因此，如果Windows工作站死了，您可以登录到另一个计算机上，安装视图并获取回去工作，

此外，这也应有其自己的段落。它是我一生中使用过的最好的合并工具。我坚信，由于缺乏高质量的合并工具，在SCM中出现了许多不良做法，因此CVS用户从未学会正确使用分支，并且对分支的担忧已经蔓延到了今天，没有特别好的理由。

好的，所有这些，如果您正在寻找不使用ClearCase的原因，虽然我认为这是错误的处理方法，但并不难找到。确实，您应该提出使用ClearCase的充分理由，而不是不使用ClearCase的理由。假定ClearCase是用于该工作的太多工具或过于复杂的工具，那么您应该遇到任何SCM情况，然后查看您是否有某种情况鼓励使用它。拥有IBM或Rational徽标不是很好的理由.. :-)

除非您对以下所有语句都同意，否则我什至不会考虑ClearCase：

• 您现在或将来将有超过50个开发人员在同一个代码库上工作。
• 这些开发人员中的大多数都位于中心位置，或者具有到中心位置的高吞吐量，低延迟的连接。
• 您拥有一组SCM策略，并且可以确定如何使用ClearCase来实施这些策略（真的，对于任何工具，您都应该考虑这一点）
• 金钱真的不是问题

我的经验主要受CC，CVS和SVN的限制。原则上，CC具有技术能力，企业就绪性，并且在功能上可以与任何现代VCS相媲美。但是它有一些缺陷，使其在任何以人为本的环境中都无法使用。对于面向流程的环境，它可能更合适，尽管我怀疑这样的环境本身是否合适。也许不知道，在军事，宇宙或医学软件中。无论如何，我相信即使对于这些领域，也有适当且更友好的工具。

除了具有技术能力的VCS，CC还具有一些独特的优势：

• 动态检视
• 尼斯版本树
• 扳机
• 良好的合并版本控制，包括重命名

我认为，除了最后一个以外，它们的使用受到限制。而且它们无法弥补缺陷。动态视图理论上不错，但在实践中并不总是可用。在其他VCS中，版本树的使用要少得多，而在CC中则是必需的，因为分支的增加（请参见6）。据我所知，触发器非常详细且功能强大，但我认为对于大多数实际任务而言，SVN挂钩已经足够了。现在，有关主要涉及可用性的缺点：

• 对于主要用户组（对于开发人员），CC在可用性方面完全失败。这就是为什么我认为永远不要在任何环境中使用它的主要原因，无论它是否用于企业。即使它是免费的，它仍然会浪费您的开发人员并使他们沮丧，从而浪费您公司的钱。这点由以下内容组成：
  1. 使用严格的锁定方法进行“签入签入”-在具有多个开发人员的单个开发分支的存储库组织中，这适得其反，重构不友好且危险。同时，严格锁定的优点可忽略不计。
  2. 性能差和高负荷
  3. 如果没有多站点，则不能有效地远程使用（由于2）。多站点也很昂贵。ClearCase Remote客户端非常有限。它甚至没有cleartool（在7.1版之前），仅留下动态视图。
  4. 它几乎不能脱机使用。动态视图是行不通的。快照视图实际上是只读的，因为如果没有访问存储库就无法检出（请参见1）。劫持是一个糟糕的选择，实际上意味着CC放弃了对被劫持文件的任何责任。CC在脱机时无法显示与以前版本的差异。SVN甚至可以离线显示与以前的版本的不同。
  5. 过于复杂的模型，尤其是在UCM中：VOB，PVOB，项目，流，分支，视图，交付，更新，加载，还原，变基，合并，基线，签入，签出。我认为其中一半概念只是多余的，不会增加价值，同时会增加技术和概念上的复杂性。几乎没有开发人员了解CC的基本知识。
  6. 分支机构的扩散。例如，存储库通常按每个开发人员的流进行组织（由于1）。在SVN或大多数其他VCS中，它没有任何意义。
  7. 没有存储库范围的修订。好吧，有一些可以理解的修订，它们称为基准。但是，当我看到某些文件修订并希望在该文件修订时获取存储库快照时，我会遇到一些问题。我将需要对config spec进行配置以创建快照视图，或者通过动态视图以某种方式找到它（如果可用）。
  8. 笨拙的用户GUI。版本树即使很好，也具有中等的可用性。合并工具只是一个遗憾。其他“功能”：不可调整大小的窗口，某些位置缺少增量搜索，以鼠标为中心的界面，1995年风格的外观，在Client和Project Explorer之间分配的奇怪工作流程等。
  9. CC会引起稀有和大量的签入。众所周知，办理登机手续必须小而频繁。但是，开发人员通常会避免与CC，劫持文件进行额外的交互，并且可以在本地VCS甚至根本不使用VCS的情况下工作（不幸的是，这种情况更常见）。然后，经过两周的开发，他们开始提交复杂功能，该功能添加了20个文件并影响了另外20个文件。它持续一两天，因为它们劫持了文件，现在需要对回购中的所有新更改执行手动合并，并解决所有冲突和差异。在此过程中，代码无法编译，因为成功检入了多个文件，而其他文件则无法检入。之后，它仍然无法编译，因为他们忘了向CC添加另外2个文件。
• 这非常贵
• 在基础架构方面非常复杂，需要专门的管理员

从外部看，ClearCase似乎非常强大。但是实际上，仅仅是基本工作流程需要使用的命令和选项的数量如此之多，以至于它们被隐藏在一些别名或脚本的后面，并且最终导致了某些功能不如CVS，并且具有Visual Source的可用性。安全。每当您想做一些超出脚本允许的复杂性的操作时，您都会感到不适。

将它与Git进行比较，从外部看，它看起来很复杂，但是使用它一周后，您会感觉完全处于控制之中。存储库模型易于理解，并且功能强大。因为很容易获得基本要点，所以在日常工作流的表面之下进行挖掘实际上很有趣。

例如，弄清一个琐碎的任务，例如如何仅在快照视图中查看文件的非HEAD版本，这花了我几个小时，而最终我得到了一个完整的hack。也不是令人愉快的黑客行为。

但是在Git中，搞清楚看似复杂的任务，例如如何以交互方式仅提交一些更改（然后将其余更改留待以后使用）是一件很有趣的事情，而且我一直都觉得VCS允许我组织代码并历史记录以适合我的方式出现，而不是历史记录是我们如何使用VCS的偶然事件。“ Git意味着永远不必说'你应该拥有'”。

在我的工作中，即使在ClearCase中，我也将Git用于各种轻量级任务。例如，我做TDD，每当一堆测试通过并且要重构时，我都会致力于Git。当任务最终完成时，我签入了ClearCase，Git可以帮助我准确地查看正在更改的内容。只需尝试让ClearCase在两个文件之间产生差异即可-不能！使用Google找出人们试图解决此问题的各种方法。这是版本控制应立即提供的功能，应该很容易！CVS已经有几十年了！

• 在安全环境中进行管理的噩梦
• 技术过时
• 非直观的GUI
• 昂贵
• 资源怪兽
• 卖给微软

在我看来？有理由吗？如果您虔诚地遵循RUP。

支持太糟糕了。我们的门票已经开放多年了。实际上，我们的eclipse大师通过反汇编java文件，实际上在30分钟内就在本地修复了eclipse插件中的错误。但是门票仍然没有超过一级支持。他们常常尝试偷偷地将其关闭或将其ping回给我们以“尝试最新版本”（即使我们向他们发送了一个复制食谱，他们也可以自己尝试）。

请勿与驳船杆接触。

性能。

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/

• 开发人员在进行任何工作之前将花费1/2的时间来弄清楚clearcase，一旦他们弄清楚了，他们将在本地安装git并仅根据需要推送到clearcase repo。

• 您必须聘请专门的Clearcase管理员。

我建议将SVN用于工具集，将Git用于扩展/工作流。我还建议尽可能避免使用CC。（不算钱，使用起来是如此痛苦，需要全职管理员的事实完全是个笑话）

我最近不得不纠缠于类似的情况。也许你可以从我的故事中学到东西。

我刚被分配到的团队正在使用繁重的工具，而且容易出错。我首先尝试通过我选择的工具和流程出售它们。这项尝试惨遭失败。我很吃惊，他们会选择这样一个繁重的环境，而不是既轻松又有效。事实证明，他们希望受到纪律处分，并且使用痛苦的过程使他们感到受到纪律处分。听起来很奇怪，但这是事实。他们也有很多其他误解。在弄清楚它们的用途之后，我们实际上坚持使用相同的工具套件（Serena），但是对它的配置进行了巨大的更改。

我对您的建议是弄清楚对您的团队至关重要。除非您对他们的兴趣说话，否则在ClearCase上翻录将无济于事。此外，找出他们为什么不想使用替代品。基本上收集一些需求并根据您的需求选择工具。取决于您的选择，谁知道，毕竟，Clear Case可能最终是最佳选择。

我并不完全反对ClearCase（它确实具有它的优点），但是列出了缺点：

• 许可证限制-我无法在家中工作，因为我无权访问许可证服务器。即使在我的笔记本电脑上有快照视图，我也要耍花招，因为我没有许可证。有一个特殊的远程客户端，但是它增加了很多自身的限制
• 再次限制许可-只有那么多座位可坐，然后没人可以使用它。
• Unix工具已过时-ClearCase似乎在Unix系统上运行最好，但是GUI工具很烂。Windows / Unix的ClearCase集成引入了各种自身的难题。

对我来说，最大的故障是性能（尤其是在VOB是多站点或异地时）以及可能较长的停机时间。

如果您像我一样，作为一家大公司的一部分在一个相对较小的办公室中工作（没有现场IT），那么Clearcase服务器宕机可能会使您在工作日的大部分时间浪费在非生产性工作上，同时还会找到合适的人修复它。

最重要的是，仅当您确实需要它进行工作时才使用它，并确保拥有强大的IT预算来维护它。

如果您还愿意在它上面使用另一个版本控制系统，则ClearCase完全可以使用！我个人发现使用CC之上的汞可以很好地工作。

1. 没有原子检入

从7.1版的新版本开始，如果您愿意，CC会提供原子检入作为功能。就我个人而言，我真的不想要它，但显然有人认为这是“基本功能”。我从不希望一次大批量生产这种庞大的版本。再说一次...如果您要打开它。

所以...不再是争论。

在过去的4年中，我们与50多个开发人员一起使用了与ClearQuest（灾难恢复跟踪/变更请求系统）集成的UCM ClearCase。我们有50多个UCM项目，超过一千个流处理了超过35,000个DR和更改请求。在此期间，我们正式进行了600多次集成交付，同时进行了多达6个并发开发和发布工作。

我是负责备份的CM / ClearCase主要负责人，他能够执行常规的交付/合并和集成构建。网络和服务器由IT团队支持。我只能说，在这项巨大的开发工作中，CM方面几乎没有任何问题，而且从来都不是阻碍。每当项目管理部门提出要求创建新项目（分支）时，我们的开发人员都将接受基本知识和简单步骤的培训。

太多的开发人员抱怨ClearCase，因为他们缺少适当的CM / IT / ClearCase / Process / Management支持。开发人员应专注于开发而不是SCM或成为工具专家。对于大型软件开发，至少应将预算的5-7％用于CM和工具支持。

在Linux中从VOB运行JDK。

尝试一下，您需要使用LD_PRELOAD变量（我知道！）

“需要一个专门的人”和“它很复杂”等观点。

发现此问题的核心问题是，您必须定义是否要在组织中执行配置管理（不是版本管理）。配置管理就像项目管理：即使没有工具，您仍然可以进行项目管理，没有工具也可以进行配置管理。许多人很难理解这一点，并且许多人认为Configuration Management等同于对软件或某些源进行版本控制的工具……（因此与Subversion或其他VERSION管理系统进行比较）

ClearCase是一种为在Configuration Management环境ERGO中使用而构建的解决方案：有一个配置管理器（就像“有一个项目管理器”一样）。

所以...如果您认为有专人负责工具管理，我认为这是非常错误的事情。在我看来，有一个专门的人负责配置管理，从最终用户的角度来看，他只会在工具出现问题时才会出现，但仅将其视为工作的1％。

因此，您需要做的事情（就像在任何其他软件项目中一样）回到您的需求，然后将需求列表放到组织对配置管理的需求上。是的，就像在其他任何软件项目中一样，您将拥有完全不同意某些要求的其他用户（例如管理）的用户（例如开发人员）。我在这里阅读的一些反应中有关键的恕我直言。

恕我直言，如果您有需求的组织列表和配置管理器....选择非常明确（另请参见www.cmcrossroads.com上的论坛）

ClearCase不仅是最终用户在版本控制（如subversion或git）下输入其源代码的工具。这仅仅是配置管理器真正想要成熟的配置管理工具的原因的1％。

而且...我认为选择CM系统绝不应该等于选择正确的项目管理工具或CRM系统。开发人员是该工具功能某些部分的最终用户。

我也许一个人在这里，但是ClearCase并不像每个人所说的那样糟糕。它可以处理巨大的存储库。动态视图也是很酷且强大的功能。它是可靠的，可以通过在pef文件，权限等基础上添加触发器和约束来进行自定义。

不幸的是，它要付出很大的代价。这是昂贵的，并且需要由专门的IT团队正确配置和维护才能正常运行。这对于BigCo确实非常有用，但对于SmallFirm则不是明智的选择。

我是DVCS和git的忠实拥护者，但可以理解BigCo为什么会选择ClearCase而不是SVN和Git。我不明白为什么有人会选择SVN而不是Git;>

动态视图。必须欣赏功能齐全的半透明文件系统。

一大好处是，知识产权始终在公司网络中。笔记本电脑可能会丢失/被盗，没有危险的源代码。

另一个是即时访问源代码和更改的文件，无需花费时间下载任何内容。

它具有很好的用途。