将复杂的 SVN 分支层次结构迁移到 Mercurial
我们的团队一直使用 SVN 来管理规模相当大的应用程序，随着时间的推移，已经建立了相当复杂的分支和标签层次结构，它遵循 SVN 存储库的基本标准布局，但更加嵌套：（
|-trunk
|-branches
| |-releases
| | |-releaseA
| | `-releaseB
| `-features
| |-featureX
| `-featureY
|-tags
|-releaseA
| |-beta
| `-RTP
`-releaseB
|-beta
`-RTP
功能分支显然是临时分支，但我们必须考虑到它们，因为在不久的将来一次性关闭所有分支是不可行的）
出于多种原因，但主要是因为合并变得越来越痛苦，我们正在考虑切换到 Mercurial 。
我们当前面临的主要问题是在不丢失历史记录的情况下迁移现有代码库。 我尝试过几种迁移工具（例如，yasvn2hg、hg 转换 和 svn2hg），其中 yasvn2hg 是最有前途的，但它们似乎都不能处理嵌套层次结构，但它们都假设分支和标签分别组织在一个平面目录中。
在这种情况下，选择命名分支或克隆作为旧 SVN 分支的转换目标并不是限制因素，因为任何一种解决方案都会受到赞赏。 我们目前正在尝试这两种选择以及它们如何适应我们当前的流程，但尚未决定哪一种。 我显然也对有关该问题的类似设置的建议或经验感兴趣。
那么，将这样的嵌套 SVN 分支层次结构转换为 Mercurial 的最佳方法是什么？ 一次将
一个分支转换为单独的存储库会非常烦人，我不确定这是否是正确的方法，具体取决于工具如何处理历史合并并且需要了解所有其他分支机构？
Our team has been using SVN for managing an application of decent size and over time a rather complex hierarchy of branches and tags has built up, which is following the basic standard layout for SVN repositories, but is more nested:
|-trunk
|-branches
| |-releases
| | |-releaseA
| | `-releaseB
| `-features
| |-featureX
| `-featureY
|-tags
|-releaseA
| |-beta
| `-RTP
`-releaseB
|-beta
`-RTP
(The feature branches are obviously temporary branches but we have to take them into consideration as it won't be feasible to close all of them at once in the near future)
For several reasons but primarily because merges have been becoming an increasing pain, we are considering to switch to Mercurial.
The main problem we are currently facing is migrating the existing code base without losing our history. I've tried several migration tools (e.g., yasvn2hg, hg convert and svn2hg) with yasvn2hg being the most promising, but none of them seem to be able to deal with nested hierarchies but they all assume that branches and tags are organized in one flat directory respectively.
The choice between named branches or clones as the conversion target of old SVN branches is not a limiting factor in this case, as either solution would be appreciated. We are currently experimenting with both options and how they would fit into our current processes but haven't decided on one yet. I'd obviously be interested in recommendations or experiences with similar setups concerning that issue as well.
So, what is the best way to convert a nested SVN branch hierarchy like this to Mercurial?
Converting one branch at a time into a separate repository would be quite annoying and I am not sure if that would be the right approach in the first place, depending on how the tools handle historic merges and need to be aware of all other branches?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您确实应该在 mercurial 邮件列表 上提出此类问题。 这就是 Mercurial 开发人员常去的地方，随着时间的推移，出现了许多 Subversion 迁移问题。
话虽这么说，最近的更改可能会对您有所帮助 - 它声称可以让您
我自己还没有尝试过，所以我无法评论它对您的具体情况有多有效。
You should really ask such questions on the mercurial mailing list. That is where the Mercurial developers hang out, and there has been many Subversion migration question over time.
That being said, a recent change might help you -- it claims to let you
I have not tried it out myself, so I cannot comment on how effective it will be for your exact case.