从ClearCase迁移到SVN的最佳策略是什么？

我们正在考虑从ClearCase转移到Subversion。该项目已经存在了一段时间（7年），我们积极支持三个“主要”版本（分支），以及旧版本中的一些偶尔修复。这个项目相当大——大约有200万行java代码

我很好奇是否有人做过类似的迁移

• SVN能处理这么大的项目吗
• 迁移所有历史版本/分支有意义吗？有哪些工具可以有选择地做到这一点
• 对于这样一个项目，迁移过程需要多长时间？如果迁移正在进行，有效的工作方式是什么

是的，Subversion可以处理非常大的项目。例如，所有这些都在一个Subversion存储库中，子项目是简单的子文件夹

如果改变所有的历史是有意义的，那你必须自己决定。但是有很多可用的工具。可以找到一篇好的博客文章

我不知道这种转换需要多长时间。但您可以先尝试使用一个小子集并测量时间

---

如果你决定搬家，你可以看看这个stackoverflow问题。

---

由于进行了多次此类迁移，我认为：

• 您不需要将ClearCase版本的所有历史导入SVN。大多数情况下（根据我的经验），只需要标记的版本（在给定集合的所有文件上一致应用的版本），除非您确实需要细粒度的历史修订

• 在迁移过程中，您需要考虑重组：导入什么？保留什么？您希望SVN内容准确反映ClearCase VOB中存储的文件结构吗？有时，这样的迁移是重新考虑某些文件组织的机会（通常通过对某些目录的简单重命名规则）

• ClearCase 2 SVN的迁移速度更快，因为SVN以存储库为中心并提交一组文件，而ClearCase以文件为中心并逐文件提交（速度慢得多）

• 如果要导入的文件集已明确标识，则迁移过程可以重复多次，这意味着您可以在第一次（大型）导入时继续在ClearCase中工作，然后在代码上放置基线（UCM标签），然后仅重新导入增量，从而有效地结束迁移过程

首先是一些资源：

实际存储库的大小、文件的数量或大小不是SVN的限制因素。开发人员的数量、变更的并发性、集成和发布过程的复杂性、合并和目录版本控制（重构）的需要可能会给大型项目带来问题。如果您的项目非常大，但相当稳定，开发人员数量少，分支数量少，并且不需要将大量修复程序向后移植到以前的几个版本中，那么SVN对您来说应该很好

我已经编写了一个自定义迁移工具，将数据带出ClearCase，这不是一项容易的任务。每两个系统都有不同的数据模型和对数据的操作。我不建议尝试编写任何定制的迁移工具，因为以任何有意义的方式从ClearCase中获取数据是非常困难的。有关商业解决方案限制的详细信息，我建议联系参考资料中链接的解决方案提供商

我个人会尽可能多地提供数据，但您必须了解SVN与ClearCase相比的局限性。在此迁移过程中，任何目录版本控制（重构）历史记录都可能丢失。SVN不支持像ClearCase这样的稀疏分支，如果您使用任务分支，它可能会扩大SVN存储库的大小。在这种情况下，您可能只想将自己限制在系统分支上。ClearCase中的文件有单独的分支结构，而SVN有每个产品的分支排序，这将导致在这个过程中大量的分支转换。通过将自己限制在系统分支上，并且可能只是在这些分支上标记版本，以便在系列中完全集成标签，您可以为自己节省很多麻烦。如果您的团队正在使用UCM，您几乎可以忘记所有UCM元数据。它们不会翻译成SVN

时间框架在很大程度上取决于所使用的工具。对于一个像你这样的大项目，甚至可能需要几个星期。ClearCase数据库由于某些奇怪的原因，甚至在读取操作上也有大量的锁定，并且有一个包含所有内容的中心表，这会在大规模访问中产生很多问题，比如迁移可能会导致的问题。我第一次在比你的产品稍大的产品上运行我的工具时，我们估计它将运行3年，经过大量优化、并行化和增量迁移后，它将运行时间缩短到大约一周。但是，根据工具的性能，所需时间可能会有很大的差异。尽管由于您迁移到SVN，并且您将忽略来自ClearCase的大量历史记录和元数据，但您的迁移应该快得多

ClearVision在其网页上提到，其CC2SVN工具可以在两个产品之间建立桥梁。虽然我没有使用这个工具，但如果它像我假设的那样工作，它将允许您在经过一些处理后同步这两个存储库，这将允许您在周末进行切换，并且零开发停机时间。如果这是不可能的，试着要求一些替代方案，比如增量迁移，首先迁移到某个日期，然后迁移自该日期以来更改的较小数据块

这个过程中非常重要的部分是迁移后阶段。请不要忽视这种切换将给开发者带来的麻烦。你必须