什么让一些版本控制系统更好地融合？ [英] What makes some version control systems better at merging?

问题描述

我听说许多分布式VCS（git，mercurial等）比Subversion等传统的更好。这是什么意思？他们做了什么样的事情来使合并更好？这些事情可以在传统的VCS中完成吗？

奖金问题：SVN 1.5的合并跟踪级别是否是比赛场地？$ b $大多数答案似乎都是关于Subversion的，所以这里有一个关于Git（和其他DVCS）的例子。

在分布式版本控制系统中，当您将一个分支合并到另一个分支时，您将创建新的合并提交，它记住您如何解决合并问题，记得所有合并的父母。这个信息在版本1.5之前的Subversion中是缺乏的;你必须使用其他工具，如SVK或svnmerge。这些信息在进行重复合并时非常重要。

由于这些信息，分布式版本控制系统（DVCS）可以自动查找共同的祖先（或共同的祖先），也称为合并基地，任何两个分支。看看下面修订版的ASCII艺术图（我希望它没有太可怕的损坏），

 
 --- O --- * --- * ---- M --- * --- * --- 1 
 \ / 
 \ --- * --- A /  - * ---- 2 
 
 

如果我们想把分支'2'合并到分支'1'中，共同的祖先我们想用来生成合并将版本（提交）标记为'A'。但是，如果版本控制系统没有记录关于合并父母的信息（'M'是先前合并相同分支），它将无法找到提交'A'，并且它会找到提交'O'作为共同的祖先（合并基础）而不是......这会重复已经包含的变化并导致大的合并冲突。

分布式版本控制系统必须做到这一点，即他们必须从一开始就非常容易地进行合并（不需要标记/标记合并父母，并且手动提供合并信息），因为让别人将代码移植到项目中的方式不是为了让他/她提交提交，但要从他/她的存储库中提取：从其他存储库获取提交并执行合并。

您可以在Subversion 1.5中找到有关合并的信息。在。需要注意的问题：您需要不同的（！）选项来将分支合并到主干中，而不是将主干合并到分支中，也就是说。并非所有的分支机构都是平等的（在分布式版本控制系统中，它们[通常]在技术上相同）。

I've heard that many of the distributed VCSs (git, mercurial, etc) are better at merging than traditional ones like Subversion. What does this mean? What sort of things do they do to make merging better? Could those things be done in a traditional VCS?

Bonus question: does SVN 1.5's merge-tracking level the playing field at all?

解决方案

Most answers seems to be about Subversion, so here you have one about Git (and other DVCS).

In distributed version control system when you merge one branch into another, you create new merge commit, which remembers how you resolved a merge, and remembers all parents of a merge. This information was simply lacking in Subversion prior to version 1.5; you had to use additional tools such as SVK or svnmerge for this. This information is very important when doing repeated merge.

Thanks to this information distributed version control systems (DVCS) can automatically find common ancestor (or common ancestors), also known as merge base, for any two branches. Take a look at ASCII-art diagram of revisions below (I hope that it didn't got too horribly mangled),

---O---*---*----M---*---*---1
     \                /
       \---*---A/--*----2

If we want to merge branch '2' into branch '1', the common ancestor we would want to use to generate merge would be version (commit) marked 'A'. However, if version control system didn't record information about merge parents ('M' is previous merge of the same branches), it wouldn't be able to find that is commit 'A', and it would find commit 'O' as common ancestor (merge base) instead... which would repeat already included changes and result in large merge conflict.

Distributed version control system had to do it right, i.e. they had to make merge very easy (without needing to mark/tag merge parents, and supply merge information by hand) from the very beginning, because the way to get somebody else to get code into project was not to give him/her commit access, but to pull from his/her repository: get commits from the other repository and perform a merge.

You can find information about merging in Subversion 1.5. in Subversion 1.5 Release Notes. Issues of note: you need different (!) options to merge branch into trunk than merge trunk into branch, aka. not all branches are equal (in distributed version control systems they are [usually] technically equivalent).

这篇关于什么让一些版本控制系统更好地融合？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！