为什么Mercurial中的分支和合并比Subversion更容易？
在Subversion或CVS中处理多个合并到分支机构中仅仅是必须经历的事情之一。 在Mercurial（可能是任何其他分布式系统）中跟踪分支和合并是非常容易的，但我不知道为什么。 其他人知道吗？
我的问题源于这样一个事实，即使用Mercurial，您可以采用与Subversions / CVS中央存储库相似的工作实践，并且一切都可以正常工作。 您可以在同一分支上进行多次合并，而且您不需要使用提交编号和标签名称的无尽纸片。
我知道最新版本的Subversion有能力跟踪分支合并，所以你没有得到相同程度的麻烦，但它是一个巨大的重大发展，它仍然没有做到开发团队所做的一切喜欢它做。
它们的工作方式必须有根本的区别。
在Subversion（和CVS）中，存储库首先是最重要的。 在git和mercurial中，存储库的概念实际上并没有相同的概念。 这里的变化是中心主题。
+1
CVS / SVN的麻烦来自于这些系统不记得变化的父母身份。 在Git和Mercurial中，不但可以有多个孩子，还可以有多个父母！
这可以很容易地使用图形工具之一， gitk或hg view 。 在以下示例中，分支＃2在提交A处从＃1分出，并且自此合并了一次（在M处，与提交B合并）：
o---A---o---B---o---C (branch #1)
o---o---M---X---? (branch #2)
注意A和B有两个孩子，而M有两个父母 。 这些关系记录在存储库中。 假设分支＃2的维护者现在想合并来自分支＃1的最新更改，他们可以发出如下命令：
$ git merge branch-1
并且该工具会自动知道该基础是B - 因为它被记录在提交M中，该提交是＃2尖端的祖先 - 并且它必须合并B和C之间发生的任何事情.CVS不记录此信息，1.5版本之前的SVN也没有。 在这些系统中，图形如下所示：
o---A---o---B---o---C (branch #1)
o---o---M---X---? (branch #2)
其中M仅仅是A和B之间发生的所有事情的一个巨大的“压扁”的承诺，应用于M之上。请注意，在完成契约之后，没有任何剩余痕迹（可能在人类可读的评论中），其中M确实源于，也没有多少承诺崩溃在一起 - 使历史更加难以逾越。
更糟的是，执行第二次合并变成了一场噩梦：人们必须弄清楚合并基地在第一次合并时的情况（并且必须知道首先合并了），然后提出信息，以便它不会尝试在A之上重放A..B。所有这些在密切协作中都很困难，但在分布式环境中根本不可能。
一个（相关的）问题是无法回答这个问题：“X是否包含B？” 其中B是潜在的重要错误修复。 那么，为什么不把这些信息记录在提交中呢，因为它在合并时是已知的！
P.-S. - 我没有使用SVN 1.5+合并记录功能的经验，但工作流程似乎比分布式系统更有人气。 如果确实如此，那可能是因为 - 正如上述评论中所提到的那样 - 重点放在存储库的组织上，而不是自己的改变。
因为Subversion（至少版本1.4及以下版本）不会跟踪已合并的内容。 对于Subversion来说，合并与其他版本控制（如Git）上的任何提交基本相同，已合并的内容将被记住。
没有任何已经提供的答案，Hg提供了卓越的合并能力，因为它在合并变更时使用更多信息（hginit.com）：
例如，如果我稍微改变了一个函数，然后将它移动到别的地方，Subversion并没有真正记住那些步骤，所以当它合并的时候，它可能会认为一个新的函数出现在蓝色之外。 Mercurial会分别记住这些事情：功能发生变化，功能发生变化，这意味着如果您也稍微更改了该功能，则Mercurial更有可能成功合并我们的更改。
当然，记住上一次合并的内容（这里提供的大多数答案都是这个问题）也是一个巨大的胜利。
然而，这两种改进都是有问题的，因为Subversion 1.5+以颠覆属性的形式存储了额外的合并信息：该信息可用，Subversion合并为什么不能像Hg或Git那样成功实现合并。 不过，我不知道它是否确实如此，但听起来像颠覆开发者正在解决这个问题。
链接地址: http://www.djcxy.com/p/37543.html上一篇: Why is branching and merging easier in Mercurial than in Subversion?