我已经和Mercurial合作了一段时间了。在对某些第三方软件进行（私有）更改时，我总是为这些更改创建一个单独的命名分支。当上游代码更新时，我只需将其合并到我的命名分支中。
今天我读到了MQ（Mercurial Queues - 章节12和13）。我想我理解MQ背后的概念，所以我的问题是：
在Mercurial（对于我的场景）中，MQ over（命名）分支是否有任何优势？
答案 0 :(得分：13)
MQ优于命名分支的主要优点是：
您可以修改补丁。这使您可以编辑历史记录，因此您可以在上游代码之上维护一系列干净且符合逻辑的补丁：如果您发现补丁中存在错误，则刷新补丁而不是进行新的提交。
补丁中的更改将与上游所做的更改完全分开。合并两个分支时，将两个开发流混合在一起。这使得很难看到你所做的改变而没有看到来自上游分支的变化。
补丁名称是暂时的。当您hg qfinish应用补丁时，提交中没有任何补丁名称的痕迹。因此，您可以在不首先与上游存储库协调的情况下使用MQ，因为它们永远不会注意到MQ。
您可以避免合并。您可以rebase应用补丁，而不是使用上游的最新代码进行合并。这为您提供了更简单的历史记录。历史显然是假的，因为你假装在看到来自上游的代码之后你做了所有的补丁 - 实际上是你与上游并行，后来移动了你的补丁到上游的一角。
您在更改集中没有永久分支名称。人们有时treat named branches as disposable并且当他们意识到历史中已修复命名分支时会感到不安。 （在推送补丁之前，您实际上可以使用hg branch设置分支名称，所以这一点并不是那么糟糕。）
MQ的缺点是：
这是一个额外的学习工具。它很强大，但它也为你提供了更多机会射击自己。运行hg qdelete将真正删除补丁，因此您可以丢弃数据。 （我认为这很好，但我们有一个Git用户来我们的邮件列表抱怨这个。）
你要与其他人合作更加困难。您可以将.hg/patches转换为存储库并在存储库之间推送/拉取补丁，但如果您不仅仅是一个开发人员，那么很难做到这一点。问题是如果多个人刷新同一个补丁，你最终会合并补丁。
您在更改集中没有永久分支名称。如果您正确使用命名分支并使用稳定的长期分支名称，那么在使用MQ时您将会错过。
答案 1 :(得分：1)
好问题。这取决于。我个人不喜欢mercurial分支系统，我尽量避免使用它（使用推书签而不是分支）。
MQ是一个很棒的工具，具有强大的功能和巨大的陷阱。您还可以考虑使用pbranch。
如果您需要为项目生成和维护补丁集，MQ是一个很好的工具，例如向项目添加feature-x并使用上游代码更新补丁。
书签（或分支，如果你喜欢）适用于需要合并到上游代码的短期开发任务。