SVN 支持历史合并，那么 Mercurial 如何更好？ [复制]

Question

可能重复：
Merging: hg/git vs. svn

嗨，

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

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

对于任何不知道在 svn 中进行历史合并的建议工作流程是这样的：

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

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

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

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

现在我想知道的是：

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

有人在 SVN 中使用过 mergeinfo 功能吗？它在实践中的实际效果如何？

Answer 1

正如 cmets 中提到的，这个 SO 问题几乎总结了它，但它需要指出确切的 Subversion（1.6 最新！）文档说明合并限制：

• Basic Merging (sic) / Reintegrating a branch:

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

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

什么？如果自上次合并回主干后您确实在该分支上做了更多工作，您不能再进行第二次 --reintegrate 合并？
您必须创建另一个分支或使用 a cherry-picking syntax with yet 另一个选项才能使其保持活力。

• Advance merging

结论告诉你所有你需要知道的：

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

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

• 有时mergeinfo 会出现在您不希望被操作触及的文件上。
• 有时，mergeinfo 根本不会生成，而您期望它会生成。

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

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

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

已经合并了;)

这并不意味着 SVN 不知道如何合并（对于简单的merge workflow，它会完成这项工作），但其底层机制的复杂性实际上会限制分支和合并的使用，使得很少有合并留下相当微不足道的。
相比之下，DVCS中合并操作的便捷性会增加分支的使用率和合并场景的复杂度，这已经不是问题了。