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

16

我们正在考虑从ClearCase迁移到Subversion。该项目已经存在一段时间(7年),我们积极支持三个“重要”的版本(分支),以及对旧版本的一些偶尔修复。该项目相当大 - 大约有2百万行Java代码。

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

  • SVN能够处理这样一个大型项目吗?
  • 整个历史版本/分支是否都需要迁移?是否有可进行选择性迁移的工具?
  • 这样的项目迁移过程需要多长时间,以及在迁移过程中的有效工作方式是什么?

短问题。Windows? - Avram
5个回答

9

我已经进行了多次此类迁移,我认为:

  • 你不需要将ClearCase版本的所有历史记录导入到SVN中。大多数情况下(根据我的经验),只需要标记版本(在给定集合的所有文件上一致应用的版本)即可,除非你真正需要进行细粒度的历史修订审查。

  • 在迁移期间需要考虑重新组织:你要导入什么?留下什么?你是否希望SVN的内容完全反映存储在ClearCase VOB中的文件结构?有时,这种迁移是重新考虑某些文件组织的机会(通常通过简单的重命名规则来处理某些目录)。

  • 使用ClearCase 2 SVN方法进行迁移速度更快,因为SVN是以仓库为中心的,并提交一组文件,而ClearCase是以文件为中心的,并逐个文件提交(速度慢得多)。

  • 如果明确定义了要导入的文件集,则可以多次重复迁移过程,这意味着您可以在ClearCase中继续工作,同时进行第一次(大量)导入,然后在您的代码上放置一个基线(UCM标签),并重新导入仅差异部分,从而有效地结束迁移过程。


5

首先是一些资源:

  1. Clearvision CC2SVN 工具
  2. Polarion 的 SVN 迁移工具
  3. CollabNet 上的文章和资源

实际仓库的大小、文件数量或其大小对 SVN 并不构成限制因素。对于大型项目,开发人员数量、并发更改的复杂性、集成和发布过程的复杂性、合并和目录版本控制(重构)的需求可能会带来问题。如果您的项目只是大型的,但相当稳定,开发者数量较少,分支数量较少,且不需要将大量修复程序回溯到几个之前的版本中,则 SVN 应该可以很好地满足您的需求。

我编写了一个自定义迁移工具,将数据从 ClearCase 中提取出来并不是易事。每两个系统都有不同的数据模型和数据操作方式。我不建议尝试编写任何自定义迁移工具,因为实际上很难以有意义的方式从 ClearCase 中获取数据。有关商业解决方案的限制详细信息,建议联系资源中链接的解决方案提供商。

我个人会尽可能多地迁移数据,但您必须了解 SVN 相对于 ClearCase 的限制。在此迁移过程中,任何目录版本控制(重构)历史记录都可能会丢失。SVN 不支持像 ClearCase 那样的稀疏分支,这可能会导致您的 SVN 仓库大小膨胀,如果您使用任务分支,则可能只想限制自己使用系统分支。ClearCase 中的文件具有单独的分支结构,而 SVN 按产品分支,这将导致许多分支转换过程。通过仅限制自己使用系统分支,或者仅使用完全集成标签系列上的标记版本,可以为自己节省很多麻烦。如果您的团队正在使用 UCM,则几乎可以忘记所有 UCM 元数据。它们不会转换为 SVN。

时间取决于所使用的工具。对于像您这样的大型项目,甚至可能需要数周时间。ClearCase 数据库在读取操作中有很多锁定,这是出于某种奇怪的原因,并且有一个包含所有内容的中心表格,这在类似于迁移的大规模访问中会造成很多问题。第一次在比您的产品略大的产品上运行我的工具时,我们估计它将运行 3 年左右,经过大量优化、并行化和增量迁移后,它缩短到了约一周的时间。但是请注意,取决于工具编写得有多好,所需时间可能会有很大差异。尽管因为您将迁移到 SVN,并且您将忽略 ClearCase 中的许多历史记录和元数据,因此您的迁移应该会快得多。

ClearVision在其页面上提到,其CC2SVN工具可以在两个产品之间创建一个桥梁。虽然我没有使用过这个工具,但如果它像我想象的那样工作,它将允许您在一些处理后同步这两个存储库,这将使您能够在周末切换而不会有任何开发停机时间。如果这不可能,请尝试寻求一些替代方案,例如增量迁移,其中您首先迁移至某个日期,然后迁移自该日期以来更改的较小数据块。
过程中非常重要的部分是迁移后阶段。请不要低估转换将给您的开发人员带来的头痛。您必须不断强调培训和清晰的文档的需求。您还需要在软件工程部门拥有一个受过训练的支持团队,他们能够操作两个SCM系统并向开发人员解释如何在新系统中完成他们习惯于在旧系统中完成的任务。这实际上是一个可能会在迁移中使您失败的关键点。开发人员抵制任何变化,无论SVN为项目带来了什么优势,它本质上都是一个更差的系统。ClearCase为您的开发人员提供了如此多的灵活性,他们永远无法与SVN一样。除非您在过程的早期将他们纳入团队,否则您可能会失去他们或更糟的是,整个迁移被撤销,宣布为灾难并失去您自己的工作。

3

1
另一个选项是Migrate2SVN。开发者(Clearvision)刚刚发布了v2.0版本,它似乎比上述Polarion软件和其他方法都有许多,许多的改进。

1
  1. 是的,Subversion可以处理非常大的项目。例如,所有 Apache 项目 都在一个单独的 Subversion 存储库中,其中子项目是简单的子文件夹。
  2. 如果将所有历史记录转换为有意义的内容,则需要自行决定。但是有很多可用的工具。可以在此处找到一篇好的博客文章。
  3. 我不知道这种转换需要多长时间。但你可以先尝试使用一个小的子集并测量时间。

与您想象的相反,Apache并不是一个非常庞大的项目,甚至不算大型项目。它只有大约30个贡献者。它是一个中等规模的项目。SVN实际上无法处理大型项目。代码库的大小并不是决定性因素,更重要的是需要合作的人数以及交互、分支和合并的数量。 - Jiri Klouda
在你对项目规模做出错误的假设之前,请先查看Apache存储库(http://svn.apache.org/repos/asf/)。该存储库不仅托管Apache Web服务器项目,而且还包括所有 Apache项目,以及数百个提交者。 - Stefan
代码库的大小通常对于任何源代码控制系统都不是问题。除了可能ClearCase,在以前的版本中,每个vob的对象数量限制为1600万,这意味着任何版本或标签应用于任何版本。对于大型项目,您需要数十个vobs或开始删除旧版本。虽然这与本特定问题无关,但您对Apache的说法仍然不能使其成为一个大型项目,只是一个大型代码库。 SVN完全能够处理大型代码库,但不能处理真正大量的贡献者和复杂的开发过程。 - Jiri Klouda

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接