是什么让一些版本控制系统更擅长合并? [英] What makes some version control systems better at merging?

问题描述

我听说许多分布式 VCS(git、mercurial 等)比 Subversion 等传统 VCS 更擅长合并.这是什么意思?他们做了哪些事情来使合并更好?这些事情可以在传统的 VCS 中完成吗?

额外问题:SVN 1.5 的合并跟踪是否完全符合竞争环境?

解决方案

大多数答案似乎都是关于 Subversion，所以这里有一个关于 Git(和其他 DVCS)的答案.

在分布式版本控制系统中，当您将一个分支合并到另一个分支时，您会创建新的合并提交，它会记住您如何解决合并，并记住合并的所有父项.在 1.5 版之前的 Subversion 中根本没有这些信息；为此，您必须使用其他工具，例如 SVK 或 svnmerge.在进行重复合并时，此信息非常重要.

由于这些信息，分布式版本控制系统 (DVCS) 可以自动找到任何两个分支的共同祖先(或共同祖先)，也称为合并基础.看看下面的 ASCII-art 修订图(我希望它没有被严重破坏)，

<前>---O---*---*----M---*---*---1/ - -* - -A2

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

分布式版本控制系统必须做得对，即他们必须从一开始就让合并变得非常容易(无需标记/标记合并父项，并手动提供合并信息)，因为这是获取其他人的方式将代码放入项目并不是授予他/她的提交访问权限，而是从他/她的存储库中提取:从另一个存储库获取提交并执行合并.

您可以在 Subversion 1.5 中找到有关合并的信息.在 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屋！