问建议的使用汞的代码评审过程

EN

事实上，我们最近在我的公司经历了几乎完全一样的事情。以下是我们所做的：

• 我们在一台服务器上保存了所有存储库的中心最终副本。当开发人员想要“签出”代码时，他们会转到这个服务器并从那里的存储库克隆。同样，当开发周期完成时，代码也会被推入适当的存储库中。
• 我们将稳定的存储库与开发存储库分离开来。我们要求在将代码推入稳定的存储库之前对其进行检查。(这很重要，因为我们还要求稳定的存储库包含当前正在生产中运行的代码，这与挂起的代码升级有所不同。)

为了执行代码评审，我们编写了一个pretxnchangegroup钩子(在HG书中有文档)。我们利用这样一个事实:当这个钩子运行时，它可以将存储库看作--如果代码更改是永久的，同时也给了我们防止推送的能力。基本上，这一过程如下：

1. 开发人员启动对稳定存储库的推送(是的，这确实是第一步)
2. 钩子运行并获取事务中包含的所有更改集的列表(通过运行HG日志)。然后，它查询我们构建的数据库，以查看这些更改集是否包含在代码评审中。(该表将更改集的哈希与代码评审ID匹配)。
   • 如果这是第一次看到这些更改集，那么我们将创建一个新的代码评审(使用代码协作器命令行)，然后使用代码评审的ID将这些更改集记录到数据库中。
   • 如果我们看到了一些变更集(但不是全部)，我们会运行( Collaborator)命令，将新的变更集附加到现有的评审中，并将这些新的变更集记录到数据库中。
   • 如果所有的更改都在数据库中找到(即它们都被添加到代码评审中)，那么我们将验证代码评审的状态是否已经完成。但是，如果有任何新的更改集(或者代码评审还没有完成)，钩子就会以非零状态代码退出(导致Mercurial回滚事务)，并输出一条关于标准错误的友好消息，向开发人员解释代码评审需要完成。

本质上，这为开发人员提供了一个相当精简的流程(他们所要做的就是一个hg推送)，并且完全自动化了代码评审的创建(并将其他更改的文件上传到评审中)，同时确保所有代码都经过审核。

注意:这是一个相当简单的过程(对我们来说也是比较新的)，所以它可能并不适用于每个人，而且可能有一些我们还没有遇到的设计错误。但到目前为止，它运作得很好。