Mercurial 与 SVN 中的私有分支机构的比较
假设 SVN 中的分支/合并支持与 Mercurial 中的一样好。
一方面考虑 SVN 系统，人们总是在自己的私有分支中工作，然后当他们处于合适的位置时，将他们的私有分支合并到“主”（或任何他们的“父”分支）。他们可以定期合并其他方式以使他们的私人分支保持最新状态。
另一方面，考虑一下 Mercurial 的设置，它有一个中央存储库，每个人都可以在自己选择的时间提交到自己的存储库，或者从他们自己的存储库中拉取和推送。
因此，SVN 中的私有分支对应于 Mercurial 中的本地存储库，HG 中的拉/推对应于 SVN 中私有分支的合并。
这是否不允许 SVN 本质上镜像本实例中设置的 Mercurial？ Mercurial在该场景中还有哪些优势？
请注意，我的开场白——“假设一下”——至少在我们现有的 SVN 版本中，是 SVN 模型对我们来说失败的地方。它所涉及的合并量，特别是主分支和私有分支之间的来回合并将是冲突地狱。如果 SVN 能像 Mercurial 一样擅长跟踪分支和合并，那么这能解决 SVN 中的问题吗？最新的支持跟踪分支跟踪的SVN服务器代码能达到那种用途吗？
谢谢。
Assume for a minute that the branch/merge support in SVN is as good as in Mercurial.
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.
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.
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.
Does this not allow SVN to essentially mirror the Mercurial set up in this instance? What other advantages does Mercurial have in the scenario?
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?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，Subversion 仍然无法像 Mercurial 那样强大地合并。我给出了一个明确的例子，说明 Subversion 如何无法合并两个分支这个答案。没有什么可以阻止中心化系统擅长合并，只是去中心化系统中分支使用过多，迫使它擅长合并。
除了合并支持之外，Mercurial 相对于 Subversion 的更大优势是分散版本控制的灵活性：
您可以进行许多小的提交，然后执行
hg rebase --collapse将它们组合成一个在将它们推向世界之前，先进行更大、更好的提交。您可以使用 MQ 扩展 或 rebase 扩展 在发布变更集之前对其进行优化。
您可以安全地提交，然后改变主意并使用
hg strip或更安全的hg clone -r扔掉东西。这让您可以更自由地进行实验，最终结果是 Mercurial 成为一个支持性的安全网，而不是一个障碍。具有讽刺意味的是，像 Subversion 这样的工具最终成为人们不使用的东西——他们好几天都不会提交更改，因为他们害怕破坏构建，并且他们不会使用分支，因为他们已经被分支烧毁了在过去。
以上只是本地灵活性——Mercurial 还允许您在存储库之间编排良好的变更集流：您可以拥有一个存储库，其中守门人进行 QA，并且仅在测试后才允许变更集通过。这种灵活性内置于去中心化模型中。
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.
Apart from the merge support, the bigger advantage of Mercurial over Subversion is the flexibility of decentralized version control:
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.You can use the MQ extension or the rebase extension to refine changesets before you publish them.
You can commit safely, and then change your mind and throw things away with
hg stripor the more safehg clone -r.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.
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.
另一个需要关注的问题是，即使是私有分支，开发人员也不愿意在 subversion 中提交半生不熟的代码，因为他们的不完整性会被同行看到。在集中式版本控制系统中，提交优秀工作代码的同行压力非常大。这会导致不频繁的提交，而复合会合并更大的合并问题。
在 DVCS 中，开发人员可以对他们的代码执行任何操作，但仍然会进行提交，因为在推送更改之前没有其他人会知道更改。他们有权进行实验，从而提高代码的生产力和效率，因为他们所做的任何事情都可以恢复。
Another issue to be concerned is the developers would feel reluctant to do a submit of half-baked code in subversion even if it is a private branch as their incompleteness would be visible to their peers. The peer pressure to submit great working code is very high in a centralized version control system. This leads to infrequent commits which compounds merge bigger merge issues.
In a DVCS developers can do anything with their code and still do a submit as no one else will come to know about the changes until the changes are pushed. They have the privileged of experimenting thereby increasing productivity and efficiency of code because anything they do can be reverted.