与git或mercurial相比，svn中的合并有区别吗？

根据我的理解，SVN是“易于分支。合并困难”。这是为什么？它们如何合并有区别吗？

请参阅我的Stack Overflow答案，了解非常具体的情况，其中Mercurial（和Git）合并没有问题，并且Subversion给您带来虚假的冲突。这种情况是在重命名某些文件的分支上完成的简单重构。

关于tdammers的回答，那么那里存在许多误解：

• Subversion，Mercurial和Git都跟踪项目的整个存储库范围的快照。将它们称为版本，修订版或变更集没有区别。它们在逻辑上都是一组文件的原子快照。

• 合并时，提交的大小没有区别。所有这三个系统均使用标准三向合并算法合并，该算法的输入为

  • 最伟大的共同祖先版本
  • 一个分支上的版本
  • 其他分支上的版本

  这不要紧，怎么两个分支版本中创建。自祖先版本以来，您可以使用1000次小的提交，也可以使用1次提交。重要的是文件的最终版本。（是的，这很令人惊讶！是的，很多DVCS指南都犯了这个可怕的错误。）

他还提出了一些关于差异的要点：

• Subversion有一些“伏都教”，您可以在其中合并/trunk成/branches/foo。Mercurial和Git不使用此模型-分支直接在历史记录中建模。因此，历史记录变成有向无环图，而不是线性的。这个模型比Subversion使用的模型简单得多，并且省去了许多极端情况。

• 您可以轻松地延迟合并，甚至可以由其他人来处理。如果hg merge给您带来大量冲突，那么您可以要求您的同事hg pull与您联系，然后他就拥有完全相同的状态。因此他可以hg merge而且也许他比您更能解决冲突。

  这是在那里你需要更新的Subversion非常困难面前你可以提交。您不能只忽略服务器上的更改并继续在自己的匿名分支上进行提交。在一般情况下，颠覆的力量你玩弄一个肮脏的工作拷贝你的时候svn update。这是有风险的，因为您没有将更改存储在安全的地方。Git和Mercurial让您先提交，然后根据需要进行更新和合并。

Git和Mercurial比Subversion更好地合并的真正原因是实现方面的问题。即使很清楚正确的答案是什么，Subversion也无法解决重命名冲突。Mercurial和Git可以轻松处理这些问题。但是，没有理由说Subversion也不能处理这些问题-集中化当然不是原因。

核心问题在于这些系统表示版本化目录结构的方式。

Subversion整个系统围绕的基本概念是版本（或在svn术语中为“修订”）的概念：文件在特定点的快照。只要历史记录是完全线性的，就可以了，但是如果您需要合并两条独立开发线中的更改，svn必须比较两者的当前版本，然后在最后一个共享版本之间进行三向比较和两个头部版本。看起来很容易改变的线条可以很容易地解决，其中一个不会改变。在两个头上完全相同地偏离的线条较难，但通常是可行的；svn会说，以不同的方式偏离的行是“人类，我无法弄清楚，请帮我解决这个问题。”

相比之下，git和mercurial跟踪变更集而不是版本。整个存储库是一棵变更集树，每个变更集都取决于一个父集，其中一个父变更集可以具有任意数量的子代，并且树根表示一个空目录。换句话说，git / hg说“首先我什么都没有，然后应用了此补丁，然后再应用该补丁，等等”。当您需要合并两条开发线时，git / hg不仅知道当前每个头的外观以及上一个通用版本的外观，而且还知道过渡是如何发生的，从而可以进行更智能的合并。

使DVCS中的合并更容易的另一件事是将提交和推送的概念分开的间接结果，并且允许随时在同一存储库的任何两个克隆之间进行各种交叉合并。使用svn时，人们倾向于提交大型变更集，而这些变更集通常具有不相关的变更，因为提交也是中央存储库上的更新，会影响所有其他团队成员；如果您提交的版本不完整，每个人都会生您的气。由于大多数设置都涉及联网的svn服务器，因此提交还涉及通过网络泵送数据，这意味着提交会给工作流程带来相当大的延迟（尤其是当您的工作副本已过时且必须先拉时）。使用git和mercurial时，提交在本地进行，并且由于两者都非常有效地处理本地文件系统，因此通常会立即完成。结果，人们（一旦习惯了）就进行了微小的增量更改，然后在其生效时，一口气推十几次提交。然后，当合并时间到来时，SCM将获得更多详细信息，并可以更好地安全自动地解决冲突。

还有一些很棒的细节使事情变得更加容易：

• 您可以有多个脑袋，但仍然可以选择其中一个。与Subversion不同，您无需在再次提交之前合并pull，update和merge-多头保持不变，直到您选择合并
• 目录没有得到特别处理；相反，该路径仅被视为一个大文件名，并且所有目录都必须始终处于同一修订版本。这意味着您不能在项目的子文件夹处于不同修订版本的情况下进行Subversion伏都教，但这也意味着工作副本不太可能成为巨大的难以管理的混乱局面，更有趣的是，移动并不表示为删除-and-add（如果不是用于改型元数据，它将在svn中完全中断），而只是作为重命名；如果您移动文件，则将保留其整个历史记录；合并甚至可以将在移动后在另一个分支中对同一文件的非移动版本进行的更改应用于移动的文件
• 在大多数情况下，您实际上甚至不需要分支：相反，您只需克隆整个存储库即可。克隆很便宜，特别是如果它是在同一文件系统上完成的，并且如果您决定要摆脱克隆，则只需删除它所在的目录即可。您甚至不需要为此使用hg或git。
• 可以合并的内容几乎没有限制。您可以具有同一存储库的六个克隆，然后从A到B，然后从C到B，然后从B到D，再从C到D，然后从B合并（或者，推或拉；通常不需要显式合并）从A，D到E，随时随地进行。
• 您可以通过以下方式测试合并：克隆要合并的存储库之一，然后从另一个存储库中拉入。如果它满足您的要求，则可以将其推回实际目标；如果不满足要求，则可以丢弃该克隆并重新开始。