MQ与Mercurial中的分支

我已经和Mercurial合作一段时间了。在对某些第三方软件进行（私有）更改时，过去我总是为这些更改创建一个单独的命名分支。当上游代码更新时，我只需将其合并到我的命名分支中

今天我读了关于MQ（Mercurial队列-章节和）。我想我理解MQ背后的概念，所以我的问题是：

---

与Mercurial中的（命名的）分支相比，MQ是否有任何优势（对于我的场景）？

好问题。视情况而定。就我个人而言，我不喜欢mercurial分支系统，我尽量避免它（使用推式书签而不是分支）

MQ是一个伟大的工具，具有强大的功能和巨大的缺陷。你也可以考虑使用.< /P> 如果您需要为项目生成和维护补丁集，比如向项目中添加feature-x，并使用上游代码更新补丁，MQ是一个很好的工具

---

书签（或分支，如果您愿意）适用于需要合并到上游代码中的短期开发任务。

MQ相对于命名分支的主要优势是：

• 你可以修改你的补丁。这允许您编辑历史记录，因此您可以在上游代码的基础上维护一系列干净且符合逻辑的修补程序：如果您注意到修补程序中存在错误，您将刷新修补程序，而不是进行新的提交

• 补丁中的更改将与上游所做的更改完全分离。当您合并两个分支时，您将混合两个开发流。这使得在没有看到来自上游分支的更改的情况下，很难看到您所做的更改

• 补丁名是暂时的。当您

  hg qfinish

  应用补丁时，提交中没有留下补丁名称的痕迹。因此，您可以在不首先与上游存储库协调的情况下使用MQ，因为他们永远不会注意到MQ

• 避免合并。您不需要与上游的最新代码合并，而需要应用补丁。这将为您提供一个更简单的历史。历史显然是假的，因为你假装在看到上游的代码后制作了所有补丁——事实上，你是与上游并行制作的，后来又将补丁移到上游的顶端

• 变更集中没有永久分支名称。当人们意识到一个命名的分支在历史上是固定的时，他们有时会感到不安。（实际上，在推送补丁之前，您可以使用

  hg branch

  设置分支名称，这样这一点就不那么糟糕了。）

MQ的缺点是：

• 这是一个额外的学习工具。它很强大，但它也给了你更多的机会射中自己的脚。运行

  hgqdelete

  将真正删除补丁，因此您可以丢弃数据。（我认为这很好，但我们有一个Git用户来到我们的邮件列表抱怨这一点。）

• 你让与他人合作变得更加困难。您可以将

  .hg/patches

  转换为一个存储库，并在存储库之间推送/拉取补丁，但如果您不是单个开发人员，则很难做到这一点。问题是，如果有多人刷新同一个修补程序，则最终会合并修补程序

• 变更集中没有永久分支名称。如果您正确地使用命名分支并使用稳定的长期分支名称，那么在使用MQ时您将错过这一点

---

不过，使用rebase也可以达到同样的效果。@LaurensHolst:哦，是的。我更关注的是MQ如何强制您重新设置补丁的基础-MQ不允许合并。让我稍微扩展一下答案。MQCollab扩展使MQ修补程序的协作变得非常好我从不重新设置MQ修补程序的基础。只要qpop all、pull、qpush、编辑补丁（如果需要）。“我做错了什么？”懒獾，你可以。重定基址在内部使用合并，因此在重定基址时，您将获得合并工具支持。当使用qpush时，您不会得到这一点。