使用“hg transplant”在稍后的时间拼接另一个存储库的内容

时间:2015-02-12 12:40:40

标签: svn mercurial cvs reposurgeon

如果您想了解实际问题,请滚动到问题的底部。我觉得有必要解释一下情况。

事态

在我们公司,由于历史原因,我们有多个版本控制系统。目前我们正在努力转移到任何 git-fast-import兼容的分布式版本控制系统,但我们现在的选择是Mercurial。我现在说,因为一旦你采取了这一步骤,在大多数情况下,从一个DVCS迁移到另一个DVCS会更容易。

我们基本上有三个代码库,我们想要加入一个已经提交到一个SVN存储库的部分,我们想要将它们分开。

所以我们有:

  1. 一个古老的CVS存储库
  2. 一个巨大的(26 GiB)SVN存储库,包含大量代码,一些实验代码和实际垃圾(在转换过程中被过滤掉)以及来自各种版本的构建产品,其中包含大量代码,其中包含大量代码进入存储库甚至只是自己的文件夹结构)
  3. 一个包含相关代码的SVN存储库,但与其他两个共享没有文件(将其视为拼接为文件夹)
  4. 庞大的仓库( 2。)包含不同时间点CVS仓库状态( 1。)的快照。显然没有人在CVS回购中被标记,因为这可能是有用的。最重要的是,快照在该快照状态之上应用了补丁。

    这就是说 2。中的子文件夹层次结构大致对应于 1。。但是,没有必要担心它,因为想法是在最初将它们拼接在不同的路径名下之后退出其中一个文件夹。所以这里没有预期的命名冲突。

    到目前为止我做了什么

    • 经过一番研究后,我选择reposurgeon作为我的首选工具。这是一个非常强大的工具,允许在git-fast-import流上进行外科手术。我热烈推荐给任何负责类似迁移的人。
    • 现在已完全涵盖了大型存储库的转换。已删除文件和文件夹,并删除旧符号。 Kinks已被解决,诸如关闭分支(在SVN中)以及稍后从同名的另一个修订版重新打开它之类的东西已被修复,使得它们看起来是连续的。基本上所有的外科手术都已完成。 (结果是{350} MiB作为git-fast-import流,btw)
    • 较小的SVN存储库也被覆盖,尽管仍然存在一些小任务。但是,由于我从庞大的SVN回购中获得的经验,我相信这只是几个小时的事情。
    • 最后但并非最不重要的CVS存储库。我尝试了许多不同的工具,包括cvs-fast-export,现在由Eric S. Raymond维护,他也是reposurgeon的作者。我还考虑过转换为SVN,只是为了发现用于执行此操作的工具集(cvs2svn)已经扩展为导出到Mercurial。

    问题

    虽然SVN转换需要很长时间才能完成,但CVS转换仍在进行中。

    由于CVS没有存储库范围的修订历史记录,因此所有工具都必须尝试解析RCS文件并理解其内容以拼凑拼图。

    我可以通过在编辑器中编辑锁定的RCS文件手动删除一些非常糟糕的伤疤(在进行备份之后)。这样一些无效的修订(RCS和CVS对什么是有效的修订版号有不同的看法)以及在某些文件中作为标记出现的符号以及在其他文件中作为分支被删除的符号。

    我还能够预处理(CVS)存储库,以便在我们感兴趣的分支(rcsfile.py来自rcsgrep之前)删除许多我们不需要的分支和标记)。基本上在该特定点之前,我们只需要MAIN / trunk / default / master的内容,无论您想要什么称呼它。

    但是,有些工具完全失败(例如cvs-fast-export崩溃),而其他工具则会产生有些损坏的结果。

    不是太糟糕,人们可以通过reposurgeon来解决很多问题。但是,有六个分支甚至从未进入转换后的存储库。

    原因似乎是在所有情况下,所有工具都会被您在SVN中找不到的特殊特性所迷惑,例如。

    如果分支标签被移动"强制(cvs tag -B),然后RCS文件中最初分配的分支号变为孤立,另一个新分支号将取代它。但是,旧版本仍保留在文件中。

    现在新分支在原始分支发生后数小时,数天或数月开始。这似乎是扰乱所有这些工具的原因。

    虽然将孤立的分支包括在内并修补那些“伤口”也很酷,但它不是优先事项。使用cvs tag -B处理的大多数文件不是源文件,而是GNUmakefile或其他项目文件等文件。

    然而,问题仍然存在,CVS转换尚未完成,需要更多时间。

    经理们变得不耐烦......

    问题

    是否可以从两个SVN存储库开始拼接到单个Hg存储库中以及稍后(当CVS转换完成时)接合这些更改而不必必须初始化另一个不相关的Hg存储库?

    (CVS repo)拼接会导致冲突的路径,我必须事先说出来。另一个存储库意味着通过它自己的子目录进行拼接,因此没有名称冲突。

    我知道推送和拉动可以将两年前的提交引入到某个人的存储库中。但是,这是否意味着hg transplant也可能成功?即我可以期望能够将这些提交从十年前移植到联合Hg存储库吗?

    这样我就可以将迁移分成几个阶段。

    1. 将两个SVN回购合并为一个Hg回购 - 基本上现在
    2. 从现在起几周/几个月内转换(转换为Hg)CVS回购
    3. 这个在技术上是否可以通过hg transplant(或任何其他hg扩展程序来实现?

      如果是的话,我也会对任何有关潜在警告的建议表示感谢。

0 个答案:

没有答案