我们正在考虑从ClearCase迁移到Subversion。该项目已经存在了一段时间（7年），我们积极支持三个“主要”版本（分支），以及旧版本中的一些偶尔修复。该项目相当大 - 大约有2百万行java代码。
我很好奇是否有人做过类似的迁移。
答案 0 :(得分：9)
为了进行这种迁移，我认为：
您无需将所有 ClearCase版本的历史记录导入SVN。大多数时候（根据我的经验），只需要标记版本（在给定集合的所有文件上一致应用的版本），除非您真正需要细粒度的历史修订版本。
您需要在迁移过程中考虑 重组 ：您导入什么？，您要离开什么？，您是否希望SVN内容反映出来？ 完全存储在ClearCase VOB中的文件结构？有时，这种迁移是重新考虑其中一些文件组织的时机（通常通过对某些目录的简单重命名规则）。
ClearCase 2 SVN方式的迁移速度更快，因为SVN是以存储库为中心并提交一组文件，而ClearCase是以文件为中心的，并且逐个文件提交（很多懒人）
如果要明确标识要导入的文件集，迁移过程可以重复多次，这意味着您可以在第一次（大）导入时继续在ClearCase中工作，然后放入代码上的基线（UCM标签），仅重新导入增量，有效地结束了迁移过程。
答案 1 :(得分：5)
首先是一些资源：
实际存储库的大小，文件数量或大小不是SVN的限制因素。开发人员的数量，变更的并发性，集成和发布过程的复杂性，合并和目录版本控制（重构）的需要可能会给大型项目带来问题。如果您的项目很大，但它相当稳定，开发人员数量少，分支机构数量少，并且不需要向几个先前版本提供大量修补程序，SVN应该可以为您做好。
我编写了一个自定义迁移工具，将数据从ClearCase中取出，这并非易事。每两个系统对数据具有不同的数据模型和操作。我不建议尝试编写任何自定义迁移工具，因为实际上很难以任何有意义的方式从ClearCase中获取数据。有关商业解决方案限制的详细信息，我建议您联系资源中链接的解决方案提供商。
我个人会尝试尽可能多地提供数据，但您必须了解SVN与ClearCase相比的局限性。在此迁移过程中，任何目录版本控制（重构）历史记录都可能会丢失。 SVN不支持像ClearCase这样的稀疏分支，如果您使用任务分支，它可能会膨胀SVN存储库的大小。在这种情况下，您可能希望仅限于系统分支。 ClearCase中的文件具有单独的分支结构，而SVN具有每个产品的分支类型，这将导致在该过程中进行大量分支转换。通过将自己限制在系统分支中，并且可能只是在这些分支上标记版本以获得系列中完全集成的标签，您可以省去很多麻烦。如果您的团队正在使用UCM，您几乎可以忘记所有UCM元数据。它们不会转换为SVN。
时间范围在很大程度上取决于所使用的工具。对于像你这样的重大项目，它甚至可能是数周。 ClearCase数据库有一些奇怪的原因，即使在读取操作上也有很多锁定，并且有一个中心表，它会在迁移等大规模访问中产生许多问题。我第一次在比你的产品稍大的产品上运行我的工具，我们估计它将运行3年，经过大量优化，并行化和增量迁移后，它减少到大约一周。但是，根据工具的完成程度，可能会出现很多差异。虽然自从迁移到SVN后，您将忽略ClearCase中的大量历史记录和元数据，但迁移速度应该快得多。
ClearVision在其网页上提到其CC2SVN工具可以在两种产品之间建立桥梁。虽然我没有使用这个工具，如果它按照我的假设工作，它会让你在一些处理后同步2个存储库，这将允许你进行一些周末切换，零开发停机时间。如果无法做到这一点，请尝试寻求一些替代方法，例如增量迁移，首先迁移到某个日期，然后迁移自该日期以来更改的较小数据块。
该过程非常重要的部分是迁移后阶段。请不要忽视交换机给您的开发人员带来的麻烦。您不能低估培训和清晰文档的必要性。您还需要在您的软件工程部门中经过培训的支持团队，该团队能够操作两个SCM系统并向开发人员解释如何在新系统中执行他们习惯的操作。这实际上是一个可能在迁移中破坏你的关键点。开发人员抵制任何变化以及SVN为项目带来的任何优势，它本质上是低劣的系统。 ClearCase为您的开发人员提供了他们在SVN中永远不会拥有的灵活性，除非您在此过程中尽早使用它们，否则您可能会丢失它们或者更糟糕的是，让整个迁移工作逆转，宣布灾难并失去自己的工作。
答案 2 :(得分：3)
如果您决定移动，可以查看此stackoverflow问题 recommendation-on-tools-to-migrate-from-clearcase-to-svn
答案 3 :(得分：1)
答案 4 :(得分：1)
另一个选项是Migrate2SVN。开发人员（Clearvision）刚刚发布了v2.0，它似乎包含了许多优于Polarion软件和上述其他方法的改进。