JWm*_*man 19 svn merge mercurial branching-and-merging
在它出现之前,我已经看过这个主题的几个主题,包括:
我正在寻找为我们的开发小组切换到Mercurial(来自Subversion).在我这样做之前,我正在做通常的利弊列表.
我的"优点"之一是Mercurial的合并优势,但到目前为止,我没有找到令人信服的证据.也就是说,在HgInit.com上发表声明,我无法核实:
例如,如果我稍微更改一个函数,然后将其移动到其他地方,Subversion就不会真正记住这些步骤,所以当合并的时候,它可能会认为一个新的函数只是出现了蓝色.Mercurial将分别记住这些事情:功能已更改,功能已移动,这意味着如果您稍微更改了该功能,则Mercurial更有可能成功合并我们的更改.
这将是非常引人注目的功能,但据我所知,这只是热空气.我一直无法验证上述声明.
我创建了一个Mercurial存储库,做了一个Hello World,然后克隆了它.在一个我修改了函数,提交它然后移动它,然后提交它.在另一个中,我只是在函数中添加了另一个输出行并提交了.
当我合并时,我得到的基本相同的合并冲突我将使用Subversion.
我知道mercurial可以更好地跟踪文件重命名,除了合并之外DVCS还有其他优点,但我对这个例子很感兴趣.乔尔斯波尔斯基在这里偏离基地,还是我错过了什么？
我在这方面没有经验,但看起来确实如此,因为Mercurial保留了更多的信息,理论上它可以更好地合并(如果开发人员也经常进行签名).例如,我认为Mercurial可以通过比较多个更改来获取上下文更改,例如,我修改函数,签入,移动函数,签入,以及Mercurial将这两个部分关联起来.
但是,Mercurial的合并似乎并没有真正利用添加的信息,并且似乎与Subversion的操作方式相同.它是否正确？
据我所知,任何说Mercurial跟踪代码文件大小不足的人都是错误的.它确实独立于代码更改跟踪文件重命名,因此如果Dave重命名文件并且Helen更改文件中的某些内容,它可以自动执行此操作,但据我所知,Subversion也可以这样做!(CVS不能.)
但是,是在Mercurial的合并逻辑,远远高于Subversion的更好的方式:它会记住冲突解决.考虑这个历史图表:
base ---> HELEN1 ---> merge1 --> HELEN2 -> merge2
\--> DAVE1 ---/ /
\--> DAVE2 ---------/
海伦和戴夫独立做出改变.海伦拉着戴夫的树并合并,然后又做了另一个改变.与此同时,戴夫继续编码而没有费心去海伦.然后海伦又拉了戴夫的树.(也许Dave正在开发主干开发,Helen关闭了一个功能分支,但她希望定期与主干更改同步.)构建"merge2"时,Mercurial会记住在"merge1"中完成的所有冲突解决方案并且只显示了Helen的新冲突,但是Subversion会让Helen从头开始重新合并.(有些方法可以避免使用Subversion,但它们都涉及额外的手动步骤.Mercurial会为你处理它.)
有关更多信息,请阅读为Merotial和Git现在使用为Monotone和AFAIK开发的标记合并算法.