为什么Mercurial中的分支和合并比Subversion更容易？

在Subversion或CVS中处理多个合并到分支上只是必须经历的事情之一.在Mercurial(以及可能是任何其他分布式系统)中跟踪分支和合并非常容易,但我不知道为什么.还有其他人知道吗？

我的问题源于这样一个事实:使用Mercurial你可以采用类似于Subversions/CVSs中央存储库的工作实践,一切都会正常工作.您可以在同一分支上执行多个合并,并且您不需要具有提交编号和标记名称的无数废纸.

我知道最新版本的Subversion能够跟踪合并到分支机构,所以你不会有相同程度的麻烦,但它是一个巨大而重大的开发,并且它仍然不能完成开发团队所做的一切喜欢这样做.

它的运作方式必然存在根本区别.

1> Damien Diede..：

---

在Subversion(和CVS)中,存储库是首要的.在git和mercurial中,并没有以相同的方式存储库的概念; 这里的变化是中心主题.

+1

CVS/SVN的麻烦来自于这些系统不 记得变化的父母身份.在Git和Mercurial中,不仅可以提交多个子项,还可以拥有多个父项!

使用其中一个图形工具很容易观察到,gitk或者hg view.在下面的示例中,分支#2在提交A处从#1分叉,并且已经合并一次(在M处,与提交B合并):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

注意A和B有两个孩子,而M有两个孩子.这些关系记录在存储库中.假设分支#2的维护者现在想要合并分支#1的最新变化,他们可以发出如下命令:

$ git merge branch-1

并且该工具将自动知道基数是B - 因为它记录在提交M(#2的尖端的祖先)中,并且它必须合并B和C之间发生的任何事情.CVS不记录此信息,1.5版之前的SVN也没有.在这些系统中,图形看起来像:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

M只是A和B之间发生的所有事情的巨大"压扁"提交,应用于M之上.注意,在契约完成后,没有任何痕迹(除了可能在人类可读的评论中)M的位置确实起源于,也没有多少承诺崩溃在一起 - 使历史变得更加难以捉摸.

更糟糕的是,进行第二次合并变成了一场噩梦:一个人必须弄清楚什么合并的基础是在第一个合并的时间(和一个具有到知道 的是,已经在第一时间合并!),那么目前这该工具的信息,以便它不会尝试在M之上重放A..B.当在密切协作中工作时,这一切都很困难,但在分布式环境中根本不可能.

一个(相关的)问题是没有办法回答这个问题:"X是否包含B？" 其中B是一个潜在的重要bug修复.那么,为什么不在提交中记录该信息,因为它在合并时已知!

P.-S. - 我没有SVN 1.5+合并录制功能的经验,但工作流程似乎比分布式系统更加人为.如果情况确实如此,那可能是因为 - 如上面的评论所述 - 重点放在存储库组织而不是变更本身.

---

SVN 1.5+确实会在合并提交M上放置一个SVN属性,列出它包含的合并提交,换句话说AB.所以你有相同的信息.

---

有没有+100按钮的祸患.谢谢.

2> htanata..：

---

因为Subversion(至少版本1.4及以下版本)无法跟踪已合并的内容.对于Subversion,合并与任何提交基本相同,而在其他版本控制(如Git)上,已合并的内容会被记住.

3> Tomislav Nak..：

---

Hg提供了卓越的合并功能,因为它在合并更改时使用了更多信息(hginit.com):未提供任何已提供的答案.

例如,如果我稍微更改一个函数,然后将其移动到其他地方,Subversion就不会真正记住这些步骤,所以当合并的时候,它可能会认为一个新的函数只是出现了蓝色.Mercurial将分别记住这些事情:功能已更改,功能已移动,这意味着如果您稍微更改了该功能,则Mercurial更有可能成功合并我们的更改.

当然,记住最后合并的内容(这里提供的大多数答案所解决的问题)也是一个巨大的胜利.

然而,这两项改进都值得怀疑,因为subversion 1.5+以subversion属性的形式存储了额外的合并信息:可用的信息,没有明显的理由说明为什么subversion合并无法像Hg或Git那样成功实现合并.我不知道它是否确实如此,但它肯定听起来像颠覆开发者正在解决这个问题.