问题标签 [mercurial-queue]

我必须在 mercurial 存储库中维护的代码库上运行十几个不同的构建测试。我不想在同一个存储库上连续运行这些测试，因为它们修改了一组公共文件，我想在不同的机器上并行运行它们。此外，在运行所有测试之后，我希望能够访问这些测试工作区域的最新测试结果。目前我正在克隆主存储库十几次，并在每个克隆中运行一个不同的测试。在每次测试执行之前，我都会执行拉取/更新/清除准备序列，以便在最新的干净状态下开始测试。这对我有好处。

我还在准备使用 mq 扩展的新更改，我将在提交它们之前对上述所有克隆进行测试。为了测试一些准备好的候选 mq 补丁，我想以某种方式部署/同步它们以在测试克隆中可用，并在运行测试之前使用一些防护应用那些准备好进行测试的补丁。

以前有人做过这种同步吗？最简单的方法是什么？我需要为此提供版本化的 mq 补丁吗？

我想使用 Mercurial 来捕获对我们使用的软件的原版安装所做的更改。每次升级软件时，我们都需要手动编辑各种配置文件，并添加我们在当前版本软件中使用的第三方库。为配置文件更改创建补丁很好，但是如何将 3rd 方库（二进制文件）添加到 Mercurial 补丁？甚至可能吗？

我有一个希望能够为其创建补丁的 Web 应用程序。具体来说，我想创建补丁以在 Web 服务器中启用特定功能。

我想要做的是为我需要对该文件进行的每个单独修改保存一个补丁，以便可以单独应用补丁（使用 qpush -move）或一起应用（qpush -a）

我首先使用文件的干净版本尝试了以下操作：

然后我修改了文件的第一行以包含以下内容

然后刷新了补丁

弹出补丁以从干净的基础开始进行第二次修改

我修改了文件的第一行以包含以下内容

然后刷新了补丁

然后当我尝试 qpush 较旧的补丁时，它未能应用。然后我尝试了另一种方法，即首先创建一个基础补丁：

，将以下内容添加到文件中

,然后刷新base.patch

然后在仍应用 base.patch 的同时为 jmx 创建一个新补丁：

编辑文件如下：

刷新补丁并弹出：

为果冻创建新补丁：

编辑文件如下：

刷新了补丁：

但同样，当我尝试将 jmx.patch qpush 到新创建的 jelly.patch 之上时，出现了冲突。

我认为 Mercurial 的行为符合预期，但我想知道我是否可以以不同的方式构建我正在制作的补丁，以便它们可以单独应用或组合使用而不会被拒绝

我使用 mercurial 队列，有时我忘记使用 a 设置消息，hg qrefresh -m ...忘记在运行之前检查hg qfinish并收到消息patch MyPatch finalized without changeset message。如果没有消息，有什么方法可以让 qfinish 中止？

在我这样做之后，我发现解决这个问题的唯一方法是生成一个补丁，hg strip我的最后一个修订版，重新应用补丁，然后提交我的消息。

这是一个最佳实践问题，我希望答案是“视情况而定”。我只是希望了解更多真实世界的场景和工作流程。

首先，我说的是同一个项目的不同更改，所以请不要使用 subrepo。

假设您的代码库位于 hg 存储库中。您开始研究一个复杂的新功能 A，然后您信任的测试人员报告了一个复杂的错误 B（您有测试人员，对吗？）。

如果（修复）B 取决于 A，这很简单。您只需 ci A 然后 ci B。

我的问题是当他们独立时（或者至少现在看起来）该怎么办。

我可以想到以下几种方式：

1. 为 B 使用单独的克隆。
2. 在同一存储库中使用匿名或命名分支或书签。
3. 使用 MQ（在 A 上使用 B 补丁）。
4. 使用分支 MQ（我稍后会解释）。
5. 使用多个 MQ（从 1.6 开始）

1 和 2由 @Steve Losh的一篇优秀博客涵盖，该博客链接自一个稍微相关的问题。

与其他选择相比，1 的一个巨大优势是，当您从一件事切换到另一件事时，它不需要任何重建，因为文件在物理上是分开的和独立的。因此，例如，如果 A 和/或 B 涉及定义三态布尔值并被数千个 C 文件包含的头文件（不要告诉我你没有见过这样的遗留代码），那么它确实是唯一的选择根据）。

3 可能是最简单的（就设置和开销而言），如果 B 是一个小和/或紧急修复，您可以颠倒 A 和 B 的顺序。但是，如果 A 和 B 接触相同的文件，它会变得很棘手。如果 A 和 B 更改在同一个文件中是正交的，则修复无法应用的补丁块很容易，但从概念上讲它仍然有点冒险。

4可以让你头晕目眩，但它是最强大，最灵活和可扩展的方式。我默认hg qinit使用，-c因为我想标记正在进行的补丁并推送/拉取它们，但是确实需要一个概念上的飞跃才能意识到您也可以在 MQ 存储库中分支。以下是步骤（mq = hg --mq）：

1. hg qnew bugA; 对 A 进行更改；hg qref
2. mq branch branchA; hg qci
3. hg qpop; mq up -rtip^
4. hg qnew bugB; 对 B 进行更改；hg qref
5. mq branch branchB; hg qci
6. 再次在 A 上工作：hg qpop; mq up branchA; hg qpush

采取这么多步骤似乎很疯狂，每当您需要转换工作时，您必须hg qci; hg qpop; mq up <branch>; hg qpush。但是考虑一下：您在同一个存储库中有多个命名的发布分支，并且您需要同时处理多个项目并为所有这些分支进行错误修复（您最好获得此类工作的保证奖金）。使用其他方法，您很快就会迷路。

现在我的汞爱好者，还有其他/更好的选择吗？

（更新）qqueue几乎使＃4过时了。请在此处查看 Steve Losh 的优雅描述。

Mercurial中创建补丁的过程如下：

使用 qnew 创建补丁 -> 进行更改 -> 刷新补丁

如果我已经进行了（未提交的）更改并且我想将它们添加到队列中怎么办？

我在以下情况下使用水银补丁：-

1. 当我需要从远程存储库中提取并有未提交的更改时。然后我简单地创建一个补丁，qpop 它，从远程存储库中拉取，然后再次导入补丁。
2. 当我需要将补丁上传到 reviewboards 时。我只是制作一个补丁并上传它。

您还如何使用 Mercurial 补丁队列？我觉得它是一个非常强大的 Mercurial 扩展，我没有充分发挥它的潜力。

扩展中的qrefresh命令MQ对我来说没有意义。我将解释我的假设：

1. 如果您不知道应该在哪个版本上应用某个补丁，那么它的价值就很小。从理论上讲，您无法知道拒绝是什么意思。即使某个版本没有被拒绝，您也不确定整个版本是否会编译。
2. 一旦你qrefresh在你的补丁队列中找到了某个补丁，你实际上就失去了队列中下一个补丁的父级。所以如果没有你的干预，下一个补丁是/可能是无用的。
3. 为了修复下一个补丁，您最好合并它而不是手动编辑.rej文件。不仅仅是因为更好的工具，如果你有原始的未qrefresh编辑补丁，你就会有更多的信息，这会qrefresh导致你丢失你真正需要的信息，以便使你对补丁所做的更改有意义。

因此，我不明白为什么要使用此命令。

更好的选择是，应用所有补丁，然后应用hg update到要更改的补丁的父级，然后hg revert将工作目录应用到要更改的补丁。更改此补丁，将其提交到新修订版，然后在此新修订版上重新定位所有其他补丁。

qrefresh当您不只编辑单个补丁时，我根本不明白何时相关。似乎这种git方法（将补丁应用到本地分支）比补丁队列更有意义。

我是否正确，我最好使用变基？有什么我错过的吗？

因无反应且浏览量低，从窑炉网迁移

有时，当我进行代码更改时，我需要对我的存储库中的共享库代码进行相应的更改，该存储库本身就是一个子存储库。当我想提交更改时，我会在父存储库中提交，Mercurial 会负责在子存储库中进行相应的提交。

但是，我最近开始使用 MQ 来更好地跟踪我自己的更改历史，并给自己更多的自由来进行实验和更安全地进行大规模重构工作。我在父存储库和子存储库上都启用了 MQ。

在上述场景中，我是否正确假设如果我“提交”到新的或现有的 MQ 补丁，那么子存储库会被忽略？这似乎是我的测试中发生的事情。这是否意味着我需要手动管理子存储库中的补丁队列？这很快就会变得笨拙。

如果这不起作用，那很好——当我有跨仓库工作要做时，我可以调整我的工作流程并避免使用 MQ——但我想知道我是否遗漏了一些东西，或者其他人是否有他们可以分享的这种情况的解决方案。

更新：根据此线程，此时似乎“不支持”：https ://www.mercurial-scm.org/bts/issue2499

我尝试了以下方法：

1. 手动提交子存储库更改。
2. 使用来自子存储库提交的哈希手动更新了父存储库中的 .hgsubstate 文件。
3. 试图 qrefresh 父存储库。

这个想法是我可以从父存储库获取提交以始终与正确的子存储库版本同步，即使我必须手动执行。不幸的是，Mercurial 似乎想在这里保护我（应该如此！），当我尝试 qrefresh 时，会出现以下问题：

为了“修复”事情，我在父存储库上的 hgfinish 之后做了一个空提交，以使事情同步备份。但是......这似乎很愚蠢，并且使代码历史更难理解。

哦，好吧，当涉及到子存储库时，我想我会回到石器时代并停止在我的工作流程中使用 MQ。

我在存储库上使用 Mercurial Queues，并将这些补丁放在补丁存储库中。另一位贡献者克隆了我的补丁队列并进行了自己的更改。我现在想将他们的更改合并到我的本地补丁存储库中。

我正在尝试找到一个很好的工作流程来执行此合并

• 在补丁存储库的历史记录中反映贡献者的变更集
• 在发生冲突时调用用户的合并工具

最初，我只是尝试直接合并补丁。这在非常简单的情况下是可以的，但当很多事情发生变化时就不能很好地工作，因为补丁取决于行号上下文，这似乎不是我应该担心调整自己的事情。总的来说，我发现检查补丁的 3 路差异太复杂了。

有没有更好的办法？