svn - ClearCase 是否适合我们的开发流程？

Question

所以，让我描述一下我们目前的情况。我们是一个由经验丰富的 Java 开发人员组成的小型团队 (6)，迷失在一个主要由 SAP 和 Siebel 配置器组成的大型 IS 团队中。
虽然所有其他团队目前都在使用 VSS，主要是作为一个 vaulting 系统，但我们的团队已经切换到 Subversion（在评估 DVCS 之后），因为它最适合我们的敏捷方法。

现在，每个人都被要求迁移到 ClearCase，所有迁移工作都放在了 VSS 用户身上，因为他们是用户中最大的一部分。
由于我们独自一人，并不真正了解 ClearCase，因此我们担心它不适合我们当前的工作流程。

以下是我们目前每天的工作方式：

• SVN 存储库遵循 /trunk、/branches、/tags 结构。
• 每个开发人员在存储库中都有自己的沙箱，用于测试和原型设计。
• 我们密集地使用分支进行新功能开发，并习惯于将它们合并在一起进行一些集成测试，然后再将它们提升回主干。
• 在 Java 中工作，我们习惯于进行重构，而 Eclipse 对此提供了很大的帮助。每天都会进行很多类和包的重命名。
• 根据项目的发展方式，某些部分可能会被重用，从而导致一个项目在几个项目中的拆分，原来的仍然通过 svn:external 属性集成。
• 我们对某些元素使用关键字替换，因为这是一种非常简单的方法，可以让测试人员知道他正在测试什么版本。
• 我们的 Subversion 存储库链接到 Hudson，用于运行测试套件并通过标记它们来提升有效构建。

目前我对 ClearCase 的了解是，我们必须通过 CCRC（或通过它的 eclipse 插件版本）使用它，并且我们非常鼓励我们将大部分项目链接到 ClearQuest 项目以进行问题跟踪管理.

您能否告诉我们 ClearCase 将如何替代我们的 Subversion，哪些概念具有完全匹配（我不关心同义词，而是真正关心概念），以及您在整个过程中可以预见到什么样的变化。

谢谢。

Answer 1

首先，您可以阅读以下有关 ClearCase 的几篇文章：

• 每个开发人员都应该知道的基本 clearcase 概念是什么？
• 如何利用 Clearcase 的功能
• ClearCase 的优点/缺点

现在：

• CCRC 的意思是“网络视图”，即 ClearCase 专用网络服务器上的快照视图……您最好在桌面和该服务器之间建立一个良好的 LAN。

• 分支是 ClearCase 中的一等公民，这意味着一个给定的 ClearCase 视图（这里是 ccweb 快照）只会让您访问一个分支。如果您习惯于同时处理多个分支，则需要多个视图。

• 所有操作都是一个文件一个文件，因此在私有分支上工作然后合并的想法很麻烦，因为涉及的合并数量。
  我强烈建议为几个开发人员想要解决的给定开发工作在一个公共分支上工作。
  如果他们想要私有分支和沙箱，他们可以毫无问题地在 ClearCase 视图中设置 Git 视图。
  （注意：快照视图不能被视为沙箱：当您签入文件时，每个其他开发人员都会在他们更新快照视图时看到您的更改）

• ClearCase Eclipse 插件确实支持重构。

• ClearCase 并不真正支持 svn:external 的概念，除非通过链接。或者通过 UCM 基线依赖项。
  应该知道，使用二进制依赖项比使用源依赖项更容易：如果您的外部是用于包含下一个项目的数千个源文件，那么在 ClearCase 中会很麻烦（由于长时间更新）。如果您包含一些 jar 或 dll，那会快得多（加上那些是实际部署的）。

• 如果您正在使用 UCM，则无法将代码从一个组件移动到另一个组件。您将不得不clearfsimport在新标识的“通用”组件中使用主要标签。

• 注意：RCS 关键字替换通常被认为是......邪恶；）我会推荐一个单独的文本文件，其中包含相关重要文件的版本或标签。这适用于交付材料，而不适用于源文件。

Answer 2

在我看来，CC 对于敏捷团队来说是一个糟糕的选择。原则上，您可以使用它，但您将不可避免地在某种程度上失去生产力。该程度的多少取决于您的 CC 管理员的优秀和同情心。他们必须清楚地了解开发团队的需求。

在我们的团队中，我们与 CC 相处得很糟糕。我们的管理员是远程的并且与团队的其他成员隔离，因此我们被迫通过邮件和请求跟踪器与他们沟通。你可以想象需要多少时间。由于此过程的费用和复杂性（以及一些管理负担，我猜），我们无法升级到最新的 CC 版本。因此，我们使用 7.0 版本的 CC/CCRC。

这个版本的 CCRC 完全烂透了。你不能轻易地用它重构。您不能对其执行任意合并。您无法创建基线。您甚至不能将文件放入忽略列表。顺便说一句，据我所知，CC 仅在后来的 CCRC 版本中支持被忽略的文件，而不在本机 CC 客户端中支持。我们的 CCRC 版本根本没有命令行界面。

CC 高度依赖于服务器通信，因此当开发人员尝试离线工作时，CC（和 CCRC）会自行离开。CC repo 在没有 CCRC 或远程桌面的情况下无法远程使用（鼠标单击响应时间为分钟级）。

CC 会干扰其他工具，因为它会将所有文件标记为只读，并要求在修改之前明确检出它们。因此，有了 Eclipse 插件，您就可以进行重构。但是对于任何其他工具，您都不走运。您需要先签出文件或强制修改它们，从而将它们变成劫持。让您使用另一个 IDE、sed 或 awk 脚本或类似的东西，您会遇到问题。即使您只使用 Eclipse，涉及 CC 的操作（这意味着所有重命名重构等）也很慢，因为 CC 很慢。

CC 唯一的好处是它擅长合并和合并跟踪。但是 Subversion 1.5 已经相当接近这一点了。无论如何，它并没有让我使用 CC。

我承认我尖锐的负面意见主要是由我个人的不良经历形成的。但我确信，即使在具有完美流程和管理的理想 CC 设置中，您的工作效率也会受到影响。这是因为CC对服务器的过度依赖和“签出签入”的严格锁定方法。它为此提供了一些“解决方法”（我宁愿称它们为 kludges），例如无保留的签出和劫持状态，但它们增加了自己的问题。CC 始终站在你和你的代码之间。

顺便说一句，我猜 IBM Rational 迟早会将他们的客户转移到Jazz 平台上。它的 Rational Team Concert 是具有“敏捷风味”的东西。它有 10 位开发人员的免费版本，并与 CC 进行了一些集成（但不确定它是否也是免费的）。所以你可以试一试。不过，我不相信 IBM Rational 有什么好的东西。

Answer 3

这是 ClearCase 的问题：

ClearCase 是在 1990 年代创建的，当时您的桌面系统上的工作站可能甚至没有磁盘驱动器——更不用说空间了。另外，您的桌面系统可能内存有限且速度较慢。

ClearCase 是一个很好的答案。视图可以存在于视图服务器上。VOB 存在于 Vob 服务器上。快速、快速、快速的专用机器。

ClearCase 派生的对象可以被眨眼，而不是让你的慢机器尝试编译代码。那是多么节省时间啊！

而且，ClearCase 的 VOB 结构意味着您可以做很少有版本控制系统可以做的事情。例如，如果您附加了名称，则可以将cd其放入文件中。@@这使您可以查看该文件的所有分支、标签和所有版本。您可以简单地运行您的标准 Unix 工具来搜索差异等。

然后，世界变了：

• 桌面系统变得更加强大。您拥有磁盘空间、内存和原始处理能力。在您的本地驱动器上创建一个结帐工作区（您当然有一个）意味着您不必依赖随着越来越多的网络进程出现而变得越来越慢的网络。在派生对象中眨眼？哎呀，我的机器可以比 ClearCase 定位适当的派生对象快五倍。

• 视窗。ClearCase 的设计考虑了 Unix。Hooks 可以在本地系统上运行，因为每个人的桌面上都安装了 Perl，并且您可以轻松地确保它们都处于相同的版本。哎呀，你可以有一个 NFS 挂载的 /usr/local 目录（我知道，但网络local目录很常见）和正确版本的 Perl 或安装的任何东西，你的钩子就可以工作了。Windows 玩得不是很好。钩子成了一个令人头疼的问题。

• 再次是 Windows：ClearCase 依赖 Unix 工具才能正常工作。Windows 没有它们。

• 敏捷开发：在开发 ClearCase 时，开发模型是一种将开发人员相互隔离的模型。如果您不必经常担心其他开发人员对您的系统进行更改，您可以更快地工作。在 ClearCase 中，分支很容易。你可以给每个人他们自己的分支，然后他们可以在完成后合并回主分支。前后合并！在 ClearCase 中很容易。哎呀，UCM 是建立在这个基础之上的。不幸的是，该战略要求严格遵守纪律。您必须不断提醒开发人员合并他们的代码，以便其他开发人员可以看到它们。由于数十名开发人员都试图将他们的更改合并回集成分支，因此在发布之前不可避免地发生了合并紧缩。敏捷开发消除了开发人员隔离的概念。你做一些小的改变，并跟踪其他人在做什么。因此，不再使用“奥普拉分支”（你得到一个分支！你得到一个分支！每个人都有一个分支！）的概念。

• 因此，现在您拥有一个具有大量磁盘空间和内存的快速系统。您可以一次进行三个或四个单独的结帐。动态视图的优势根本没有克服它的狗慢和网络密集的缺点。快照视图有所帮助，但它们消除了曾经拥有的所有 ClearCase 魔法。换句话说，既然您一开始就可以简单地使用 CVS，为什么还要像 CVS 一样使用像 ClearCase 一样大而笨重的系统呢？

• 最后，ClearCase 很难。回到过去，当开发人员都是系统和网络专家时，学习 ClearCase 的来龙去脉是可以预料的。制作视图并不比学习 YACC 语法难。然而，开发人员不像以前那样精通系统。为什么应该这样？您无需了解内存的工作原理即可使用 Java 或 C# 进行编程。开发人员不再想学习大约 100 种不同的工具来完成他们的工作。ClearCase 培训可能需要几天时间，而学习 ClearCase 的来龙去脉可能需要几周时间。在 ClearCase 中，我必须了解视图语法才能执行简单的操作，例如修改分支上的代码。使用 CVS，它只是一个命令。

ClearCase 实在是太复杂、太慢而且太贵了。而且，这在很大程度上是 Atria 在构建 ClearCase 时所下的赌注：1)。开发人员会愿意学习它，因为无论如何他们都必须学习 100 种其他工具。2）。与网络服务器相比，您的台式机既慢又小。“在云中”做所有事情都更快。3）。ClearCase 集中化能力对公司来说是一个很大的优势，因为一个站点可以管理和支持一切。

所有这三个假设都被证明是错误的，因此，越来越少的公司甚至考虑使用 ClearCase。也许回到 Rational 收购 PureAtria 的时候，如果 Rational 把它带入 21 世纪，让它变得更小、更轻、更便宜，它可能仍然是一个广泛使用的工具。但是，Rational 忙于让开发变得更加复杂，以便将他们购买的所有漂亮工具集成到集中式开发过程中。到 IBM 收购 Rational 时，ClearCase 开始吸引用户。

Answer 4

小发明，

我目前正在经历与您相同的问题，除了从另一个角度来看 - 我是一名 ClearCase 管理员，试图将团队从 SVN 迁移到 ClearCase。

CCRC 被吹捧为用于开发 Java 的工具。我不完全确定我是否相信 - CCRC（ClearCase 远程客户端）旨在帮助开发人员从主要基础设施远程工作。代码被保存到桌面以帮助提高访问速度 - 但签入和签出的开销不容忽视。

从技术上讲，CCRC 可以进行重构，但如果与基础设施断开连接，则无法进行重构 - 该工具不会让您这样做。

Eclipse Workspaces 与 CCRC 视图完美匹配还有其他问题 - 您可能（取决于您的环境的分支结构）对工具的绝对路径名有问题。

需要记住的一点——也许还需要研究一下——ClearCase 确实可以做普通的快照视图。我不同意 VonC（也许是有史以来第一次，他是一个 helluva 管理员），因为我认为 CCRC 视图（称为 web 视图）与本机快照视图有很大不同，后者允许您在更像这样的环境中开发SVN - 特别是如果您正在寻找进行 Java 开发。

至于 ClearCase 和 Hudson，我已经与 Andrew Bayer 谈过，让 ClearCase 插件在 Dynamic Views 上工作得更容易一些——这在 0.9 版本中开始发挥作用。他是 Hudson 社区的活跃成员，因此如果您对插件有疑问，提出的问题应该很快得到解决。

我能给出的最大建议是，仅仅因为它不同，并不意味着它更糟。请耐心等待，如果您阅读文档并花点时间，您会惊讶于 ClearCase 可以为您提供的控制级别。

祝你好运！

斯图尔特

Answer 5

Clearcase 是一个功能强大的软件配置管理工具，您在日常活动中列出的大部分内容都可以通过 Clearcase 实现。

Clearcase 具有类似于您提到的沙箱的视图概念。有了配置规范的一些基本知识（从存储库中选择元素版本的规则集），分支就更容易了，并且对在不同分支中完成的更改的合并有很好的支持。

我不确定它是否受支持的一项活动是关键字替换。即使 Clearcase 支持不支持关键字替换，您也可以创建一个预签入触发器来自动执行关键字替换。

但我不清楚您与 Clearcase 的所有交互是否仅通过 CCRC（Clearcase 远程客户端）进行。我没有使用过 CCRC，也不知道 CCRC 支持什么。

Answer 6

clearcase 是我所知道的最强大的版本控制系统。支持所有枚举任务。