Mercurial 和代码审查；良好的工作流程？

Question

我在一个小型分布式团队中，使用 Mercurial 作为中央存储库。我们每个人都通过 ssh 将其克隆到我们自己的 Linux 机器上。我们的目的是在将更改推送到中央存储库之前审查彼此的工作，以帮助保持中央存储库的干净。在不同 Linux 机器上的开发人员之间共享代码的好方法是什么？我是 Mercurial 的新手。我能想到的选项（通过阅读，而不是经验）是：

1：作者提交所有本地更改并使用中央提示更新工作克隆。如果有办法指定捆绑包中包含哪些本地转速，作者会使用 hg 捆绑包。 （一项实验表明，“捆绑”仅获取未提交的更改，即使中央不知道以前的本地提交）作者将捆绑文件发送给审阅者。审阅者从中心的尖端创建一个新的干净克隆，并将包导入到该克隆中。 或者，

2：作者和审阅者都从中心的提示中获取后，作者使用补丁，审阅者导入补丁。 或者，

3：作者推送到审阅者或审阅者从作者处拉取（但是，到底是如何？我读到的只是关于向/从原始服务存储库推送和拉取，和/或在同一个盒子上而不是在不同的 Linux 盒子之间推送和拉取。 )

4：忘记在推送到中央之前检查代码；继续推进，使用标签来识别哪些内容已被审查或未审查，并使用 Hudson（已经在工作）来标记最新的安全构建，以便团队成员可以知道从哪一个中提取。

如果您的团队使用 Mercurial 并进行代码审查，您如何让审查者看到您的更改？

Answer 1

其中大多数都是可能的，但有些比其他更乏味。

1. 您可以通过将中央存储库的提示指定为 --base 来使用捆绑包：
   hg bundle --base 4a3b2c1d review.bundle
2. 不妨只使用bundle。这样，变更集数据也包含在内。
3. 您可以向具有共同祖先的任何存储库推送（和拉取）。如果您想从一位同事那里拉取，他们只需要在他们的机器上运行 hgserve ，您就可以拉取。
4. 这也有效，但您必须维护多个头并小心合并。如果不这样做，那么在未经审查的变更集之上建立稳定的变更就会变得很容易，如果您以后需要修复该未经审查的变更集，这将使撤消变得困难。

在您提供的选项中，＃1 和＃3 可能是最简单的，仅取决于你们是否可以到达对方的盒子。

相关说明：这个问题促使我和我的同事开始开发 Kiln，我们的（Fog Creek 的）Mercurial 托管和代码审查工具。我们的计划和最初的原型将保留多个存储库，一个“中央”存储库和一堆“审查”存储库。审查过程首先将中央存储库克隆到服务器上的审查存储库中，然后在两者之间运行完整的存储库差异，并使用一个简单的 Web 界面来获取和查看差异。

我们已经对该工作流程进行了相当大的改进，但总体思路仍然是相同的，即有一个分支存储库来推送未经审核的更改，并有一个界面在将它们推送到中央存储库之前对其进行审核。我不想在这里做广告，但我确实建议给予尝试一下。

Answer 2

这个问题的一半答案是使用 ReviewBoard 和 Mercurial 扩展。它允许通过发出以下命令来推送某些修订以供审查

hg 审稿后提示

Answer 3

我将添加第五个选项 - 在命名分支上进行所有开发工作，最好每个任务一个。允许将任何内容提交给名为“开发”的分支，无论它是否处于工作状态。

推送到中央存储库，让审阅者拉取分支。对分支机构进行审核。

当审核通过后，将开发工作合并到适当的功能分支中。

这个工作流程（对我而言）出人意料地不受欢迎，但它具有许多优点：

1. 所有工作都已提交 - 您不必在提交之前等待审核完成。

2. 您不会构建错误的版本。您只能从功能分支进行构建。

3. 正在进行的工作不会干扰其他开发人员。

4. 从开发分支，您可以查看最新的更改（例如，处理审核意见的更改集），与分支点进行比较，或者与最新的功能分支进行比较 - 所有这些都可以提供有用的信息。