是什么让一些版本控制系统更好地融合？

Question

我听说许多分布式VCS（git，mercurial等）在合并方面比Subversion等传统方式更好。这是什么意思？他们做了什么样的事情才能让合并变得更好？这些事情可以在传统的VCS中完成吗？

奖金问题：SVN 1.5的合并跟踪水平根本没有公平？

Answer 1

SVN的合并功能很不错，简单的合并方案也很好用 - 例如释放分支和主干，其中trunk跟踪RB上的提交。

更复杂的情况变得复杂得多。例如，让我们从稳定的分支（stable）和trunk开始。

您希望演示一项新功能，并希望将其基于stable，因为它比trunk更稳定，但您希望所有提交都传播到trunk此外，其他开发人员仍在stable修复内容并在trunk上开发内容。

因此，您创建了一个demo分支，合并图如下所示：

• stable -> demo -> trunk（你）
• stable -> trunk（其他开发者）

但是当您将stable中的更改合并到demo，然后将demo合并到trunk时会发生什么，而其他开发人员也在合并{{1}进入stable？ SVN混淆了trunk合并两次合并到stable。

有很多方法，但是使用git / Bazaar / Mercurial这根本不会发生 - 他们意识到提交是否已经合并，因为它们在合并路径中对每个提交进行ID识别。

Answer 2

大多数答案似乎是关于Subversion的，所以这里有一个关于Git（和其他DVCS）的内容。

在分布式版本控制系统中，当您将一个分支合并到另一个分支时，您可以创建新的合并提交，它会记住您如何解析合并，并且会记住合并的所有父级。在版本1.5之前的Subversion中缺少这些信息;你必须使用其他工具，如SVK或svnmerge。重复合并时，此信息非常重要。

由于这些信息，分布式版本控制系统（DVCS）可以自动为任何两个分支找到共同的祖先（或共同的祖先），也称为合并基础。看一下以下版本的ASCII-art图表（我希望它没有太可怕的损坏），

---O---*---*----M---*---*---1
     \                /
       \---*---A/--*----2

如果我们想将分支'2'合并到分支'1'中，我们想要用来生成合并的共同祖先将是标记为'A'的版本（提交）。但是，如果版本控制系统没有记录有关合并父项的信息（'M'是先前合并的相同分支），它将无法找到提交'A'，并且它将找到提交'O'作为共同的祖先（合并基础）而不是...这将重复已经包含的更改并导致大的合并冲突。

分布式版本控制系统必须做得正确，即他们必须从一开始就非常容易地进行合并（无需标记/标记合并父项，并手动提供合并信息），因为获取其他人的方式将代码导入项目不是为了提供他/她的提交访问权限，而是从他/她的存储库中提取：从其他存储库获取提交并执行合并。

您可以在Subversion 1.5中找到有关合并的信息。在Subversion 1.5 Release Notes。需要注意的问题：您需要不同的（！）选项将分支合并到主干，而不是合并主干到分支，也就是说。并非所有分支都相同（在分布式版本控制系统中，它们[通常]在技术上是等同的。）

Answer 3

1.5中的合并跟踪优于不合并跟踪，但它仍然是一个手动过程。我喜欢它记录哪些转速是和未合并的方式，但它没有接近完美的地方。

Merge在1.5中有一个很好的对话框。您可以选择要单独合并或整个分支的修订。然后，您可以触发本地发生的合并（并且需要FOREVER），然后为您提供一组要读取的文件。您需要在逻辑上检查每个文件的正确行为（最好通过文件的单元测试运行），如果您有冲突，则必须解决它们。一旦您高兴地提交了您的更改，那么该分支将被视为合并。

如果你是零敲碎打地做的话，SVN会记住你之前说的已经合并过的东西，允许你合并。我发现这个过程和一些合并的结果至少可以说是奇怪的......

Answer 4

这些版本控制系统可以做得更好，因为它们有更多信息。

SVN pre-1.5，以及最新一代之前的大多数VCS，实际上并不记得你在任何地方合并了两次提交。它记得这两个分支在它们第一次分支时共享一个共同的祖先方式，但它不知道可以作为共同基础的任何更近期的合并。

我对SVN帖子1.5一无所知，所以也许他们已经改进了。

Answer 5

轻率回答：为什么某些编程语言在文本/数学方面比其他语言更好？

真实答案：因为他们必须这样做。分布式VCS在很大程度上合并了冲突代码的作者都不能手动调整合并，因为合并是由第三方完成的。因此，合并工具具有以在大多数情况下正确使用它。

在与SVN的合同中，如果你最终合并了一些你没有写过一方或另一方的东西，那么你正在做一些时髦（并且错了吗？）。

IIRC大多数VCS可以将合并归结为你要求它们使用的任何东西，因此（理论上）没有任何东西阻止SVN使用GIT / mercurial合并引擎。 YMMV