与SVN中的私有分支相比，Mercurial
假设一分钟，SVN中的分支/合并支持与Mercurial一样好.
Assume for a minute that the branch/merge support in SVN is as good as in Mercurial.
一方面考虑一个SVN系统，人们总是在自己的私有分支中工作，然后在合适的时候将其私有分支合并到主"分支(或他们的父"分支发生的任何事情)中是).他们可以定期合并另一种方式来更新其私有分支.
Consider on the one hand a SVN system where people always work in their own private branches, and then when they are at a suitable point, merge their private branch into the "main" (or whatever their "parent" branch happens to be). Periodically they can merge the other way to get their private branch up to date.
然后，另一方面，考虑Mercurial建立的一个中央存储库，每个人随其选择的时间向其提交或撤出的自己的存储库中拉入/推入.
Then on the other hand consider the Mercurial set up of having a central repository and each person pulling and pushing to/from their own repository to which they commit as and when they choose.
因此，SVN中的私有分支对应于Mercurial中的本地存储库，而HG中的拉/推对应于SVN中的私有分支之间的合并.
So the private branch in SVN corresponds to the local repository in Mercurial and the pull/push in HG corresponds to merging to and from the private branch in SVN.
这是否不允许SVN实质上镜像此实例中设置的Mercurial?在这种情况下，Mercurial还有什么其他优势?
Does this not allow SVN to essentially mirror the Mercurial set up in this instance? What other advantages does Mercurial have in the scenario?
请注意，至少在我们拥有的SVN版本中，我的开场白-假设一会儿"是SVN模型对我们不利的地方.它将涉及的合并数量，尤其是主分支和私有分支之间来回合并将是冲突地狱.如果SVN像Mercurial一样擅长跟踪分支和合并，那会解决SVN中的问题吗?是最新的支持跟踪分支跟踪的SVN服务器代码吗?
Note that my opening sentence -- "assume for a moment" -- at least in the version of SVN we have, is where the SVN model falls down for us. The amount of merging that it would involve, and particularly the merging back and forward between the main branch and private branch would be conflict hell. If SVN were as good at tracking branches and merges as Mercurial, would that solve the issue in SVN? Is the latest SVN server code that supports tracking branch tracking up to that kind of use?
谢谢.
否，Subversion仍无法像Mercurial那样健壮地合并.我给出一个明确的示例，说明Subversion如何无法合并两个分支此答案.没有什么能阻止集中式系统擅长合并，只是在分散式系统中使用了太多分支，以至于它不得不擅长合并.
No, Subversion is still not able to merge as robustly as Mercurial. I give an explicit example of how Subversion fails to merge two branches this answer. There is nothing that prevents a centralized system from being good at merging, it is just that branches are used so much in a decentralized system that it is forced to be good at merging.
除合并支持外，Mercurial相对于Subversion的更大优势是分散版本控制的灵活性:
Apart from the merge support, the bigger advantage of Mercurial over Subversion is the flexibility of decentralized version control:
-
您可以先进行许多小的提交，然后再进行
hg rebase --collapse将它们组合成更大更好的提交，然后再将它们推向世界.
You can make many small commits and then do
hg rebase --collapseto combine them into a bigger and better commit before you push them to the world.
您可以使用 MQ扩展或
You can use the MQ extension or the rebase extension to refine changesets before you publish them.
您可以安全地进行承诺，然后改变主意并用hg strip或更安全的hg clone -r扔掉.
You can commit safely, and then change your mind and throw things away with hg strip or the more safe hg clone -r.
这使您可以更自由地进行实验，最终结果是Mercurial成为了支持性的安全网，而不是障碍.具有讽刺意味的是，诸如Subversion之类的工具最终会成为人们不使用的东西-他们因为担心破坏构建而几天不提交更改，并且因为被它们烧掉而不会使用分支.过去.
This lets you experiment more freely and the end result is that Mercurial becomes a supportive safety net instead of a hindrance. It's deeply ironic that tools like Subversion end up being something that people don't use -- they don't commit their changes for days because they are afraid of breaking the build, and they wont use branches because they've been burned by them in the past.
以上只是本地的灵活性-Mercurial还可以让您在存储库之间精心安排变更集的流程:您可以拥有一个存储库，由网闸管理员进行质量检查，仅在测试变更集后才能通过.分散模型中内置了这种灵活性.
The above were just local flexibility -- Mercurial also lets you orchestrate nice flows of changesets between repositories: you can have a repository where a gate keeper does QA and only lets changesets through after testing them. That kind of flexibility is built into the decentralized model.