我在一个使用Mercurial作为中央存储库的小型分布式团队。 我们每个人都通过ssh克隆到我们自己的Linux机器上。 我们的目的是在向中央资源库推进变革之前，先审查彼此的工作，以帮助保持中央的提示清洁。 在不同的Linux机器上，开发人员之间共享代码的好方法是什么？ 我是Mercurial的新手。 我能想到的select（通过阅读而不是经验）是：
1：作者提交所有本地更改和更新与中央的提示工作克隆。 如果有一种方法可以指定捆绑包中包含哪些本地转速，那么作者使用hg捆绑包。 （一个实验显示我“捆绑”只抓取未被改变的变化，即使有以前的本地提交中央不知道）作者获取包文件审查。 审阅者从中央的提示创build一个新的干净的克隆，并将该包导入该克隆。 要么，
2：作者和审稿人从中心的提示中取出后，作者使用补丁和审稿人input补丁。 要么，
3：作者推荐审稿人或审稿人从作者（但是究竟是如何，究竟是什么？）读取的只是关于推送和从原来服务的存储库中，和/或在同一个盒子上，而不是在不同的linux盒子之间。
4：在推送到中央之前忘记检查代码; 继续推进，使用标签来标识已经评论过的内容，并使用Hudson（已经在工作）来标记最新的安全构build，以便团队成员可以知道哪一个可以从中获得。
如果您的团队使用Mercurial并进行代码审查，那么您如何才能让审阅者看到您的更改？
其中大部分都是可能的，有些比其他更繁琐。
--base使用捆绑： hg bundle --base 4a3b2c1d review.bundle hg serve ，你将能够拉动。 在你提出的选项中，＃1和＃3可能是最简单的，这取决于你是否可以到达对方的盒子。
在相关说明：这是让我的同事，我开始开发窑 ，我们的（雾溪）Mercurial托管和代码审查工具的问题。 我们的计划和最初的原型将会保留多个版本库，一个“中央”版本库和一些“审查”版本库。 审查过程将通过将中央仓库复制到服务器上的评论仓库中开始，然后在两者之间运行完整的仓库回购比较，并使用简单的Web界面获取和查看差异。
我们已经对这个工作流程进行了一些改进，但是总体思路是，将分支回购推送给未经审查的变更以及在将它们推入中央回购之前对其进行审查的界面仍然是一样的。 我不想在这里做广告，但我建议尝试一下 。
这个问题的一半答案是使用ReviewBoard Mercurial扩展 。 它允许通过发出以下命令来推送某些修订版本以供审阅
hg postreview提示
我将添加第五个选项 – 在命名分支上进行所有的开发工作，最好每个任务一个。 允许任何东西被提交给一个名为“development”的分支，无论它是否处于工作状态。
推送到中央存储库，让审阅者拉分支。 在分支上执行审查。
审核通过后，将开发工作合并到相应的功能分支中。
这个工作流程（这对我来说）令人惊讶地不受欢迎，有很多优点：
所有的工作都得到了承诺 – 在提交之前，您不必等待审查。
你不会建立错误的版本。 你只能从功能分支构建。
正在进行的工作不会干扰其他开发者。
在开发分支中，您可以查看最新的变化（例如，查看评论意见的变更集），与分支点进行比较，或者与最新的功能分支进行比较 – 所有这些都可以提供有用的信息。