mercurial - 如何使用 mercurial 管理并发开发？

Question

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

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

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

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

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

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

为 B 使用单独的克隆。

在同一存储库中使用匿名或命名分支或书签。

使用 MQ(在 A 上使用 B 补丁)。

使用分支 MQ(我稍后会解释)。

使用多个 MQ (自 1.6)

1 和 2 被 excellent blog 覆盖@Steve Losh 从 slightly related question 链接.

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

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

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

hg qnew bugA ;对 A 进行更改； hg qref

mq branch branchA; hg qci

hg qpop; mq up -rtip^

hg qnew bugB ;对 B 进行更改； hg qref

mq branch branchB; hg qci

再次处理 A:hg qpop; mq up branchA; hg qpush

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

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

(更新)qqueue几乎使＃4过时了。参见 Steve Losh 的优雅描述 here .

Answer 1

我总是使用命名分支，因为这让 Mercurial 可以完成它的工作:保留您的项目历史记录，并记住您为什么以什么顺序对源代码进行了哪些更改。考虑到我的工作方式，至少在磁盘上放置一个或两个克隆通常很容易:

您的项目是否缺少构建过程，以便您可以直接从源代码进行测试和运行？然后我会很想只有一个克隆，hg up当我需要在另一个分支上工作时来回走动。

但是如果你有一个构建、virtualenv 或其他构建的结构，并且可能在两个分支之间存在分歧，那么执行 hg up然后等待构建过程重新运行可能会很痛苦，尤其是在涉及设置示例数据库之类的事情时。在那种情况下，我肯定会使用两个克隆，一个位于树干的顶端，一个位于紧急功能分支的顶端。