当不再存在缺少元数据的情况时，v1.5之前的SVN中的合并带来的不便现在是否已经过时？

我开始使用SVN，因此有很多消息来源说，与DVCS工具相比，SVN中的合并非常困难。在最近的问题，我能找到这里SE是从2012年开始。

有时会提到原因是v1.5之前的SVN没有元数据，但是SVN现在是1.8.9版本。

鉴于SVN现在比v1.5更加成熟，尤其是我们没有使用SVN 1.5，所以我们不会因为提到的元数据不足而受苦- 这些反对SVN的论点是否仍然有足够的有效性？

我知道DVCS有一种完全不同的方法，通常更可取，但是对于出于某些原因“必须”使用SVN的用户，合并不再是真正的“地狱”，对吗？

如果您坚持简单的情况，它会很好地工作，但是有些复杂的情况则不然。

我能想到的限制：

• 它只能在所涉及的分支之一上找到最新的祖先。所以，如果你创建branches/this和branches/that无论从trunk再尝试合并branches/this到branches/that，它将不知道该怎么办。这意味着您只能将分支合并到父分支或从父分支合并。如果启动两个功能分支，然后意识到这些功能是相互依赖的并且需要将它们组合在一起，则可能会遇到这种情况。

• 尽管它声称可以跟踪重命名，但是当文件在一侧移动并在另一侧进行修改时合并分支并不一定总能找到正确的文件进行合并，因此手动修复它有些乏味，因为它不会在任何地方保留必要的信息。手。

• 添加的文件有时会在以后的合并中造成虚假冲突。

• 由于subversion没有单独的分支概念，因此您只能合并项目的子树，这会很快导致混乱。强烈建议务必始终合并完整的分支。不幸的是，由于某些原因，有时合并信息属性会出现在子目录上，即使它们看起来是多余的，并且合并也正确地对了整个分支。

• 最后但并非最不重要的是它很慢。合并任何规模的项目通常需要几分钟，而大多数DVCS可以在一秒钟内完成。

根据我的经验，在SVN中合并是在1.6版中“修复”的。我同时在Mercurial和SVN中工作，并且自SVN 1.6版以来，合并似乎在两个平台上的工作量几乎相同。一个例外可能是您必须记住--reintegrate在使用SVN从分支合并回主干时提供该选项。

这只是我的操作经验。我对SVN的内部一无所知。