dvcs（git / mercurial）如何分支和合并支持比svn更好？

Question

许多关于dvcs系统的文章声称优越的分支和合并支持是从svn迁移到dvcs系统的一个原因。这些系统究竟是如何以不同的方式进行分支和合并以使其更好？

Answer 1

从历史上看，git和svn中合并跟踪的区别在于：git具有合并跟踪功能，直到版本1.5，svn没有。完全没有。如果要进行合并，则必须始终准确指定要合并的更改，如果您将一个分支合并到另一个分支中，则必须手动跟踪哪些修订已经合并，但尚未合并，并手动选择尚未合并的更改，以避免冲突。祝你好运，如果你曾经挑选过任何变化。

从版本1.5（2008年发布）开始，如果您的客户端，服务器和存储库都是最新的，那么svn能够更智能地执行操作;它使用属性来跟踪分支的来源以及已经合并到其中的更改。结果是，在许多情况下，你可以svn merge BRANCHNAME并且正确的事情发生。但由于它的“狂奔”性质，它仍然不是很快而且not entirely robust。另一方面，Git因为其DVCS特性而具有来处理合并场景，并且它从一开始就设计了数据结构（如它使用的特定类型的DAG）和算法（例如作为适合任务的递归合并和章鱼合并。

Answer 2

与流行的看法相反，差异不是由于DVCS的分布式特性，而是Subversion的集中模型。集中式模型中没有任何固有的东西需要分支和合并将是不合格的。

我认为Subversion通过决定在单个统一的目录树中建模基于代码库的目录结构，分支和标记（以及所有其他代码管理模式）来实现大规模的设计失态，这使得问题可靠如果分支在模型中是明确的，那么检测分支活动的难度就会大一百倍。

Answer 3

不要忘记任何版本控制系统的人体组件。今天早些时候，我创建并删除了3个不同的本地git分支，因为这是在主分支上完成清理问题的破坏性最小的方法。尝试使用集中版本控制，如果你甚至有权使用它，你很可能会从服务器管理员或愤怒的电子邮件风暴中得到一个演讲。您可以在私人仓库中拥有分支这一事实消除了有效使用分支的许多文化障碍。集中式系统使用的算法正在赶上DVCS。那些人为因素将继续存在。

Answer 4

来自Joel's hginit：

  

这是区别。设想   你和我正在研究一些代码，   我们分支代码，我们分别   进入我们独立的工作区   并做了很多很多改动   那个代码是分开的，所以他们有   分歧很大。

     

当我们必须合并时，Subversion   试图看看这两个修订 - 我的   修改过的代码，并修改了   代码 - 它试图猜测如何   在一个大的邪恶中将他们粉碎在一起   一塌糊涂。它通常会失败，产生   “合并冲突”的页面和页面   简单来说，这不是真正的冲突   Subversion失败的地方   弄清楚我们做了什么。

     

相比之下，我们在工作的时候   Mercurial分别在Mercurial   忙于保持一系列变更。   所以，当我们想要合并我们的代码时   在一起，Mercurial实际上有一个   更多信息：它知道   我们每个人都改变了，能做什么   重新应用这些变化，而不是   只看最终产品和   试图猜测如何把它   在一起。

Answer 5

SVN中的分支或标记仅仅是将特定目录及其子目录复制到同一存储库中的另一个位置。在git中，分支（和标签）被描述为元数据（非常类似于CVS），除了它不会将所有这些数据都放在一个文件中，而是多个（允许更快的更新，因为你不必重写一个巨大的“foo.c，v”例如）。此外，git大量使用指针。 （http://eagain.net/articles/git-for-computer-scientists/）所以事实上，当事情发生变化时（例如提交），很少有人更新。

Answer 6

不同之处在于大多数DVCS使用的存储库格式 - 定向Acylic图。

SVN只会将您的历史存储在一系列行中，每行都有自己的行。但是DVCS会将其存储在DAG中，该DAG包含更好的合并信息。