我们正在考虑从ClearCase迁移到Subversion。该项目已经存在一段时间(7年),我们积极支持三个“重要”的版本(分支),以及对旧版本的一些偶尔修复。该项目相当大 - 大约有2百万行Java代码。
我很好奇是否有人做过类似的迁移。
- SVN能够处理这样一个大型项目吗?
- 整个历史版本/分支是否都需要迁移?是否有可进行选择性迁移的工具?
- 这样的项目迁移过程需要多长时间,以及在迁移过程中的有效工作方式是什么?
我已经进行了多次此类迁移,我认为:
你不需要将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工具可以在两个产品之间创建一个桥梁。虽然我没有使用过这个工具,但如果它像我想象的那样工作,它将允许您在一些处理后同步这两个存储库,这将使您能够在周末切换而不会有任何开发停机时间。如果这不可能,请尝试寻求一些替代方案,例如增量迁移,其中您首先迁移至某个日期,然后迁移自该日期以来更改的较小数据块。