从ClearCase迁移到SVN / Mercurial

Question

在工作中，我们现在正在使用ClearCase。但是，需要大量的开销，特别是当有人做了一些愚蠢的事情时（例如擦除在主干上有多个保留检出的视图......）。由于我们试图降低我们的开销并尽可能轻量级，我们已经考虑了抛弃CC和寻找更轻的东西（Subversion或Mercurial）的可能性，看看我们如何不使用CC的90％的功能无论如何。这听起来合理还是我们将法拉利换成旅行车？

Answer 1

根据我的经验，ClearCase确实有很多开销，我们使用SVN进行了大量管理。

我投票，“降级”（实际上是升级版）。 ;）

Answer 2

我学到的主要内容是，比产品更重要的是流程。

如果你使用SVN类型的模型实现了ClearCase（CC），那么SVN就可以正常工作并且很多更便宜。

另一方面，如果您使用延迟分支，按标签构建和动态视图（或可以），我们在节省时间和精力以及提高可靠性方面具有很大优势，您将会非常后悔失去这些特征。 （更不用说构建管理，UCM等）

我发现大多数人都使用第一选择，就像在高峰时段使用法拉利......

实施例？ 定义标签GA，SP1，SP2（您可以根据需要在GA和SP1之间放置尽可能多的版本，不相关，并记住，CC标签与SVN不同）。 GA是你的基础版本， SP1是您当前的版本。 SP2是您的下一个版本。 当前版本基于GA和SP1。 下一个版本基于GA，SP1和SP2（参见CC配置规范）

开始QA。 开发正在为“下一个版本”进行持续的工作，用户可以参考（而不是更改）GA和SP1，并且可以应用SP2。 维护工作正在修复QA发现的缺陷，可以参考GA，并应用SP1。

案例1： 在ClearCase中，仅仅应用SP1标签的行为使得修复程序自动可供Dev SP2发布团队使用。没工作。 Nada，Zero。

在Subversion中，您将在QA分支上进行更改，然后（希望记住）将更改迁移到SP2。

案例2： 在您提出要求之前，当然，如果添加SP2更改，则必须进行分支以添加SP1的后续更改，就像在大多数系统中一样。

在我的世界中，现实世界的数字： 案例1发生了我最后一次SP的122次（每年8次SP）。 如果我使用Subversion模型，那么每年我不需要在ClearCase中进行800次以上的更改。

自2002年初安装CC以来，案例2已经发生了6次。

查看进程，而不仅仅是产品。

（对不起，它没有开始那么久： - ）

Answer 3

我同意之前的海报。放弃IBM产品并转向开源源代码控制产品将不会降级。使用这些更轻便，更易于使用的工具，您可能会更开心。在我们的商店，我们正在从CVS转向SVN，并对结果非常满意。

Answer 4

我绝对会考虑从clearcase转向颠覆升级！

Answer 5

我们从ClearCase LT转到SVN并喜欢它。我们节省了大量的维护费用现金，一切都和以前一样好。

我只是希望在推荐SVN之前我已经调查了Git或类似的东西。

Answer 6

转换您切换的建议。如果您不使用这些功能，那么使用商业价格的解决方案是一个糟糕的商业选择。

现在，“免费”解决方案也存在相关成本。 SVN和Mercurial都不会为您提供商业级支持。如果这是一个问题，并且肯定可以在某些情况下，你可能不想这样做。

在您提到的两个中，如果您当前正在使用集中式VC存储库，则应该选择SVN。 SVN的操作模型不仅简单直观，而且SVN只是我在开源项目中见过的最好的文档和开发人员社区。用户邮件列表非常精彩，开发人员对他们的用户做出了响应和负责，Red Bean book是开源手册中最好的一部分。

Answer 7

我的“开关”没问题。如果你没有很多使用UCM的相互依赖项目，那将是一次升级。

我管理SCM（ClearCase和Subversion）并建议Subversion用于中小型独立的项目。

但是，请确保您的开发人员不习惯ClearCase的动态视图：它是文件系统的封装，允许用户从网络访问文件。据我所知，ClearCase是唯一具有此类访问权限的人。

并考虑范式转换：

• ClearCase是以文件为中心的（您获得的每个文件都是只读的，只检查您工作的文件）
• Subversion是以存储库为中心的（你得到的每个文件都是读写的，你在一次原子提交中检查所有修改/添加/删除的文件）

Answer 8

我喜欢ClearCase的事情，我在其他SCM工具中无法做到或根本没有做过：

1. 与开发者分支机构合作是徒劳的。在CC（UCM）中，您在流（a.k.a。分支）中工作，并将“一堆”工作“交付”到集成流中。与此同时，其他开发商也这样做。然后，集成商（可能是其中一个开发人员）对集成流进行一些测试，并确保所有内容构建并可能抽取测试内容，然后推荐新的基线，其中包括所有开发人员的工作。同时，你继续在你的分支机构工作。下次要交付时（或者在您愿意之前），您会看到新的基线可用，因此您将合并到流中。事实上，如果有更新的基线可用，您将被迫改变。我尝试在Microsoft Team Foundation Server和SVN中执行此操作。首先，我找不到一种方法来强制实施类似CC强制转换的策略，所以我不得不去弄清楚自上次合并以来我做了哪些修改，以及从那以后在trunk中做了什么，以及然后从主干合并到我的分支。然后，当我想将我的新作品合并到主干中时，我不得不重新合并我刚刚合并到我的分支中的所有东西，以及我的新作品。
2. 开发人员分支机构有助于有效的代码审查。当我使用CC时，我们审查了所有内容。但实际上，评论需要时间，我们需要继续工作。每件作品都与CC中的活动相对应。只有在审核完成后，我们才会将活动交付给整合流。如果审核需要更改，我可以决定对我执行原始工作的活动进行更改（只要对该活动中更改的文件没有进行后续更改），创建新活动以解决审核更改，或者可能会吹走整个活动并重新开始（再次，只要没有进行后续更改）。在TFS和SVN中，一旦你投入了一些东西，你就不能轻易回去而不会让后续的工作失败。因此，我们必须找到一些其他方式来向其他开发人员展示我们的更改。最终将差异转换为网页，但是，如果没有将其与待审核的工作混合，我们仍然无法继续进行更多的工作。
3. 使用动态视图可以更轻松地进行跨平台开发。我在这里只有SVN进行比较，所以也许Mercurial或其他更好。我的目标是在Linux和PowerPC平台（以及另一个项目的Windows）上进行更改，构建，测试和调试，并在我很高兴它可以在所有平台上运行时提交单个变更集。对于PowerPC构建，我们有一个sun工作站（访问动态视图），我们用它来构建和测试目标。它很慢，所以我们在Linux上进行了大部分编码和调试，然后在（PowerPC）目标上进行最终测试之前在PowerPC上构建和测试，最后签到。解决此问题的一种方法是网络文件共享。我在这里看到的一个问题是Windows上的Linux svn和TortoiseSVN之间的版本不兼容。如果你让Tortoise进入Linux repo副本，它会更改.svn文件，然后Linux svn会抱怨版本太新了。 （由于我们为目标选择的平台，我们无法将我们的Linux盒升级到足够新的svn。）所以我不能在Linux svn repo中使用我的Windows diff工具。如果我采用其他方式，使用Windows签出和Linux挂载Windows存储库，则不会保留符号链接（Linux版本中需要这些符号链接）。

我不同意，维护ClearCase是一场噩梦，将花费你的钱。但是一旦设置好，它就可以提供一个非常好的开发环境。特别是当您开始与ClearQuest集成时（缺陷跟踪，我们也用于跟踪代码审查）。

正如另一位回应者所说，你的答案在很大程度上取决于你的过程需求。

Answer 9

在我以前的公司（CMMi流程）中，大约100名开发人员/测试人员/集成人员使用ClearCase（CC）和3名全职管理员（增加2名自愿兼职）。 除非使用配置管理部分（基线），否则应继续使用现代SCM。基线功能非常强大：在传统的SCM中，当您更新/ rebase时，默认情况下会获得最新的修订。基线是某些“兼容”版本的软件组件集，以确保构建正常。在某种程度上，它就像依赖构建（即Maven，Ant Ivy）。当开发人员在基线上重新定义（更新）时，他们会获得应该“可构建”的内容。

现在回顾我的新公司（敏捷商店），我们使用SVN和Mercurial，我认为CC每天都很痛苦。使用CC处理项目（存储库），您可以创建视图，创建活动，然后签出文件。有些同事害怕做分支:)。 使用SVN和Mercurial，我们的GUI客户端没有这样的问题。开发人员每天承诺10次。与CC相比，人们每天都会登记一次。

确实，CC有很多开销，网络延迟慢，许可证成本高，需要全职管理员。那么除了配置管理之外还有什么好处呢。

在Mercurial上，工作流程更轻松。对于我们当前的项目，一个人通过提交非源文件搞砸了。 Hg历史是不可改变的。我们没有管理员。一位开发人员在半天内重新克隆了一个新项目。 在Clearcase中，您需要请专家来备份已删除的文件:)。要创建新的仓库，请询问您的管理员：）

离开ClearCase之后，现在我对SVN尤其是Mercurial非常满意。因此，从ClearCase转移到Mercurial将非常轻量级，并且您可以获得更高的生产力。

现在SVN和Mercurial之间的选择？您应该问自己是集中还是分散的存储库。您可以快速搜索stackoverflow。

我开始不喜欢IBM Rational产品，而选择优雅的开源解决方案。

如果您阅读并理解它，则应标题为“从clearcase升级为svn-mercurial”。

已添加： Clearcase落后于推荐能力阈值，而Mercurial，Subversion＆amp; Git显然是值得推荐的。 http://martinfowler.com/bliki/VersionControlTools.html
你也可以结合Mercurial＆amp; ClearCase的。阅读“多个VCS”段落

Answer 10

过去几周我一直在寻找SCM（软件配置管理）和ALM（应用程序生命周期管理）工具，以取代CVS并支持Agile的采用。

如果您正在寻找能够支持并行开发和分支的真正SCM的东西，那么可能有更多的替代方案，而不是您意识到的。

对于简单的SCM解决方案，请查看以下内容：

• Accurev：这是一个SCM工具，它支持基于流/并行的开发。它提供了一个非常好的流浏览器，为您提供流的图形视图，并允许您以图形方式促进更改作为问题或变更集（强制执行原始提升的一组源文件）。它有一个内置的问题跟踪器，可以为您提供变更管理，让您以基于任务的方式工作。使用AccuFlow，您可以通过工作流程更好地控制您的更改，Accubridge为您提供IDE集成。
• Seapine Surround：这是一款外观漂亮的工具，适用于分支，但不如Accurev先进。 Seapine的优点在于它与问题跟踪工具TestTrack Pro以及他们的测试用例管理解决方案TestTrack TCM（它们组合成TestTrack Stuido）的集成。最后，他们还拥有QA Wizard Pro，这是一个web和winforms自动化测试工具。
• PureCM：这是另一种非常受欢迎的选择，但我没有详细看过它
• Perforce：此空间中的另一个替代方案，我并没有那么深刻，但它确实有一些有趣的利基功能，如比较和合并图像的能力。
• 塑料SCM：一个不成熟的产品，但看起来非常有趣。

所有这些解决方案都提供了更好的分支支持，而ClearCase具有本机支持的概念，例如开发人员沙箱（而不是在ClearCase中使用那些疯狂的视图）和verions快照。实际上是一个只读分支，有点像基线。

如果您有广泛的Rational部署，您可能希望研究这些替代方案：

• MKS Integrity：这是一款很好的产品，它具有出色的产品组合管理工具和良好的内置测试运行视图。它的所有工具都属于一个IDE，可以自定义。
• Serena CM：这是一个足够好的套件，围绕核心ALM解决方案提供了大量工具。非常大的投资组合管理部分，Mashups组件提供了大量的支持流程支持，并且还支持原型设计。
• Telelogic：具有讽刺意味的是，现在是IBM的一部分，很快将成为IBM的理性人选。它的SCM解决方案（Telelogic Change和Synergy）是我见过的最好的，能够通过任务明确地将代码更改提升到发布版本分支。

上述所有解决方案都支持与Accurev等相同的SCM概念，但显然是更多的端到端产品，并且是企业规模。

此时我们已将选择范围缩小至MKS或Telelogic。

我最大的一点是，ClearCase和CVS / Subversion之间存在许多很多解决方案，这些解决方案是商业化的但又非常便宜。

希望这是有用的。

Answer 11

我建议阅读HG Init - Joel Spolsky关于如何从SVN切换到Mercurial的指南。

正如之前的一些答案所提到的，SVN和ClearCase基本上都在相同的范例下工作，所以当你阅读这篇文章时，你几乎可以用“ClearCase”替换“Subversion”这个词，并将它应用到你的情境中

这是最终说服我开始在工作中使用Mercurial的写作。

Answer 12

我很想知道你的分支结构是如何建立的。

为什么用户在您产品的“主干”上工作？ （我认为这意味着你的主要分支）。开发分支是否会阻止您的开发人员影响主干？

为什么你不能在rmview脚本上引入一个触发器来防止用户在仍然有结账的情况下删除视图？这是一个非常简单的练习，网上有很多资源（如果你问的话，我相信StackOverflow会为你提供答案！）。

另一个建议是，如果你已经在IBM产品上投入了现金（因此愿意在商业支持的SCM环境上花钱），你可能想看看Team Concert和Jazz。

Answer 13

听起来像你会对git / mercurial感到高兴，而且可能不会出现在SVN中。 OTOH，我所有的清晰经验都是乏味和不爱的，所以我认为任何“逃避”行动确实是一件非常好的事情。

分布式系统听起来更像是与您的工作流程相匹配。