我们的团队一直在使用SVN管理体面大小的应用程序，随着时间的推移，已建立了相当复杂的分支和标签层次结构，这是遵循SVN存储库的基本标准布局，但更嵌套：
|-trunk
|-branches
| |-releases
| | |-releaseA
| | `-releaseB
| `-features
| |-featureX
| `-featureY
|-tags
|-releaseA
| |-beta
| `-RTP
`-releaseB
|-beta
`-RTP
（特征分支显然是临时分支，但我们必须考虑它们，因为在不久的将来不可能立即关闭所有分支）
由于多种原因，但主要是因为合并变得越来越痛苦，我们正在考虑转向Mercurial。
我们目前面临的主要问题是迁移现有代码库而不会丢失历史记录。我已经尝试了几种迁移工具（例如，yasvn2hg，hg convert和svn2hg），yasvn2hg是最有希望的，但它们似乎都没有能够处理嵌套的层次结构，但它们所有人都假设分支和标签分别组织在一个平面目录中。
命名分支或克隆之间的选择作为旧SVN分支的转换目标在这种情况下不是限制因素，因为任何解决方案都将被理解。我们目前正在试验这两种选择以及它们如何适应我们当前的流程，但还没有决定。我显然对有关该问题的类似设置的建议或经验感兴趣。
那么，将嵌套的SVN分支层次结构转换为Mercurial的最佳方法是什么？
将一个分支一次转换为一个单独的存储库会非常烦人，我不确定这是否是正确的方法，这取决于工具如何处理历史合并并需要了解所有其他分支？
答案 0 :(得分：2)
我读过的一篇优秀文章是。 http://ww2.samhart.com/node/50
答案 1 :(得分：2)
你应该在mercurial mailing list上提出这样的问题。这就是Mercurial开发人员所在的地方，并且随着时间的推移出现了许多Subversion迁移问题。
话虽这么说，recent change可能会帮助你 - 它声称会让你
[...]修复即使是最糟糕的管理不善的存储库，并将它们转换为结构良好的Mercurial存储库。
我自己没有尝试过，所以我无法评论你的具体情况会有多大效果。