为什么在Mercurial中分支和合并比在Subversion中更容易？
为什么在Mercurial中分支和合并比在Subversion中更容易？
在Subversion或CVS中处理多个合并到分支的操作只是其中一件必须亲身体验的事情。在Mercurial（以及可能是任何其他分布式系统）中，跟踪分支和合并要容易得多，但我不知道为什么。有人知道吗？
我的问题源于Mercurial可以采用类似于Subversion/CVS的中央仓库的工作实践，一切都能正常运行。您可以在同一分支上进行多次合并，而不需要无休止地记录提交编号和标签名称。
我知道最新版本的Subversion具有跟踪合并到分支的能力，因此您不会遇到完全相同程度的麻烦，但这对他们来说是一个巨大的主要发展，而且它仍然无法满足开发团队的所有需求。
这一切肯定有一种根本的不同工作方式。
为什么Mercurial比Subversion更容易进行分支和合并？
Mercurial在合并更改时使用更多的信息，这使得它具有更强大的合并能力。相比之下，Subversion在合并时并不真正记住这些步骤，因此在合并时可能会认为出现了新的函数。然而，Mercurial会分别记住这些步骤，这意味着如果你对这个函数做了一些修改，Mercurial更有可能成功地合并我们的更改。
当然，记住上次合并的内容也是一个巨大的优势。然而，这两个改进在Subversion 1.5+中都是有问题的，因为它以Subversion属性的形式存储了额外的合并信息。在有了这些信息后，Subversion的合并理论上应该能够像Mercurial或Git一样成功地执行合并。不过我不确定它是否实现了这一点，但肯定的是Subversion的开发人员正在努力解决这个问题。
为什么Mercurial中的分支和合并比Subversion更容易？
在Subversion（和CVS）中，仓库是首要的。在Git和Mercurial中，没有类似的仓库概念；这里的变更是中心主题。
CVS/SVN中的麻烦来自于这些系统不记住变更的父子关系。在Git和Mercurial中，一个提交不仅可以有多个子节点，还可以有多个父节点！
这可以通过其中一个图形工具（gitk或hg view）轻松观察到。在以下示例中，分支2从提交A处分叉于分支1，并在此之后进行了一次合并（在M处与提交B合并）：
o---A---o---B---o---C (分支1)
\ \
o---o---M---X---? (分支2)
请注意，A和B有两个子节点，而M有两个父节点。这些关系被记录在仓库中。假设分支2的维护者现在想要合并分支1的最新变更，他们可以发出以下命令：
$ git merge branch-1
工具会自动知道基础是B——因为它被记录在提交M中，是分支2末端的祖先——并且它必须合并B和C之间发生的任何变更。CVS不记录这些信息，之前的SVN版本也不记录。
在这些系统中，图形将会是这样的：
o---A---o---B---o---C (分支1)
\
o---o---M---X---? (分支2)
其中M只是一个巨大的“压缩”提交，包含了A和B之间发生的所有变更，应用在M之上。请注意，完成后，没有痕迹（除了人类可读的注释）表明M的起源在哪里，也没有有多少提交被合并在一起——使得历史更加难以理解。
更糟糕的是，进行第二次合并变得非常困难：必须找出第一次合并时的基础是什么（还必须知道第一次确实发生了合并！），然后将该信息提供给工具，以便它不会尝试在M之上重新应用A..B。所有这些在紧密协作时已经很困难了，但在分布式环境中根本不可能。
一个（相关的）问题是没有办法回答问题：“X是否包含B？”其中B是一个可能重要的错误修复。那么，为什么不在提交中记录这些信息，因为在合并时是已知的呢！
PS：我对SVN 1.5+的合并记录功能没有经验，但工作流程似乎比分布式系统更复杂。如果确实如此，那可能是因为-如上面的评论所提到的-重点放在仓库组织上，而不是变更本身。SVN 1.5+确实会在合并提交M上放置一个列出所包含的合并提交（即A-B）的SVN属性。所以你有相同的信息。
有点类似。从技术上讲，SVN的合并追踪类似于Git称之为“cherry-picking”的操作，但使用了额外的魔法使其对用户更加友好；在合并操作时，它在语义上与Git、Hg和Bzr所做的操作是不同的。我猜在实践中这没有太大区别，只要你不关心DAG（有向无环图）。
哇，没有+100的按钮。谢谢。
我假设你提到的SVN 1.5功能是使用svn:mergeinfo属性？
是的，这正是svn:mergeinfo的作用。
你总是可以设定奖励！
为什么Mercurial比Subversion更容易进行分支和合并？
Subversion（至少版本1.4及以下）没有跟踪已合并的内容。对于Subversion来说，合并基本上和提交一样，而在其他版本控制系统（如Git）中，已合并的内容是被记住的。
这个问题的出现原因是Subversion没有提供一种机制来跟踪已经合并的内容。这意味着在使用Subversion进行分支和合并时，开发人员需要手动记录和跟踪已经合并的内容，这增加了管理的复杂性和可能导致错误。
Mercurial则提供了更简单和可靠的分支和合并机制。Mercurial使用一个称为"merge tracking"的功能来跟踪已经合并的内容。这意味着在使用Mercurial进行分支和合并时，系统会自动记录和跟踪已经合并的内容，使得分支和合并操作更加简单和可靠。
在Mercurial中，分支和合并的操作可以通过以下步骤完成：
1. 创建一个新的分支，使用命令hg branch branch_name。
2. 在新分支上进行开发工作，使用命令hg commit -m "commit message"提交更改。
3. 在原始分支上进行开发工作，使用命令hg update branch_name切换到新分支。
4. 使用命令hg merge将新分支的更改合并到原始分支上。
5. 使用命令hg commit -m "merge message"提交合并的更改。
通过这种方式，Mercurial可以更简单和可靠地进行分支和合并操作，而无需手动记录和跟踪已经合并的内容。
，Mercurial比Subversion更容易进行分支和合并的原因是Mercurial提供了"merge tracking"功能，可以自动跟踪已经合并的内容，从而简化了分支和合并操作。通过使用Mercurial的分支和合并机制，开发人员可以更轻松地管理代码的变更和合并，提高工作效率和代码质量。