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

Question

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

1：作者提交所有本地更改和更新与中央的提示工作克隆。如果有方法可以指定捆绑中包含哪些本地转速，则作者使用hg捆绑包。 （一个实验显示我“捆绑”只捕获未被改变的更改，即使以前的本地提交中央不知道）作者将包文件发送给审阅者。 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托管和代码审查工具的问题。我们的计划和最初的原型将保留多个库，一个“中央”仓库和一些“审查”仓库。审查过程将通过将中央仓库复制到服务器上的评论仓库中，然后在两者之间运行完整的仓库回购比较开始，并使用简单的Web界面获取和查看差异。

我们已经发展了很多工作流程，但总体思路，有一个分支回购推动未经审查的变化和一个界面，在您将它们推入中央仓库之前对它们进行审查仍然是一样的。我不想在这里做广告，但我确实推荐giving it a try。

Answer 2

此问题的一半答案是使用ReviewBoard与Mercurial extention。它可以通过发出以下命令

汞柱postreview尖

Answer 3

推动检讨某些版本将添加一条第五选项 - 做所有的开发工作命名分支，每个任务最好之一。允许任何东西被提交给一个名为“development”的分支，无论它是否处于工作状态。

推送到中央存储库，让审阅者拉分支。在分支上执行审查。

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

这个工作流程，这是（对我来说）出奇火爆，有很多优点：

1. 所有工作被提交 - 你不必等待审查提交之前完成。

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

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

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