假设SVN中的分支/合并支持与Mercurial一样好。
一方面考虑SVN系统，人们总是在他们自己的私人分支中工作，然后当他们处于合适的位置时，将他们的私有分支合并到“主”（或者他们的“父”分支发生的任何地方）是）。他们可以定期合并另一种方式让他们的私人分支更新。
然后另一方面考虑Mercurial建立一个中央存储库，并且每个人都在拉动和推送他们自己的存储库以及他们选择时提交的存储库。
因此SVN中的私有分支对应于Mercurial中的本地存储库，HG中的pull / push对应于SVN中私有分支的合并。
这是否允许SVN基本上镜像此实例中的Mercurial设置？ Mercurial在场景中还有哪些其他优势？
请注意，我的开头句 - “暂时假设” - 至少在SVN的版本中，是我们的SVN模型。它将涉及的合并量，特别是主要分支和私人分支之间的合并后退和前进将是冲突地狱。如果SVN擅长跟踪分支并合并为Mercurial，那会解决SVN中的问题吗？最新的SVN服务器代码是否支持跟踪分支跟踪以达到这种用途？
感谢。
答案 0 :(得分：3)
不，Subversion仍然无法像Mercurial那样强大地合并。我给出了Subversion如何合并两个分支this answer的明确示例。没有任何东西阻止集中式系统善于合并，只是在分散的系统中使用分支以至于它被迫善于合并。
除合并支持外，Mercurial对Subversion的更大优势是分散版本控制的灵活性：
您可以进行许多小型提交，然后hg rebase --collapse将它们组合成更大更好的提交，然后再将它们推向世界。
您可以在发布变更集之前使用MQ extension或rebase extension优化变更集。
您可以安全地投入，然后通过hg strip或更安全的hg clone -r改变主意并扔掉一些东西。
这使您可以更自由地进行实验，最终结果是Mercurial成为支持性的安全网而不是障碍。具有讽刺意味的是，像Subversion这样的工具最终会成为人们不会使用的东西 - 他们几天都没有提交更改，因为他们害怕打破构建，他们不会使用分支，因为他们已被他们烧毁在过去。
以上只是本地灵活性 - Mercurial还允许您在存储库之间编排好的变更集流：您可以拥有一个存储库，其中一个守门员执行QA，并且只有在测试它们之后才允许更改集。这种灵活性是内置于分散模型中的。
答案 1 :(得分：2)
另一个值得关注的问题是开发人员不愿意在subversion中提交半生不熟的代码，即使它是私有分支，因为他们的不完整性对他们的同行是可见的。在集中式版本控制系统中，提交优秀工作代码的同行压力非常大。这导致不经常的提交，这些化合物合并了更大的合并问题。
在DVCS中，开发人员可以对其代码执行任何操作，并且仍然可以执行提交，因为在推送更改之前，没有其他人会了解更改。他们有进行实验的特权，从而提高了代码的生产力和效率，因为他们所做的任何事情都可以恢复。