SVN支持历史合并,那么Mercurial如何更好？

Question

可能重复:
合并:hg/git与svn

嗨,

我是SVN的长期用户,并且在一般的mercurial和分散版本控制系统方面已经听到了很多关于我的事情.我所知道的主要功能是Mercurial中的合并更容易,因为它记录了每个合并的信息,因此每个连续的合并都知道以前的合并.

现在正如红皮书中所述,在与合并有关的部分中,SVN已经通过mergeinfo支持了这一点.现在我还没有真正使用过这个功能(虽然我想,我们的repo版本不够新)但是这个SVN功能与Mercurial提供的特别不同吗？

对于那些不知道svn中历史合并的建议工作流程的人是这样的:

1. 从开发主干分支做自己的事情.

2. 定期将更改从主干合并到您的分支以保持最新.

3. 完成mergeinfo后合并以平滑过程.

没有历史数据合并这是一场噩梦,因为比较严格依赖于文件中的差异,并没有考虑到路上采取的步骤.因此,当您合并回来时,开发主干中的每个更改都会使您进一步陷入冲突.

现在我想知道的是:

与SVN中的mergeinfo相比,使用Mercurial合并是否提供了显着的优势,或者这只是一些关于什么的热点？

有没有人在SVN中使用了mergeinfo功能,实际上它有多好？

Answer 1

正如评论中所提到的,这个SO问题几乎总结了它,但它指出了确切的Subversion(1.6最新!)文档说明合并限制:

• 基本合并(原文如此)/重新整合分支:

    svn merge --reintegrate ^/branches/my-calc-branc

一旦--reintegrate从分支到主干进行合并,分支就不再可用于进一步的工作.它无法正确吸收新的行李箱更换,也无法再次正确地重新集成到行李箱.

什么？如果自从上次合并回到主干后你在该分支上工作了一些,你就不能再进行第二次 --reintegrate合并了吗？
你必须创建另一个分支或使用一个挑选语法,还有另一个选项来保持它活着.

• 推进合并

结论告诉你所有你需要知道的事情:

底线是Subversion的合并跟踪功能具有极其复杂的内部实现,该svn:mergeinfo属性是用户进入机器的唯一窗口.由于该功能相对较新,因此可能会弹出许多边缘情况和可能的意外行为.

例如,有时在运行simple svn copy或svn movecommand 时会生成mergeinfo .

• 有时mergeinfo将出现在您不希望被操作触及的文件上.
• 有时候,当你期望它时,根本不会生成mergeinfo.

此外,mergeinfo元数据的管理具有:

• 围绕它的一整套分类法和行为,例如"显式"与"隐式"合并信息,"操作"与"不工作"修订,
• mergeinfo"elision"的具体机制
• 甚至从父目录到子目录的"继承".

让我们将其与DVCS进行比较:

刚合并;)

这并不意味着SVN不知道如何合并(对于简单的合并工作流,它将完成工作),但其底层机制的复杂性将实际上限制分支和合并的使用,使少数合并保持公平不重要的.
相比之下,DVCS中合并操作的简易性将增加分支的使用和合并场景的复杂性,这不再是问题.