为什么在 Mercurial 中分支和合并比在 Subversion 中更容易? [英] Why is branching and merging easier in Mercurial than in Subversion?

问题描述

在 Subversion 或 CVS 中处理多个分支合并只是必须经历的事情之一.在 Mercurial(可能还有任何其他分布式系统)中跟踪分支和合并要容易得多，但我不知道为什么.还有人知道吗?

Handling multiple merges onto branches in Subversion or CVS is just one of those things that has to be experienced. It is inordinately easier to keep track of branches and merges in Mercurial (and probably any other distributed system) but I don't know why. Does anyone else know?

我的问题源于这样一个事实，即使用 Mercurial，您可以采用类似于 Subversions/CVS 中央存储库的工作实践，并且一切都会正常进行.您可以在同一个分支上进行多次合并，而且您不需要无休止的带有提交编号和标签名称的纸屑.

My question stems from the fact that with Mercurial you can adopt a working practice similar to that of Subversions/CVSs central repository and everything will work just fine. You can do multiple merges on the same branch and you won't need endless scraps of paper with commit numbers and tag names.

我知道最新版本的 Subversion 能够跟踪合并到分支的情况，因此您不会遇到同样程度的麻烦，但对他们来说这是一个巨大而重大的发展，但它仍然无法完成所有工作开发团队希望这样做.

I know the latest version of Subversion has the ability to track merges to branches so you don't get quite the same degree of hassle but it was a huge and major development on their side and it still doesn't do everything the development team would like it to do.

这一切的运作方式肯定有根本的不同.

There must be a fundamental difference in the way it all works.

推荐答案

在 Subversion(和 CVS)中，存储库是首要的.在 git 中并且 mercurial 中并没有真正的存储库的概念同样的方法;这里的变化是中心主题.

In Subversion (and CVS), the repository is first and foremost. In git and mercurial there is not really the concept of a repository in the same way; here changes are the central theme.

+1

CVS/SVN 的麻烦在于这些系统没有记住变化的父母身份.在 Git 和 Mercurial 中，一个提交不仅可以有多个子项，还可以有多个父母！

The hassle in CVS/SVN comes from the fact that these systems do not remember the parenthood of changes. In Git and Mercurial, not only can a commit have multiple children, it can also have multiple parents!

使用其中一种图形工具 gitk 或 hg 可以很容易地观察到查看.在以下示例中，分支 #2 是从 #1 分叉出来的提交 A，此后已合并一次(在 M 处，与提交 B 合并):

That can easily observed using one of the graphical tools, gitk or hg view. In the following example, branch #2 was forked from #1 at commit A, and has since been merged once (at M, merged with commit B):

o---A---o---B---o---C         (branch #1)
            
      o---o---M---X---?       (branch #2)

注意 A 和 B 有两个孩子，而 M 有两个父母.这些关系记录在存储库中.假设维护者分支 #2 现在想要合并分支 #1 的最新更改，他们可以发出如下命令:

Note how A and B have two children, whereas M has two parents. These relationships are recorded in the repository. Let's say the maintainer of branch #2 now wants to merge the latest changes from branch #1, they can issue a command such as:

$ git merge branch-1

并且该工具会自动知道 base 是 B——因为它记录在提交 M 中，它是 #2 尖端的祖先——和它必须合并发生的一切B 和 C 之间.CVS 不记录此信息，SVN 之前也没有记录版本 1.5.在这些系统中，图看起来像:

and the tool will automatically know that the base is B--because it was recorded in commit M, an ancestor of the tip of #2--and that it has to merge whatever happened between B and C. CVS does not record this information, nor did SVN prior to version 1.5. In these systems, the graph would look like:

o---A---o---B---o---C         (branch #1)
         
      o---o---M---X---?       (branch #2)

其中 M 只是 A 和 B 之间发生的所有事情的巨大压扁"提交，应用在 M 之上.注意，契约完成后，没有任何痕迹离开(除了可能在人类可读的评论中)M 所做的起源于，也不是有多少次提交被折叠在一起——制作历史更加难以理解.

where M is just a gigantic "squashed" commit of everything that happened between A and B, applied on top of M. Note that after the deed is done, there is no trace left (except potentially in human-readable comments) of where M did originate from, nor of how many commits were collapsed together--making history much more impenetrable.

更糟糕的是，执行第二次合并变成了一场噩梦:人们必须弄清楚第一次合并时合并基础是什么(并且必须知道首先是合并！)，然后将该信息呈现给该工具，以便它不会尝试重播 A..BM 的顶部.当密切合作时，所有这些都足够困难，但是在分布式环境中根本不可能.

Worse still, performing a second merge becomes a nightmare: one has to figure out what the merge base was at the time of the first merge (and one has to know that there has been a merge in the first place!), then present that information to the tool so that it does not try to replay A..B on top of M. All of this is difficult enough when working in close collaboration, but is simply impossible in a distributed environment.

一个(相关的)问题是没有办法回答这个问题:X包含 B?" 其中 B 是一个潜在的重要错误修复.那么，为什么不只在提交中记录该信息，因为它在合并时已知！

A (related) problem is that there is no way to answer the question: "does X contain B?" where B is a potentially important bug fix. So, why not just record that information in the commit, since it is known at merge time!

P.-S.-- 我没有使用 SVN 1.5+ 合并录制功能的经验，但工作流程似乎要多得多比在分布式系统中更人为设计.如果确实如此，那可能是因为——正如前面提到的在上面的评论中——重点是存储库组织而不是更改本身.

P.-S. -- I have no experience with SVN 1.5+ merge recording abilities, but the workflow seems to be much more contrived than in the distributed systems. If that is indeed the case, it's probably because--as mentioned in the above comment--the focus is put on repository organization rather than on the changes themselves.

这篇关于为什么在 Mercurial 中分支和合并比在 Subversion 中更容易?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！