svn - 是什么使DVCS中的 merge 变得容易？

我在Joel on Software上阅读:



并在HgInit:



通过查看SVN的存储库文件夹，我的印象是Subversion将每个修订都保留为变更集。据我所知，Hg同时使用变更集和快照，而Git仅使用快照来存储数据。

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

*更新:

我对技术 Angular 更感兴趣，但是从非技术 Angular 来看的答案是可以接受的

更正:

Git的概念模型完全基于快照。快照可以作为其他快照的差异存储，只是差异仅用于存储优化。 – Rafał Dowgird的comment

从非技术 Angular 来看:

这只是一种文化:如果合并困难，DVCS根本无法工作，因此DVCS开发人员投入了大量时间和精力来简化合并。 CVCS用户OTOH习惯了糟糕的合并，因此开发人员没有动力使其工作。 (为什么当您的用户为您的产品付钱时，您却付出了同样的价钱？)
...
回顾一下:DVCS的重点是拥有许多分散的存储库，并不断地来回合并更改。如果没有良好的合并，DVCS就毫无用处。但是，CVCS仍然可以在糟糕的合并中幸存下来，特别是在供应商可以限制其用户避免分支的情况下。 – Jörg W Mittag的answer

从技术 Angular 来看:

记录真实DAG历史记录确实有帮助!我认为主要的区别在于CVCS并不总是将合并记录为变更集并包含多个父级，从而丢失了一些信息。 – tonfa的comment

是因为合并跟踪，而更基本的事实是每个修订版都知道其父级。 ...当每个修订(包括合并提交)的每个修订(包括合并提交)都知道其父级(对于合并提交意味着拥有/记住多个父级，即合并跟踪)时，您可以重建修订图(DAG =直接非循环图)历史。如果您知道修订图，则可以找到要合并的提交的共同祖先。而且，当您的DVCS知道如何来查找共同祖先时，您就不需要提供它作为参数，例如在CVS中。
。
请注意，两个(或更多)提交中可能有一个以上的共同祖先。 Git使用所谓的“递归”合并策略，该策略合并合并基础(公共(public)祖先)，直到您剩下一个虚拟/有效的公共(public)祖先(以某种简化方式)，并且可以执行简单的三向合并。 – Jakub Narębski的answer

还要检查How and/or why is merging in Git better than in SVN?

最佳答案

在Git和其他DVCS中合并不是一件容易的事，这并不是因为Joel徘徊了一些神秘的系列变更集 View (除非您使用具有补丁理论的Darcs或某些Darcs启发的DVCS；它们是少数派)，但是由于合并跟踪，并且更基本的事实是每个修订版都知道其父级。为此，您需要(我认为)整个树/完整存储库提交...不幸的是，这限制了执行部分 check out 以及仅对文件子集进行提交的能力。
当每个修订(每个提交)(包括合并提交)知道其父代(对于合并提交意味着拥有/记住多个父代，即合并跟踪)时，您可以重建修订历史记录的图表(DAG =直接非循环图)。如果您知道修订图，则可以找到要合并的提交的共同祖先。而且，当您的DVCS知道如何来查找共同祖先时，您就不需要提供它作为参数，例如在CVS中。
请注意，两个(或更多)提交中可能有一个以上的共同祖先。 Git使用所谓的“递归”合并策略，该策略合并合并基础(公共(public)祖先)，直到您剩下一个虚拟/有效的公共(public)祖先(以某种简化方式)，并且可以执行简单的三向合并。
Git使用重命名检测是为了能够处理涉及文件重命名的合并而创建的。 (这支持Jörg W Mittag的论点，即DVCS具有更好的合并支持，因为他们必须拥有DVt，因为合并比CVCS更为常见，合并隐藏在'update'命令中，在update-then-commit工作流中，参见Understanding Version Control(WIP) (埃里克·雷蒙德)。