68

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

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

4

31 回答 31

110

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

以文件为中心的操作

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

File-per-file 操作意味着：缓慢的递归操作（如递归检出或递归“添加到源代码控制”，甚至 by clearfsimport）。
一个快速的 LAN是强制性的，以减轻该协议的副作用。

集中式 VCS

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

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

昂贵的分布式 VCS 选项

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

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

旧且不友好的 GUI

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

UCM 不一致和连贯性

正如“如何利用 ClearCase 的特性”中提到的，动态视图很棒（一种通过网络查看数据而无需将它们复制到磁盘的方式），但主要特性仍然是UCM：如果你有它，它可以成为真正的资产具有复杂工作流程的大型项目。

这方面的一些缺点：

  • 组件之间的依赖关系在深度上没有得到很好的管理（因为“寄生虫基线”的错误）
  • 如CM Crossroads中所述，UCM 仍然存在一些连贯性和不一致之处

Base ClearCase 的有限政策

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

  • 创建分支（否则任何人都可以创建任何分支，最终你会得到一大堆，合并工作流程的噩梦）
  • 放置标签（否则您忘记标记某些文件，或者您在不应该放置标签的位置放置标签，或者您将标签从一个版本“移动”（喘气）到另一个版本：至少 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 进程，并且任何用户对视图的所有操作都必须与该服务器进行通信。如果基础设施“正确”（专用高速局域网、专用服务器、持续监控），可以做到这一点，但实际上，您的局域网将不支持这种模式。

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

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

添加到“动态视图”方面，它有一个优点（它是动态的）和一个缺点（它是动态的）。
动态视图非常适合设置简单的环境以在小团队之间快速共享小型开发：对于小型开发工作，动态视图可以帮助 2 或 3 个开发人员不断保持联系，当一个人的提交中断时立即看到其他观点中的一些东西。 对于更复杂的开发工作，快照视图提供的人工“隔离”更可取（只有在刷新或“更新”快照视图时才能看到更改）

对于真正不同的开发工作或课程，仍然需要一个分支来实现真正的代码隔离（在某些时候需要合并，ClearCase 处理得很好，尽管速度很慢，逐个文件）

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

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

  • 访问数据的其他方式，除了快照视图，这意味着它是一个很好的工具来“查看”文件（例如，您可以使用动态视图来调整其配置规范，直到您看到您想要的内容，然后复制这些选择规则到您通常的快照视图中）
  • 进行合并的侧视图：您使用快照视图，但对于合并，您可以使用动态“姐妹视图”（“姐妹”与“相同配置规范”中的“姐妹”），以避免由于以下原因导致合并失败签出文件（您当前正在处理快照视图），或者因为快照视图不是完全最新的。合并完成后，您将更新常规快照视图并继续工作。

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

  • 一个包含所有内容的快照视图
  • 包含 dll 或 jar 或 exe 的快照视图（文件不会每五分钟更改一次：每天更新一次），以及仅显示源的动态视图。
于 2009-07-02T14:39:21.920 回答
35

成本是一个相当明显的劣势。不仅仅是许可成本，还有 ClearCase 专家的工资成本。据我所知，几乎每家使用 ClearCase 的公司似乎都至少有一个人，其唯一目的是驯服这头不守规矩的野兽。

复杂到需要全职保姆的事实也令人担忧。

于 2009-07-02T14:13:57.807 回答
27

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

  • 太慢了_
  • 如果您使用动态视图并且网络出现故障，您将无法访问源的工作副本。你什么也做不了，只能坐等它修好。
  • 如果您使用快照视图，您似乎总是遇到冲突和“劫持”文件，因此您的工作副本中的文件永远不会与源存储库中的文件完全相同。
  • 每当您尝试进行大型更新或交付操作时，它总是由于某种原因而 失败，这需要您的 ClearCase 专家花费几个小时/几天的时间来解决这个问题。哦，是的，您必须有一位专职的、全职的 ClearCase 专家！
  • 当它失败时，您通常也无法回滚操作，因此您会陷入正在进行的操作并且开发人员被阻止。
  • 当您查看漂亮（？）图标时，GUI 很差- 甚至无法调整窗口大小以查看完整文件路径！
  • 他们的支持人员非常不愿意解决任何问题。他们的第一反应总是“这是设计使然”和“你能解决它吗？” 如果他们最终确实提供了解决方案（经过多次争论），这将是解决最直接问题的最基本的可能解决方案。

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

于 2009-07-17T05:00:28.483 回答
25

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

有时我们会创建一个完整的新目录，其中包含需要签​​入的文件，但在完成之前我们不想签入它们。现在还早，一切都还不稳定，那么为什么要检查那些你可能很快就会删除的东西呢？好的，到目前为止还不错。现在该签入了。您将新创建的文件夹添加到源代码管理。好吧，ClearCase 不是递归的，因此只签入了单个文件夹。使用 SVN，该文件夹及其下面的所有内容都会根据您的选择添加。开发人员需要记住添加所有内容，否则会丢失很多文件。

ClearCase 拥有这些文件和文件夹，因此除非您先签出，否则您无法修改任何内容。eclipse 插件在这里消除了很多麻烦。我无法告诉你有多少次我在 vi 中打开一个文件以进行快速更改，结果发现我忘记先检查它。结帐也不是递归的。

如果没有变更集，更新可能会非常缓慢。当您使用快照视图进行更新时，每个文件都会更新，而不仅仅是修改后的文件。我参与了一个包含 20,000 多个文件的项目。我会远程进入我的工作机器，开始更新，然后开车上班；喝咖啡；在它完成的时候去我的办公桌前。这听起来可能有些夸张，但遗憾的是并非如此。

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

我知道成本可能不是一个大问题，但是为公司赚钱的开发人员会喜欢在有趣的活动或新设备上花费 5 万到 10 万美元（取决于 ClearQuest 许可证，这是一个常见的附加功能）（椅子、显示器等）。IBM 建议让员工保持 ClearCase 的运行。为什么不重新利用这些人为公司创造收入，而不是确保事情不会崩溃和烧毁？

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

  • 学习需要时间和金钱
    • 学习 SVN 或 Mercurial 应该不会超过一天。只有 ClearCase 建议拥有一定比例的管理员和开发人员。
  • 迁移会很痛苦
  • 安全
    • SVN AFAIK 中没有已知的漏洞，开发团队致力于快速修复任何发现的问题。国防部似乎对 SVN 没问题。
  • 之后没有真正的生产力提升
    • 在没有变更集的情况下尝试追踪错误需要永远。我喜欢能够回滚，直到看不到错误为止。在 ClearCase 中你不能这样做。
  • 多站点
    • WANdisco 解决了这个问题。虽然它不是免费的。

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

于 2009-07-14T12:42:53.290 回答
20

我在 Clearcase 所做的一切似乎总是很难。然而，我从未对其他系统产生过这种印象（有时可能是 CVS 除外）。

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

于 2009-07-13T17:10:46.090 回答
15

我所经历的与 ClearCase 相关的一切都是低效、丑陋、过于复杂、缓慢、混乱、昂贵和不便。

它似乎吸引了完全错了的经理和工程师。

该死的，IBM 和 Rational 必须有出色的销售人员才能销售如此糟糕的产品。

于 2010-03-25T22:33:02.587 回答
15

我对 ClearCase 的体验是一场灾难，我将支持 Don 的声明，即它需要一位常驻专家——不幸的是，我们有不止一位专家。我有使用过 CVS 和其他版本控制系统的经验，对概念很熟悉，但我发现 ClearCase 文档难以理解，不得不多次寻求帮助；不同的专家给了我相互矛盾的建议，以至于我们实际上破坏了 cd。也就是说，在我在 UNIX shell 中发出 ClearCase 命令后，“cd”命令失败并显示错误消息。

版本控制系统的基本任务非常简单。老实说，我认为六个命令就足够了，使用与其他文件配合得很好的文件方案。对我来说，ClearCase 看起来像是一位营销主管故意将事情复杂化以使产品看起来复杂而强大的结果。我听说它可以配置为以一种简单、安全、可靠的方式运行，但这同样需要专家的服务——开箱即用，它就像一把机动瑞士军刀。

于 2009-07-02T19:21:27.033 回答
15

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

您的重要业务数据受制于 ClearCase。你不能把它弄出来。

您的重要业务数据是代码、其版本历史记录和所有元数据，例如提交评论、谁签入以及何时签入。

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

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

在中短期内，这对我们来说将介于麻烦和问题之间。几年后，它不再重要，但也许 1-3 年它会很重要。

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

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

于 2011-07-02T21:55:07.903 回答
14

没有原子提交

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

蹩脚的用户界面

ClearCase Explorer 的 GUI 只是个大笑话。可用性和丑陋的外观很糟糕。没有提供不同且通常必要的功能（例如，递归地签入已处理的工件）。与 cygwin 一起使用的命令行工具 cleartool 要好得多，但仍然有些东西不可用，比如递归地将新文件/文件夹添加到源代码控制中。如果我阅读了 50 行代码长脚本来解决这个问题，我不得不大笑。

高管理努力

管理 ClearCase 野兽远非显而易见或轻量级（与 CVS、subversion 或 Git 等其他 scm 系统不同）。预计会有不少专门的 ClearCase 专家来维持它的运行。

糟糕的表现

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

缺乏对分布式开发的支持

今天，软件开发通常是分布式的（开发人员分布在世界各地，致力于同一个产品/项目）。ClearCase 显然不适合这种情况，因为它非常不适合离线工作。进行签出（编辑文件/文件夹之前的操作）要求您已连接网络。在这里您可以使用劫持选项，但这只是一种解决方法（您基本上只是解锁文件系统上的文件）。如果您的开发站点远离您的 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/

于 2009-07-21T15:45:46.523 回答
13

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

于 2010-05-14T02:29:53.740 回答
12

ClearCase 的缺点——这里最深入的帖子的补充。

  1. 合并工具不值得。它几乎没有帮助你，不记得你做出的任何决定，它只是一个美化的差异。

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

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

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

  5. 如果他们的视图规范与团队不同，有人可能会完全搞砸存储库或签入。这太疯狂了，没有人可以只检查某个分支；他们需要适当的视图规范，这会顺便给他们正确的东西。整个概念可以很好且灵活，但 99% 的时间它只会引起很多痛苦。我有没有提到你不能通过 Microsoft Outlook 发送你的规范，因为 CC 工具不接受 UTF-8，所以你不能复制粘贴它？

  6. 关于CC，我绝对没有什么好说的。我在 2 家公司使用了 2 年，并且在整个过程中都感觉很开心。在家中尝试自己的项目也是不可能的，因此您仍将在家学习 SVN 或 Git，并被迫在工作中经历 ClearCase 的痛苦。我认识的人都没有自愿使用过 CC。他们之所以使用它，是因为一些工作中的经理认为 CC 是通往救赎的道路，并迫使每个人都迁移到它。事实上，我上一家公司从 CVS 迁移到 ClearCase，一年后从 ClearCase 迁移到 SVN。就是那么讨厌。

  7. ClearCase 不仅仅是让您拒绝的一件事。这就像住在一个蚂蚁出没的房子里。每只蚂蚁充其量只是轻微的不便，但出没会让你发疯。

于 2009-07-20T17:46:56.177 回答
11

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

  • 如果您正在比较 git 和 ClearCase，我恭敬地提出您需要更好地定义您的需求 - 如果您出于“好的”原因考虑使用 ClearCase，那么 git 可能甚至不在等式中 - 它太新了，无法信任用于企业级源代码控制，imo。
  • ClearCase 将许多其他系统没有的概念引入到版本控制空间中，因此它可能非常令人生畏和混乱。特别是如果您唯一的经验是阅读文档，这里的一些人似乎就是这种情况。
  • ClearCase 绝对不适合那些不在具有 VOB 服务器的 LAN 上的开发人员所支持的庞大代码库。您可以拥有许多复制的（多站点）VOB 服务器以使它们靠近远程开发人员，但如果这些远程站点只是一个开发人员，这并不一定实用。
  • 您想要文件版本控制还是存储库版本控制？这是一个非常重要的问题，它必然会过滤掉一整套工具，让你的工作更轻松。存储库版本控制有很多优点（而且它不是“新”，就像一些海报声称的那样——像 Perforce 这样的商业工具已经存在了十多年，甚至可能在 Perforce 之前就已经存在进行存储库版本控制的工具），但是它不是灵丹妙药。
  • 如果安装了足够大的任何源代码控制系统，您将需要帮助。在考虑工具时，您需要考虑找到帮助您的人（无论是有经验的求职者，还是会立即通知您解决任何问题的顾问）是多么容易。没有免维护的 SCM 系统这样的东西，假设你有一个比选择一个需要“太多”管理的系统会给你带来更多的麻烦。
  • 不要过多关注那些谈论“动态视图”有多糟糕的人——糟糕的 SCM 策略是糟糕的，无论您使用什么工具。您的配置管理策略和实践必须与您选择的工具分开 - 如果您不定义合理的分支和合并策略，任何工具都不会阻止人们破坏您的代码库。如果有人建议让开发人员直接提交到 /main 是一个明智的想法，那么您可能希望退出该对话。

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

此外，这值得拥有自己的段落...... clearmerge 几乎值得单独入场的价格。这是我一生中使用过的最好的合并工具。我坚信，由于缺乏高质量的合并工具，SCM 中的许多不良实践已经形成，因此 CVS 用户从未学会正确使用分支，并且这种对分支的恐惧已经蔓延到今天，没有什么特别好的理由。

好吧，说了这么多，如果您正在寻找不使用 ClearCase 的理由，那么并不难找到，尽管我认为这是错误的做法。确实，您应该想出使用 ClearCase 的充分理由，而不是不使用 ClearCase 的理由。您应该假设 ClearCase 是太多工具或太复杂的工具来完成任何 SCM 情况，然后看看您是否有一些情况鼓励您无论如何都要使用它。拥有 IBM 或 Rational 徽标不是一个好理由.. :-)

我什至不会考虑 ClearCase，除非您可以对以下所有陈述说“是”：

  • 您现在或最终将有 50 多名开发人员在同一个代码库上工作。
  • 这些开发人员中的大多数都位于中心位置，或者具有与中心位置的高吞吐量低延迟连接。
  • 您有一组 SCM 策略，并且可以确定如何使用 ClearCase 来执行这些策略（实际上您应该为任何工具考虑这一点）
  • 钱真的不是问题
于 2009-07-16T19:31:17.753 回答
9

我的经验主要受到 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. 没有存储库范围的修订。嗯，有这样的修订，他们称之为基线。但是当我看到一些文件修订并想在该文件修订时获取存储库快照时，我会遇到一些问题。我将需要使用配置规范来创建快照视图，或者通过动态视图以某种方式找到它（如果可用）。
    8. 蹩脚的用户界面。版本树，即使很好，也有平庸的可用性。合并工具只是一个遗憾。其他“功能”：不可调整大小的窗口、某些地方没有增量搜索、以鼠标为中心的界面、1995 年风格的外观、客户端和项目资源管理器之间分布的奇怪工作流程等。
    9. CC 引发了罕见的大量签到。众所周知，签到必须小而频繁。但是开发人员通常会避免与 CC 进行额外的交互、劫持文件以及在本地 VCS 中工作，甚至根本不使用 VCS（不幸的是，这种情况更常见）。然后，经过两周的开发，他们开始提交复杂的功能，添加 20 个文件并影响另外 20 个文件。它会持续一两天，因为他们劫持了文件，现在需要手动合并来自 repo 的所有新更改并解决所有冲突和差异。在此过程中，代码无法编译，因为有几个文件成功签入，而其他文件则没有。之后它仍然无法编译，因为他们忘记向 CC 添加另外 2 个文件。
  • 这非常贵
  • 它在基础架构方面非常复杂，需要专门的管理员
于 2010-07-02T23:20:38.837 回答
8

从外部看，ClearCase 似乎非常强大。但实际上，只是您需要用于基本工作流程的命令和选项的数量如此之多，以至于它们被隐藏在一些别名或脚本后面，并且您最终得到的东西不如 CVS 强大，但具有 Visual Source 的可用性安全的。每当你想做一些比你的脚本允许的更复杂的事情时，你都会感到恶心。

将其与 Git 进行比较，从外部看它似乎很复杂，但在使用它一周后，您会感觉完全掌控。存储库模型易于理解，并且非常强大。因为很容易掌握具体细节，所以在日常工作流程的表面下进行挖掘实际上很有趣。

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

但是在 Git 中，搞清楚一个看似复杂的任务，比如如何交互地提交一些更改，（其余的留待以后处理）非常有趣，而且我一直觉得 VCS 允许我组织代码和历史以适合我的方式，而不是历史是我们如何使用 VCS 的意外。“Git 意味着永远不必说‘你应该拥有’”。

在我的工作中，我将 Git 用于各种轻量级任务，甚至在 ClearCase 中也是如此。例如，我做 TDD，每当一堆测试通过并且我即将重构时，我都会提交到 Git。当任务最终完成时，我签入 ClearCase，Git 帮助我准确地查看我正在更改的内容。只是尝试让 ClearCase 产生跨几个文件的差异 - 它不能！使用谷歌找出人们试图解决这个问题的各种黑客。这是版本控制应该开箱即用的事情，而且应该很容易！CVS 已经有几十年了！

于 2009-07-09T23:27:22.487 回答
7
  • 在安全环境中管理的噩梦
  • 过时的技术
  • 非直观的 GUI
  • 昂贵的
  • 资源怪物
  • 卖给微软

在我看来？拥有它的唯一理由？如果您虔诚地遵循 RUP。

于 2009-07-14T13:00:16.680 回答
6

支持是可怕的。我们的门票已经开放多年了。我们的 eclipse 大师实际上在大约 30 分钟内通过反汇编 java 文件在本地修复了他们的 eclipse 插件中的一个错误。但这张票仍然没有超过一级支持。每隔一段时间，他们要么尝试偷偷关闭它，要么将其 ping 回给我们“尝试最新版本”（即使我们向他们发送了他们可以自己尝试的复制配方。）。

请勿触摸驳船杆。

于 2009-07-20T19:22:46.153 回答
5

表现。

ClearCase 功能强大、稳定（如果得到适当的维护和监督），但速度很慢。地质有时。

动态视图视图会导致可怕的构建时间，快照视图可能需要很长时间才能更新（大型项目的午休时间）或结帐（当天回家）。

于 2009-07-03T19:45:38.053 回答
4

  • 开发人员将在做任何工作之前花费 1/2 的时间来弄清楚 clearcase，一旦他们弄清楚了，他们就会在本地安装 git，并且只根据需要推送到 clearcase 存储库。

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

于 2011-12-22T00:46:10.673 回答
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/

于 2009-07-17T05:42:29.553 回答
3

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.

于 2009-07-17T07:10:51.230 回答
3

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

于 2009-07-02T15:58:31.877 回答
2

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

  • 许可证限制 - 我无法轻松在家工作，因为我无权访问许可证服务器。即使在我的笔记本电脑上使用快照视图，我也不得不耍花招，因为我无法获得许可证。有一个特殊的远程客户端，但它增加了大量自身的限制
  • 许可证限制再次 - 只有这么多座位可以转，然后没有人可以使用它。
  • Unix 工具过时了——ClearCase 似乎在 Unix 系统上运行得最好，但是 GUI 工具在那里很糟糕。ClearCase 的 Windows/Unix 集成引入了它自己的各种痛苦。
于 2009-07-16T04:20:15.070 回答
1

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

于 2009-07-20T23:27:26.003 回答
1

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

我是主要的 CM/ClearCase 人，有一个能够执行常规交付/合并和集成构建的备份。网络和服务器由 IT 团队提供支持。我只能说，在这项巨大的开发工作中，我们从 CM 方面几乎没有遇到任何问题，而且从来都不是表演的终结者。每当应项目管理人员的要求创建新项目（分支）时，我们的开发人员只接受了基本内容和简单步骤的培训。

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

于 2011-04-05T19:47:44.557 回答
1

对我来说最大的缺点是性能（尤其是当您的 VOB 是多站点或异地时）和可能长时间的停机时间。

如果您像我一样，在一家相对较小的办公室作为大公司的一部分工作（没有现场 IT），Clearcase 服务器出现故障可能会使您在工作日的大部分时间都花在非工作效率上，同时也找不到合适的人把它修好。

最重要的是，仅当您确实需要它来完成您正在做的事情时才使用它，并确保您有足够的 IT 预算来维护它。

于 2009-07-13T23:50:16.003 回答
1
  1. 没有原子签入

从 7.1 版的新版本开始，如果您喜欢的话，CC 会提供原子签入功能。就我个人而言，我真的不想要它，但显然有些人认为这是“一个基本特征”。我永远不会想要一个大批量作为一种大规模版本。再说一次......如果你想要它，只需打开它。

所以……不再争论。

于 2010-07-09T15:05:08.423 回答
0

在 Linux 中从 VOB 运行 JDK。

试试看，你需要使用 LD_PRELOAD 变量（我知道！）

于 2009-07-15T10:31:52.320 回答
0

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

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

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

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

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

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

ClearCase 不仅是最终用户在 subversion 或 git 等版本控制下输入其源代码的工具。这只是配置管理器真正想要一个成熟的配置管理工具的 1%。

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

于 2010-07-15T17:10:04.900 回答
-1

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

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

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

它很好地满足了它的目的。

于 2009-10-07T01:13:15.407 回答
-1

我可能会一个人在这里，但 ClearCase 并没有大家说的那么糟糕。它可以处理巨大的存储库。动态视图也是非常酷且强大的功能。它是可靠的，可以通过基于 pef 文件、权限等添加触发器和约束来进行自定义。

不幸的是，它是有代价的，很大的代价。它成本高昂，并且需要由专门的 IT 团队正确配置和维护才能正常运行。这对 BigCo 来说非常好，但对 SmallFirm 来说并不是那么明智的选择。

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

于 2009-07-21T15:49:50.460 回答
-3

行政。我不得不安排多天的停机时间来执行从 6 到 7 的升级，并将半大规模 (159GB) VOBS 从旧服务器移动到 SAN 存储。使用像 git 或 svn+svk 这样的系统，这可以在一夜之间完成，几乎是自动的，对用户没有影响——他们永远不会注意到。他们无法将更改推送到上游，但他们可以继续工作。使用 ClearCase 或原始 SVN，它们受存储库服务器的支配。

ClearCase UCM 是一个很棒的工具，我喜欢它，并且认为可以做一些事情来向 SVN/mercurial/git/bzr 添加类似的功能 - 并不是说​​你不能用钩子脚本来实现它，但这是一个定制的一次性每个站点。UCM 如此流行，每个人都这样做，但几乎没有人在存储库中跟踪它。：-/

于 2009-07-14T15:53:43.557 回答