分布式版本控制系统合并简单细节答案

【问题标题】：Distributed version control systems merge easiness details分布式版本控制系统合并简单细节
【发布时间】：2011-03-04 20:29:06
【问题描述】：

我刚刚阅读了 Joel 关于分布式版本控制系统的 blogpost，但无法理解主要思想。他说 SVN 考虑版本，而 Mercurial 考虑变化。而且，据 Joel 说，它解决了合并问题。

我多次听到这个想法，但仍然没有想到它。据我所知，SVN 的合并机制也是基于更改（差异）。那么区别是什么呢？我没有分布式版本控制系统的经验，但我积极使用 SVN 分支/合并并且没有严重的问题。当然有时会出现合并冲突（当两个分支中的一段代码都被更改时）。但我看不出有什么办法可以通过某种控制版本系统自动解决这个问题。

【问题讨论】：

不同之处在于现代 DVCS 记录了完整的 DAG 变化，而 afaik svn 只记录线性历史（或树）并且不能正确记录合并。
见stackoverflow.com/questions/2613525/…，以及stackoverflow.com/questions/2850996/…中提到的其他链接
乔尔的解释不正确。正如 tonfa 所说，这里的关键思想是在现代 DVCS 中使用 DAG 修订版。
Subversion 从 1.5 版开始记录合并。问题不在于是否使用 DAG，真正的问题是 Subversion 在它的合并实现中存在长期存在的错误。看到这个答案：stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/…

标签： svn mercurial dvcs version-control

【解决方案1】：

我会将 SVN 与 Mercurial 进行比较，因为这是迄今为止我使用过的唯一 DVCS。 SVN 使用文件并为每个下一个版本制作每个文件的副本，而 Mercurial 则组装变更集。您在 SVN 中拥有完整的文件版本 1.0，并且您拥有完整文件版本 1.1 的另一个副本。在 Mercurial 中，您在 1.0 版中拥有完整的文件。然后你有一个规则，比如“在此处添加 2 行并在此处删除 3 行”来生成 1.1 版。 Mercurial 遍历整个历史记录并在更新期间将更改应用到您的本地副本，但它不会将您的完整文件版本 1.1 存储在任何地方。

但是，您描述的问题在 Mercurial 中也没有从技术上解决。我尝试了一个非常简单的例子：让两个人在同一个文件的末尾同时添加一行。第一个提交和推送没有问题。第二个需要先拉取和更新，以获取最新的更改。这是一个合并冲突，这很烦人！ Mercurial 不知道第二个人是要多加一行还是要修改该行，只是第一个人添加的。它和这里的 SVN 一样 - 你必须手动合并......所以，根本没有魔法:)

您可以阅读http://hginit.com/ 了解更多信息。

【讨论】：

您的答案的第一部分在技术上是不正确的。 SVN 只存储差异（“在此处添加 2 行，在此处删除 3 行”），就像 Mercurial 一样。 SVN 存储非常高效。这其实是 Mercurial 和 SVN 的共同点之一。

【解决方案2】：

您所说的 SVN 是 Subversion 无法处理某种树冲突，并且合并将失败。与 git、hg 和 bzr 相比，真正的 git、hg 或 bzr 可以处理这些情况，SVN 目前不能。我建议阅读有关已制作的bachelor study，当然同时其中一些问题已得到解决。

【讨论】：