MQ vs.Mercurial的分支机构

Question

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

今天我读了关于MQ（Mercurial队列-章节 12 和 13).我想我理解了MQ背后的概念，所以我的问题是:

Mq对Mercurial中的（命名）分支有什么优势（对于我的场景）？

Answer 1

与命名分支相比，MQ的主要优点是:

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

• 补丁中的更改将与上游所做的更改干净地分开。当您合并两个分支时，您将混合两个开发流。这使得很难看到您所做的更改，而不会看到来自上游分支的更改。

• 补丁名称是暂时的。当你 hg qfinish 一个应用的补丁，提交中没有留下补丁名称的痕迹。因此，您可以使用MQ而无需首先与上游存储库进行协调，因为它们永远不会注意到MQ。

• 你避免合并。而不是与上游的最新代码合并，您 [医]改性 你应用的补丁。这给你一个更简单的历史。历史显然是假的，因为你假装你做了所有的补丁 之后 从上游看到代码-当infact时，您与上游和更高版本并行 搬家了 你的补丁到上游的尖端。

• 变更集中没有永久的分支名称。人有时 将命名分支视为一次性 当他们意识到一个命名的分支在历史中是固定的时，他们会感到不安。（你实际上可以设置分支名称与 hg branch 之前推补丁所以这一点不是那么糟糕。)

MQ的缺点是:

• 这是一个额外的学习工具。它很强大，但它也给了你更多的机会射击自己的脚。跑步 hg qdelete 真的会 删除 补丁，所以你可以扔掉数据。（我认为这很好，但是我们有一个Git用户来到我们的mailinglist抱怨这一点。)

• 你让与他人合作变得更加困难。你 可以 转 .hg/patches 进入存储库并在存储库之间推送/拉取补丁，但如果您不仅仅是一个开发人员，则很难做到这一点。问题是，如果多个人刷新同一个补丁，您最终会合并补丁。

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

Answer 2

好问题。这取决于。就个人而言，我不喜欢Mercurial分支系统，当我可以（使用被推式的书签而不是分支）时，我试图避免它。

mq是一个很好的工具，具有强大的力量和巨大的陷阱。您还可以考虑使用 pbranch

mq是一个很好的工具，如果您需要为项目生成和维护一个补丁集，类似于将Furgure-X添加到项目并使修补程序与上游代码添加更新的内容。

书签（或分支，如果您喜欢）很好适用于需要合并到上游代码的短开发任务。