Mercurial和代码审查;好工作流程？

Question

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

1：作者提交所有本地更改并使用中心提示更新工作克隆。作者使用hg bundle，如果有办法指定要包含在哪个本地转速中。 （一个实验显示我“捆绑”只抓取未经修改的更改，即使之前有中心不知道的本地提交）作者将捆绑文件提供给审阅者。 Reviewer从中心的提示创建一个新的干净克隆，并将该包导入该克隆。 或者，

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

3：作者推动评论者或审稿人从作者那里获取（但究竟如何？我读到的只是关于推送和拉出原始服务存储库，和/或在同一个盒子而不是在不同的linux盒子之间。）

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

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

Answer 1

其中大多数是可能的，有些比其他更繁琐。

1. 您可以通过将中央仓库的提示指定为--base来使用捆绑包：
   hg bundle --base 4a3b2c1d review.bundle
2. 不妨只使用捆绑。这样，还包括变更集数据。
3. 您可以推送（并拉动）任何具有共同祖先的存储库（来自）。如果你想从你的同事那里拉，他们只需要在他们的机器上运行hg serve，你就可以拉。
4. 这也有效，但你必须保持多个头并注意合并。如果不这样做，可以很容易地在未查看的变更集之上进行稳定的更改，如果您以后需要修复未经审核的变更集，则很难撤消。

在您提出的选项中，＃1和＃3可能最简单，只是取决于您是否可以达到彼此的方框。

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

我们已经进行了相当多的工作流程，但是一般的想法，有一个分支回购推送未经审查的更改，以及在将它们推入中央仓库之前审查它们的界面，仍然是相同的。我不想在这里做广告，但我建议giving it a try。

Answer 2

此问题的一半回答是ReviewBoard与Mercurial extention一起使用。它允许通过发出以下命令推送某些修订以供审查

  

hg postreview tip

Answer 3

我将添加第5个选项 - 对命名分支执行所有开发工作，最好是每个任务一个。允许任何事情致力于＆＃34;开发＆＃34;命名分支，是否处于工作状态。

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

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

这个工作流程（对我而言）令人惊讶地不受欢迎，有许多优点：

1. 所有工作都已提交 - 您无需在提交前等待审核。

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

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

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