9

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

今天我读到了 MQ（Mercurial Queues - 第12章和第13章）。我想我理解了 MQ 背后的概念，所以我的问题是：

与 Mercurial 中的（命名）分支相比（对于我的场景），MQ 有什么优势吗？

4

2 回答 2

13

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

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

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

  • 补丁名称是临时的。当您hg qfinish应用补丁时，提交中不会留下补丁名称的痕迹。因此，您无需先与上游存储库协调就可以使用 MQ，因为他们永远不会注意到 MQ。

  • 你避免合并。您无需与来自上游的最新代码合并，而是重新定位您应用的补丁。这为您提供了更简单的历史记录。这段历史显然是假的，因为你假装在看到上游代码后制作了所有补丁——实际上你是与上游并行制作的，然后将补丁移到上游的顶端。

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

MQ的缺点是：

  • 这是一个额外的学习工具。它很强大，但它也让你有更多的机会在脚下开枪。运行hg qdelete将真正删除补丁，因此您可以丢弃数据。（我认为这很好，但我们有一个 Git 用户来到我们的邮件列表抱怨这个。）

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

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

于 2012-03-12T11:36:56.570 回答
1

好问题。这取决于。就我个人而言，我不喜欢 mercurial 分支系统，并且尽可能避免使用它（使用推送的书签而不是分支）。

MQ 是一个很棒的工具，具有强大的功能和巨大的陷阱。您也可以考虑使用pbranch。

如果您需要为项目生成和维护补丁集，例如向项目添加 feature-x 并使用上游代码更新补丁，MQ 是一个很好的工具。

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

于 2012-03-12T10:48:48.303 回答