如果您想了解实际问题，请滚动到问题的底部。我觉得有必要解释一下情况。
在我们公司，由于历史原因，我们有多个版本控制系统。目前我们正在努力转移到任何 git-fast-import兼容的分布式版本控制系统，但我们现在的选择是Mercurial。我现在说，因为一旦你采取了这一步骤，在大多数情况下，从一个DVCS迁移到另一个DVCS会更容易。
我们基本上有三个代码库，我们想要加入一个已经提交到一个SVN存储库的部分，我们想要将它们分开。
所以我们有：
庞大的仓库（ 2。）包含不同时间点CVS仓库状态（ 1。）的快照。显然没有人在CVS回购中被标记，因为这可能是有用的。最重要的是，快照在该快照状态之上应用了补丁。
这就是说 2。中的子文件夹层次结构大致对应于 1。。但是，没有必要担心它，因为想法是在最初将它们拼接在不同的路径名下之后退出其中一个文件夹。所以这里没有预期的命名冲突。
reposurgeon作为我的首选工具。这是一个非常强大的工具，允许在git-fast-import流上进行外科手术。我热烈推荐给任何负责类似迁移的人。git-fast-import流，btw）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中找不到的特殊特性所迷惑，例如。
如果分支标签被移动＆＃34;强制（cvs tag -B），然后RCS文件中最初分配的分支号变为孤立，另一个新分支号将取代它。但是，旧版本仍保留在文件中。
现在新分支在原始分支发生后数小时，数天或数月开始。这似乎是扰乱所有这些工具的原因。
虽然将孤立的分支包括在内并修补那些“伤口”也很酷，但它不是优先事项。使用cvs tag -B处理的大多数文件不是源文件，而是GNUmakefile或其他项目文件等文件。
然而，问题仍然存在，CVS转换尚未完成，需要更多时间。
经理们变得不耐烦......
是否可以从两个SVN存储库开始拼接到单个Hg存储库中以及稍后（当CVS转换完成时）接合这些更改而不必必须初始化另一个不相关的Hg存储库？
（CVS repo）拼接会不导致冲突的路径，我必须事先说出来。另一个存储库意味着通过它自己的子目录进行拼接，因此没有名称冲突。
我知道推送和拉动可以将两年前的提交引入到某个人的存储库中。但是，这是否意味着hg transplant也可能成功？即我可以期望能够将这些提交从十年前移植到联合Hg存储库吗？
这样我就可以将迁移分成几个阶段。
这个在技术上是否可以通过hg transplant（或任何其他hg扩展程序来实现？
如果是的话，我也会对任何有关潜在警告的建议表示感谢。