是什么让 DVCS 中的合并变得容易? [英] What makes merging in DVCS easy?

问题描述

我阅读了 Joel on Software:

通过分布式版本控制，分布式部分实际上不是最有趣的部分.

With distributed version control, the distributed part is actually not the most interesting part.

有趣的是，这些系统从变化的角度思考，而不是在版本方面.

The interesting part is that these systems think in terms of changes, not in terms of versions.

在 HgInit:

当我们必须合并时，Subversion试图查看两个修订版——我的修改过的代码，以及你修改过的代码——它试图猜测如何将它们粉碎成一个巨大的邪恶混乱.它通常会失败，产生合并冲突"的一页又一页这并不是真正的冲突，只是Subversion 失败的地方弄清楚我们做了什么.

When we have to merge, Subversion tries to look at both revisions—my modified code, and your modified code—and it tries to guess how to smash them together in one big unholy mess. It usually fails, producing pages and pages of "merge conflicts" that aren’t really conflicts, simply places where Subversion failed to figure out what we did.

相比之下，我们在工作时分别在 Mercurial 中，Mercurial 是忙于维护一系列变更集.所以，当我们想要合并我们的代码时总之，Mercurial 实际上有一个更多信息:它知道我们每个人都改变了什么并且可以重新应用这些更改，而不是只看最终产品和试图猜测如何放置它一起.

By contrast, while we were working separately in Mercurial, Mercurial was busy keeping a series of changesets. And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together.

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

By looking at the SVN's repository folder, I have the impression that Subversion is maintaining each revisions as changeset. And from what I know, Hg is using both changeset and snapshot while Git is purely using snapshot to store the data.

如果我的假设是正确的，那么一定有其他方法可以使合并 DVCS 变得容易.那些是什么?

If my assumption is correct, then there must be other ways that make merging in DVCS easy. What are those?

* 更新:

• 我对技术角度更感兴趣，但可以接受非技术角度的回答
• 更正:

1. Git 的概念模型完全基于快照.快照可以存储为其他快照的差异，只是差异纯粹是为了存储优化.– Rafał Dowgird 的 评论

1. Git's conceptual model is purely based on snapshots. The snapshots can be stored as diffs of other snapshots, it's just that the diffs are purely for storage optimization. – Rafał Dowgird's comment

从非技术角度:

From non-technical perspective:

1. 这只是文化上的问题:如果合并困难，DVCS 根本无法工作，因此 DVCS 开发人员会投入大量时间和精力来简化合并.CVCS 用户 OTOH 习惯于糟糕的合并，因此开发人员没有动力让它工作.(当您的用户为一些废话付给您同样好的报酬时，为什么还要制作一些好东西?)
   ...
   总结一下:DVCS 的全部意义在于拥有许多分散的存储库并不断地来回合并更改.如果没有良好的合并，DVCS 就毫无用处.然而，CVCS 仍然可以在糟糕的合并中存活下来，特别是如果供应商可以调整其用户以避免分支.– Jörg W Mittag 的 答案

从技术角度来看:

From technical perspective:

1. 记录历史的真实 DAG 确实有帮助！我认为主要区别在于 CVCS 并不总是将合并记录为多个父项的变更集，从而丢失了一些信息.– tonfa 的 评论
2. 因为合并跟踪，以及更基本的事实，即每次修订都知道其父项....当每个修订(每个提交)，包括合并提交，知道它的父级(对于合并提交意味着拥有/记住多个父级，即合并跟踪)，您可以重建修订图(DAG = Direct Acyclic Graph)历史.如果您知道修订图，您可以找到要合并的提交的共同祖先.当您的 DVCS 知道自己如何找到共同祖先时，您无需将其作为参数提供，例如在 CVS 中.
   .
   请注意，两个(或多个)提交可能有多个共同祖先.Git 使用所谓的递归"合并策略，它合并合并基础(共同祖先)，直到你只剩下一个虚拟/有效的共同祖先(在一些简化中)，并且可以进行简单的 3 路合并.– Jakub Narębski 的 答案

1. recording a real DAG of the history does help! I think the main difference is that CVCS didn't always record a merge as a changeset with several parents, losing some information. – tonfa's comment
2. because of merge tracking, and the more fundamental fact that each revisions knows its parents. ... When each revision (each commit), including merge commits, know its parents (for merge commits that means having/remembering more than one parent, i.e. merge tracking), you can reconstruct diagram (DAG = Direct Acyclic Graph) of revision history. If you know graph of revisions, you can find common ancestor of the commits you want to merge. And when your DVCS knows itself how to find common ancestor, you don't need to provide it as an argument, as for example in CVS.
   .
   Note that there might be more than one common ancestor of two (or more) commits. Git makes use of so called "recursive" merge strategy, which merges merge bases (common ancestor), till you are left with one virtual / effective common ancestor (in some simplification), and can the do simple 3-way merge. – Jakub Narębski's answer

同时检查如何以及/或者为什么在 Git 中合并比在 SVN 中合并要好?

推荐答案

在 Git 和其他 DVCS 中合并很容易，并不是因为一些神秘的变更集系列视图(除非您使用的是 Darcs，它的补丁理论，或一些受 Darcs 启发的 DVCS；虽然它们是少数)，乔尔漫不经心地谈论，但因为合并跟踪，以及更基本的事实>每个修订版都知道它的父母.为此，您(我认为)需要(我认为)整个树/完整存储库提交......不幸的是，这限制了进行部分签出以及仅提交文件子集的能力.

In Git and other DVCS merges are easy not because of some mystical series of changesets view (unless you are using Darcs, with its theory of patches, or some Darcs-inspired DVCS; they are minority, though) that Joel rambles about, but because of merge tracking, and the more fundamental fact that each revisions knows its parents. For that you need (I think) whole-tree / full-repository commits... which unfortunately limits ability to do partial checkouts, and making a commit about only subset of files.

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

When each revision (each commit), including merge commits, know its parents (for merge commits that means having/remembering more than one parent, i.e. merge tracking), you can reconstruct diagram (DAG = Direct Acyclic Graph) of revision history. If you know graph of revisions, you can find common ancestor of the commits you want to merge. And when your DVCS knows itself how to find common ancestor, you don't need to provide it as an argument, as for example in CVS.

请注意，两个(或多个)提交可能有多个共同祖先.Git 使用所谓的递归"合并策略，合并合并基(共同祖先)，直到只剩下一个虚拟/有效共同祖先(在某些简化中)，并且可以进行简单的三向合并.

Note that there might be more than one common ancestor of two (or more) commits. Git makes use of so called "recursive" merge strategy, which merges merge bases (common ancestor), till you are left with one virtual / effective common ancestor (in some simplification), and can the do simple 3-way merge.

重命名检测的 Git 使用是为了能够处理涉及文件重命名的合并.(这支持 Jörg W Mittag 论点，即 DVCS 有更好的合并支持，因为他们必须拥有它，因为合并比在 CVCS 中更常见，它的合并隐藏在更新"命令中，在更新然后提交工作流程中，参见 了解版本控制 (WIP) by Eric S. Raymond).

Git use of rename detection was created to be able to deal with merges involving file renames. (This supports Jörg W Mittag argument that DVCS have better merge support because they had to have it, as merges are much more common than in CVCS with its merge hidden in 'update' command, in update-then-commit workflow, c.f. Understanding Version Control (WIP) by Eric S. Raymond).

这篇关于是什么让 DVCS 中的合并变得容易?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！