当主干/分支/标签结构混乱时，如何从 Subversion 迁移到 Mercurial？

我想将存储库从 Subversion 转换为 Mercurial，但是当我最初设置存储库时，我以最懒的方式完成了它。随着时间的推移，该结构不断变形和恶化（此时已有 5 年历史）。尽管如此，我还是想保留尽可能多的历史，即使我必须弄脏并手动将东西缝合在一起。

话不多说，当前的结构如下所示：

svn://svn.example.com/Example
    + trunk
        + BigProject
        + BinaryDepedencies
    + branches
        + BigProject
            + branch1
            + feature1
            + maintenance1
            + ...
    + tags
        + BigProject
            + tag1
            + tag2
            + ...
    + projects
        + small_project1
        + small_project2
        + small_project3
        + ...

鉴于这只是最新的结构，这个存储库还有希望吗？如果没有希望，任何人都有一个在 Mercurial（或 bazaar）中手工重建历史的好方法。

另外，由于各种原因，我将无法使用 git，除非有一个防弹策略将这个特定的存储库从 Subversion 转换为 git 再转换为 hg/bzr。

一种策略可能是转换主干。如果你的躯干移动了，你可能需要玩一些游戏，但这应该不会太难。

你的武器库中的另一个工具可能是 hg->hg 转换和 rebase 扩展。当你将东西放入 hg 存储库后，你可以使用它们来摆弄你的树，并在转换它们后移植到分支上。或者在移动后移植您的主干历史记录的新片段。

这是一个很好的文档链接Mercurial 变基扩展 http://mercurial.selenic.com/wiki/RebaseExtension.

基本上，这是您要遵循的策略...首先，使用转换扩展名 http://mercurial.selenic.com/wiki/ConvertExtension or hgsvn http://pypi.python.org/pypi/hgsvn转换存储库的部分内容。这可能会导致多行主干，或者分支位于与主线不同的存储库中。

如果您有两部分 trunk 位于不同的存储库中，并且位于名为second直接跟在目录中名为first， 你可以这样做：

cd second
hg log -r 0
# Note the revision hash
cd ../first
hg tip
# Again, note the revision hash
hg pull -f ../second
hg rebase --source <revision hash from hg log -r 0> --dest <revision hash from hg tip>

这会将树干的一部分移植到树干的另一部分上。

如果您在单独的存储库中有一个分支，则过程会稍微复杂一些：

cd branch
hg log -r 0
# Note the revision hash
cd ../trunk
# Find the revision that the branch branches off from and note its hash.
# We will call this revision the 'branch base'.
hg pull -f ../branch
hg rebase --source <revision hash from hg log -r 0> --dest <revision hash of branch base>

这会将树枝嫁接到主树上。