17

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

首先，我说的是同一个项目的不同更改，所以请不要使用 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 的优雅描述。

4

3 回答 3

7

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

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

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

于 2010-09-16T12:54:55.483 回答
3

似乎没有比我在问题中列出的选择更多或更好的选择。所以他们又来了。

  1. 每个项目使用一个克隆。
    • 优点：完全分离，因此在切换项目时无需重建。
    • 缺点：工具链需要在两个克隆之间切换。
  2. 在同一存储库中使用匿名或命名分支或书签。
    • 优点：标准 hg（或任何 DVCS）实践；干净利落。
    • 缺点：必须在切换之前提交并在之后重建。
  3. 每个项目使用一个补丁（或多个连续补丁）的 MQ。
    • 优点：简单易行。
    • 缺点：必须qrefresh在切换之前和之后重建；如果项目不是正交的，则棘手且有风险。
  4. 每个项目使用一个 MQ 分支（或qqueue1.6+）。
    • 优点：超灵活和可扩展（针对并发项目的数量）
    • 缺点：必须qrefresh和qcommit之前切换和重建之后；感觉很复杂。

像往常一样，没有灵丹妙药，所以挑选适合工作的那个。

（更新）对于喜欢 MQ 的任何人，在常规分支（#2 + #3）之上使用 MQ 可能是最常见和更可取的做法。

如果您在两个分支上有两个具有基线的并发项目（例如下一个版本和当前版本），那么像这样在它们之间跳转是微不足道的：

hg qnew; {coding}; hg qrefresh; {repeat}
hg qfinish -a
hg update -r <branch/bookmark/rev>
hg qimport -r <rev>; {repeat}

最后一步，qimport应该添加一个-a选项来一次导入一行变更集。我希望Meister Geisler注意到这一点 :)

于 2010-10-30T03:05:20.093 回答
1

所以问题是，当您被告知停止开发功能 A 并开始独立功能 B 时，还有哪些替代选项：如何使用 mercurial 管理并发开发？

让我们看看删除并发的问题，就像编写线程代码一样——定义一个简单的工作流来解决给你的任何问题，并将其应用于每个问题。一旦完成，Mercurial 将加入这项工作。因此，程序员 A 将处理功能 A。程序员 B 将处理功能 B。两者都恰好是你。（如果我们有多核大脑就好了：）

我总是使用命名分支，因为这让 Mercurial 可以完成它的工作：保留您的项目历史记录，并记住您为什么以什么顺序对源代码进行了哪些更改。

我同意 Brandon 的观点，但我想知道他是否忽略了功能 A 尚未经过测试？在最坏的情况下，代码编译并通过了单元测试，但有些方法实现了以前的要求，有些方法实现了新的要求。与上次签到的差异是我用来帮助我回到功能 A 的正轨的工具。

您的功能 A 代码是否在您通常签入的时候？从功能 A 切换到功能 B 并不是将代码提交到头部或分支的理由。只签入编译并通过测试的代码。我的理由是，如果程序员 C 需要开始功能 C，那么重新签出这个分支不再是最好的起点。保持分支负责人健康，意味着您可以通过更可靠的错误修复快速响应。

目标是让您的（经过测试和验证的）代码运行，因此您希望所有代码最终合并到（您的开发和遗留分支的）头部。我的观点似乎是，我看到分支使用效率低下：代码变得陈旧然后不使用，合并变得比原始问题更难。

只有你的选项 1 对我有意义。一般来说：

  1. 在其他人看到之前，您应该认为您的代码有效。
  2. 把头放在树枝上。
  3. 如果其他人正在解决问题，请分支并办理登机手续。
  4. 如果您的自动化系统或测试人员只需要您的代码，则进行分支。
  5. 如果您是团队的一员，则在解决问题时进行分支。将其视为头部，参见 1-4。

除了配置文件，构建过程应该是一个检查和一个构建命令。在克隆之间切换应该不会比新程序员加入项目更困难。（我承认我的项目需要在这里做一些工作。）

于 2010-09-30T19:36:31.500 回答