我们的团队一直在使用SVN来管理体面大小的应用程序,并且随着时间的推移,建立了一个相当复杂的分支和标签层次结构,它遵循SVN存储库的基本标准布局,但是多个嵌套:将复杂的SVN分支层次结构迁移到Mercurial
|-trunk |-branches | |-releases | | |-releaseA | | `-releaseB | `-features | |-featureX | `-featureY |-tags |-releaseA | |-beta | `-RTP `-releaseB |-beta `-RTP
(该功能分支显然是临时的分支,但我们必须予以考虑,因为这将是不可行的在不久的将来在一次关闭所有的)
出于多种原因,主要是因为合并已成为越来越多的痛苦,我们认真考虑切换到Mercurial。
我们目前面临的主要问题是迁移现有的代码库而不会丢失我们的历史记录。我尝试了几种迁移工具(例如,yasvn2hg,hg convert和svn2hg),yasvn2hg是最有前途的,但他们都没有能够处理嵌套层次结构,但他们都假设分支和标签被组织在一个平面目录中分别。
命名分支之间的选择或克隆作为旧SVN分支转换目标不是在这种情况下的限制因素,因为任一溶液,将不胜感激。我们目前正在试验这两种选择,以及它们将如何适合我们当前的流程,但尚未决定。我明显对这个问题的建议或类似设置的体验感兴趣。
那么,什么是这样一个嵌套的SVN分支层次转换为Mercurial的最佳方式是什么?
将一个分支一次转换为一个单独的存储库会很烦人,我不确定这是否是正确的方法,这取决于这些工具如何处理历史合并并需要注意所有其他分支?
嘿我差不多发布了同样的问题。自问这个问题以来,如果你决定采用一种解决方案,会很乐意听到。正如下面在评论中提到的,在我的情况下,每个嵌套分支有一个“克隆”实际上不是一个解决方案,我当然希望找到一种方法能够将分支导入HG,而无需重复分割数据很多回购。 – 2010-04-01 18:20:30