什么使DVCS中的合并变得容易？

Question

我在Joel的软件上读到:

使用分布式版本控制,分布式部分实际上不是最有趣的部分.

有趣的是,这些系统考虑的是变化,而不是版本.

在HgInit:

当我们必须合并时,Subversion会尝试查看两个版本 - 我的修改后的代码和修改过的代码 - 它会尝试猜测如何在一个大的邪恶混乱中将它们粉碎在一起.它通常会失败,产生并非真正冲突的"合并冲突"的页面和页面,只是Subversion无法弄清楚我们做了什么的地方.

相比之下,当我们在Mercurial中单独工作时,Mercurial正忙着保留一系列变更集.因此,当我们想要将我们的代码合并在一起时,Mercurial实际上有更多的信息:它知道我们每个人都改变了什么并且可以重新应用这些更改,而不仅仅是查看最终产品并试图猜测如何放置它一起.

通过查看SVN的存储库文件夹,我的印象是Subversion将每个修订版维护为变更集.据我所知,Hg正在使用变更集和快照,而Git纯粹使用快照来存储数据.

如果我的假设是正确的,那么必须有其他方法使DVCS中的合并变得容易.那些是什么？

*更新:

• 我对技术角度更感兴趣,但从非技术角度来看是可以接受的
• 更正:
  1. Git的概念模型纯粹基于快照.快照可以存储为其他快照的差异,只是差异纯粹用于存储优化.- 拉法洛·道格尔德的评论
• 从非技术角度来看:
  1. 它只是文化:如果合并困难,DVCS根本不会工作,因此DVCS开发人员投入大量时间和精力使合并变得容易.CVCS用户OTOH习惯于糟糕的合并,因此开发人员没有动力让它工作.(为什么当你的用户为你的垃圾付出​​同样的代价时能做些好事？)
     ......
     回顾一下:DVCS的重点是拥有许多分散的存储库并不断地来回合并变化.如果没有良好的合并,DVCS根本就没用.然而,CVCS仍然可以通过糟糕的合并来生存,特别是如果供应商可以调整其用户以避免分支.- JörgWMittag的回答
• 从技术角度来看:
  1. 录制真实DAG的历史确实有帮助!我认为主要区别在于CVCS并不总是将合并记录为与几个父母的变更集,从而丢失了一些信息.- tonfa的评论
  2. 因为合并跟踪,以及每个修订都知道其父母的更基本的事实....当每个修订(每次提交),包括合并提交,知道其父项(对于合并提交,意味着拥有/记住多个父项,即合并跟踪),您可以重建图(DAG =直接非循环图)的修订历史.如果您知道修订图,则可以找到要合并的提交的共同祖先.当您的DVCS知道如何找到共同的祖先时,您不需要将其作为参数提供,例如在CVS中.
     .
     请注意,两个(或更多)提交可能有多个共同的祖先.Git利用所谓的"递归"合并策略,它合并了合并基础(共同的祖先),直到你留下一个虚拟/有效的共同祖先(在一些简化中),并且可以做简单的3路合并.- JakubNarębski的回答

检查在Git中合并和/或为什么在SVN中的合并更好？

Answer 1

在DVCS中没有什么特别的东西可以让合并变得更容易.它只是文化:如果合并困难,DVCS 根本不会工作,因此DVCS开发人员投入大量时间和精力使合并变得容易.CVCS用户OTOH习惯于糟糕的合并,因此开发人员没有动力让它工作.(为什么当你的用户同样为某些垃圾支付你的费用时,能做些好事？)

Linus Torvalds在他的一个Git谈话中说,当他在Transmeta使用CVS时,他们在合并的开发周期中留出了整整一周的时间.而且每个人都认为这是正常的事态.如今,在合并窗口期间,Linus在短短几个小时内完成了数百次合并.

如果CVCS用户只是去他们的供应商并说这个垃圾是不可接受的,那么CVCS可以和DVCS一样具有良好的合并能力.但他们陷入了Blub悖论:他们根本不知道这是不可接受的,因为他们从未见过一个有效的合并系统.他们不知道那里有更好的东西.

而当他们做尝试了DVCS,他们奇迹般地属性中的所有善良的"d"的一部分.

从理论上讲,由于集中性,CVCS应该具有更好的合并能力,因为它们具有整个历史的全局视图,不像DVCS,每个存储库只有一个小片段.

总括来说:在整点一DVCS的是有很多分散的资源库,不断合并更改来回.如果没有良好的合并,DVCS根本就没用.然而,CVCS仍然可以通过糟糕的合并来生存,特别是如果供应商可以调整其用户以避免分支.

所以,就像软件工程中的其他一切一样,这是一个努力的问题.

Answer 2

在Git和其他DVCS合并很容易,因为一些神秘的变更集系列视图(除非你使用Darcs,其补丁理论,或者一些Darcs启发的DVCS;它们是少数,但是)Joel讨论,但是因为的合并跟踪,而且更根本的事实,每一个版本都知道其父母.为此,您需要(我认为)整个树/完整存储库提交...但遗憾的是,它限制了部分检出的能力,并且只提交了文件子集.

当每个版本(每次提交),包括合并提交,知道它的父母(对于合并提交,这意味着有/记忆多个父,即合并跟踪),你可以重建修订历史记录的图(DAG =向无环图).如果您知道修订图,则可以找到要合并的提交的共同祖先.当您的DVCS知道如何找到共同的祖先时,您不需要将其作为参数提供,例如在CVS中.

请注意,两个(或更多)提交可能有多个共同的祖先.Git的利用所谓的"递归"合并策略,其合并合并基地(共同的祖先),直到你留下了一个虚拟的/有效的共同祖先(在某些简化),并且可以做简单的3路合并.

创建了Git使用重命名检测,以便能够处理涉及文件重命名的合并.(这支持JörgWMittag的论点,即DVCS有更好的合并支持,因为他们必须拥有它,因为合并比CVCS更常见,其合并隐藏在'update'命令中,在update-then-commit工作流中,参见了解版本控制(WIP)由Eric S. Raymond完成.

Answer 3

部分原因当然是技术论证,即DVCS存储的信息比SVN更多(DAG,副本),并且还有一个更简单的内部模型,这就是为什么它能够执行更准确的合并,如其他响应中所述.

然而,可能更重要的区别在于,因为您拥有本地存储库,所以您可以进行频繁的小型提交,并且还经常提取和合并传入的更改.这更多地是由"人为因素"造成的,人类使用集中式VCS与DVCS的方式不同.

使用SVN,如果您更新并且存在冲突,SVN将合并它可以并在您的代码中插入不能的标记.与此相关的一个重大问题是,在解决所有冲突之前,您的代码现在将不再处于可行状态.

这会使您分散您正在尝试实现的工作,因此通常SVN用户在处理任务时不会合并.将此与SVN用户也倾向于让更改在单个大型提交中累积以避免破坏其他人的工作副本这一事实相结合,并且在分支和合并之间将存在大量时间.

使用Mercurial,您可以在较小的增量提交之间更频繁地合并传入的更改.根据定义,这将导致较少的合并冲突,因为您将处理更新的代码库.

而如果有原来是一个冲突,你可以决定推迟合并,并在自己的闲暇做.这尤其使合并变得不那么烦人.

Answer 4

哇,攻击5段散文!

简而言之,没有什么比这更容易.这很难,我的经验表明确实发生了错误.但:

• DVCS强制您处理合并,这意味着花几分钟时间熟悉一下可以帮助您的工具.仅此一点有帮助.

• DVCS鼓励您经常合并,这也有帮助.

您引用的hginit片段声称Subversion无法进行三向合并,并且Mercurial通过查看两个分支中的所有变更集进行合并,这两个方面都是错误的.