SVN支持历史合并，那么Mercurial有什么优势呢？
SVN支持历史合并，那么Mercurial有什么优势呢？
你好，
我是一个长期使用SVN的用户，并且一直听说关于Mercurial和分布式版本控制系统的种种争议。我所了解的主要宣传特点是Mercurial中的合并更容易，因为它记录了每次合并的信息，所以每次连续的合并都能知道之前的合并情况。
现在，正如《红宝书》中所述，在合并部分，SVN已经通过mergeinfo支持了这一点。虽然我实际上没有使用过这个功能（尽管我想使用，但我们的仓库版本不够新），但这个SVN的功能和Mercurial提供的功能有什么特别不同吗？
对于不了解历史合并的人，SVN中的建议工作流程如下：
- 从开发主干创建分支，进行自己的工作。
- 定期将主干的变更合并到你的分支，以保持最新。
- 使用合并信息在完成后将分支合并回主干，以平滑过程。
如果没有历史数据合并，这将是一场噩梦，因为比较严格基于文件的差异，而不考虑过程中的步骤。因此，每次开发主干的变更在合并回去时都可能导致更多的冲突。
现在我想知道的是：
与SVN中的mergeinfo相比，使用Mercurial进行合并是否提供了明显的优势，还是只是一场无关紧要的大惊小怪？
有人使用过SVN中的mergeinfo功能吗？实际上它的效果如何？
SVN支持历史合并，那么为什么Mercurial更好呢？
SVN的文档中明确指出了合并的限制。一旦从分支到主干进行了--reintegrate合并，该分支将无法再进行进一步的工作。它无法正确吸收新的主干变更，也无法正确地再次合并到主干中。
如果在上次合并回主干后还在该分支上进行了更多工作，那么就无法进行第二次--reintegrate合并。必须创建另一个分支或使用带有另一选项的拣选语法来保持其可用性。
Subversion的合并跟踪功能具有极其复杂的内部实现，而svn:mergeinfo属性是用户对此内部实现的唯一窗口。由于该功能相对较新，可能会出现许多边缘情况和可能的意外行为。
此外，合并信息元数据的管理还涉及一整套分类和行为，例如“显式”与“隐式”合并信息、“有效”与“无效”修订版本，合并信息“省略”的特定机制，甚至是从父目录到子目录的“继承”。
与此相比，分布式版本控制系统（DVCS）中的合并操作更加简单。这意味着SVN并不不懂得如何合并（对于简单的合并工作流程，它可以完成任务），但其底层机制的复杂性会限制分支和合并的使用，使得剩下的合并变得相对简单。
相比之下，DVCS中合并操作的简便性将增加分支的使用和合并场景的复杂性，这些都不再是问题。