SVN 支持历史合并，那么 Mercurial 有何优势？

Question

可能的重复：
合并：hg/git 与 svn

你好，

我是 SVN 的长期用户并且已经听到了很多关于一般的善变和去中心化版本控制系统的争论。我知道的主要吹捧功能是 Mercurial 中的合并要容易得多，因为它记录每个合并的信息，因此每个连续的合并都知道以前的合并。

现在正如 红皮书 中所述，在与合并有关的部分中，SVN 已经支持此功能合并信息。现在我还没有真正使用过这个功能（虽然我想使用，但我们的 repo 版本还不够新），但是这个 SVN 功能与 Mercurial 提供的功能有什么特别不同吗？

对于那些不知道 svn 中历史合并的建议工作流程的人来说是这样的：

1. 从开发主干分支到 做你自己的事情。

2. 定期合并来自主干的更改 到您的分支以保持最新状态。

3. 完成后合并回来 mergeinfo 以使过程顺利进行。

如果没有历史数据合并，这将是一场噩梦，因为比较严格地针对文件中的差异，并且没有考虑途中采取的步骤。因此，开发主干中的每次更改都会使您在合并回来时进一步陷入可能的冲突。

现在我想知道的是：

与 SVN 中的 mergeinfo 相比，使用 Mercurial 进行合并是否提供了显着的优势，或者这只是一堆空话？

有人使用过 SVN 中的 mergeinfo 功能吗？它在实践中到底有多好？

Answer 1

正如评论中提到的，这个 SO 问题几乎概括了它，但值得指出确切的 Subversion（最新的 1.6！）文档，说明合并限制：

• 基本合并（原文如此）/重新集成分支：

    svn merge --reintegrate ^/branches/my-calc-branc

一旦从分支到主干完成了--reintegrate合并，该分支就不再可用于进一步的工作。它无法正确吸收新的主干更改，也无法再次正确地重新集成到主干。

什么？如果自上次合并回主干后您在该分支上做了更多工作，您就不能再进行第二次 --reintegrate 合并？
您必须创建另一个分支或使用 一种精挑细选的语法，还有另一个选项来保持它的活力。

• 高级合并

结论告诉您所需的一切知道：

底线是 Subversion 的合并跟踪功能具有极其复杂的内部实现，并且 svn:mergeinfo 属性是用户进入机器的唯一窗口。由于该功能相对较新，因此可能会出现许多边缘情况和可能的意外行为。

例如，有时运行简单的 svn copy 或 svn move 命令时会生成 mergeinfo。

• 有时合并信息会出现在您不希望被操作触及的文件上。
• 有时，当您期望时，合并信息根本不会生成。

此外，mergeinfo元数据的管理具有：

• 围绕它的一整套分类法和行为，例如“显式”与“隐式”合并信息、“有效”与“无效”修订，
• mergeinfo“省略”的具体机制，
• 甚至是从父目录到子目录的“继承”。

让我们将其与 DVCS 进行比较：

只需合并即可；）

这并不意味着 SVN 不知道如何合并（对于简单的合并工作流程，它会完成这项工作），但其底层机制的复杂性实际上会限制分支和合并的使用，使得少数合并变得相当微不足道。
相比之下，DVCS中合并操作的便利性会增加分支的使用和合并场景的复杂性，而这些都不再是问题。