2009-06-05 71 views
6

我们的团队一直在使用SVN来管理体面大小的应用程序,并且随着时间的推移,建立了一个相当复杂的分支和标签层次结构,它遵循SVN存储库的基本标准布局,但是多个嵌套:将复杂的SVN分支层次结构迁移到Mercurial

 
    |-trunk 
    |-branches 
    | |-releases 
    | | |-releaseA 
    | | `-releaseB 
    | `-features 
    |  |-featureX 
    |  `-featureY 
    |-tags 
    |-releaseA 
    | |-beta 
    | `-RTP 
    `-releaseB 
     |-beta 
     `-RTP  

(该功能分支显然是临时的分支,但我们必须予以考虑,因为这将是不可行的在不久的将来在一次关闭所有的)

出于多种原因,主要是因为合并已成为越来越多的痛苦,我们认真考虑切换到Mercurial。

我们目前面临的主要问题是迁移现有的代码库而不会丢失我们的历史记录。我尝试了几种迁移工具(例如,yasvn2hg,hg convertsvn2hg),yasvn2hg是最有前途的,但他们都没有能够处理嵌套层次结构,但他们都假设分支和标签被组织在一个平面目录中分别。

命名分支之间的选择克隆作为旧SVN分支转换目标不是在这种情况下的限制因素,因为任一溶液,将不胜感激。我们目前正在试验这两种选择,以及它们将如何适合我们当前的流程,但尚未决定。我明显对这个问题的建议或类似设置的体验感兴趣。

那么,什么是这样一个嵌套的SVN分支层次转换为Mercurial的最佳方式是什么?

将一个分支一次转换为一个单独的存储库会很烦人,我不确定这是否是正确的方法,这取决于这些工具如何处理历史合并并需要注意所有其他分支?

+0

嘿我差不多发布了同样的问题。自问这个问题以来,如果你决定采用一种解决方案,会很乐意听到。正如下面在评论中提到的,在我的情况下,每个嵌套分支有一个“克隆”实际上不是一个解决方案,我当然希望找到一种方法能够将分支导入HG,而无需重复分割数据很多回购。 – 2010-04-01 18:20:30

回答

2

我读过的优秀文章是。 http://ww2.samhart.com/node/50

+0

此链接提到我的理由将svn回购拆分为多个hg回购 – 2009-06-11 22:26:34

2

你真的应该问这样的问题在mercurial mailing list。这就是Mercurial开发者闲逛的地方,随着时间的推移,出现了许多Subversion迁移问题。

话虽这么说,一个recent change可以帮助你 - 它声称让你

[...]修复,即使是最严重的管理不善库,使他们成为很好的结构化的Mercurial库。

我还没有尝试过自己,所以我不能评论它将如何有效为您的确切情况。

+0

谢谢,我会看看我是否可以找到您提到的修复并尝试一下。关于邮件列表,我肯定会探讨这个选项。我发现有关Mercurial迁移的大多数Google命中或者指向博客条目或SO,因此它似乎是询问 – 2009-06-09 00:19:12