我在一个使用Mercurial作为中央存储库的小型分布式团队中。我们每个人都通过ssh将其克隆到我们自己的linux机器上。我们的目的是在将更改推送到中央存储库之前检查彼此的工作，以帮助保持中央的尖端清洁。在不同Linux机器上的开发人员之间共享代码的好方法是什么？我是Mercurial的新手。我可以想到的选项（通过阅读而不是经验）是：
1：作者提交所有本地更改，并使用Central的技巧更新可用的克隆。如果有一种方法可以指定要包含在捆绑包中的本地版本，则作者使用hg捆绑包。 （实验表明，“捆绑包”仅捕获未提交的更改，即使以前中央不知道的本地提交也是如此）作者将捆绑包文件提供给审阅者。审阅者从Central的尖端创建一个新的干净克隆，并将捆绑包导入到该克隆中。
要么，
2：在作者和审稿人都从Central的提示中获取信息后，作者使用补丁，审稿人导入了补丁。
要么，
3：作者推送到审稿人或审稿人从作者那里拉（但是，究竟如何？我读到的仅是关于向/从原始服务的存储库中和/或从同一服务器上拉入和拉出，而不是在不同的Linux盒之间拉入和拉出的信息。）
4：在推送到中心之前，忘记对代码进行审查；继续进行，使用标签来标识已审核或未审核的内容，并使用Hudson（已在工作）为最新的安全构建进行标签，以便团队成员可以知道要从中选择哪个。
如果您的团队使用Mercurial并进行代码审查，那么如何使审查者看到您的更改？
最佳答案
其中大多数是可能的，有些比其他的更乏味。
您可以通过将中央仓库的尖端指定为--base来使用bundle：hg bundle --base 4a3b2c1d review.bundle
也可以只使用捆绑软件。这样，变更集数据也包括在内。
您可以从具有公共祖先的任何存储库中推送（和拉出）。如果您想从您的一位同事那里拉，他们只需要在他们的计算机上运行hg serve，您就可以拉。
这也可以，但是您必须保持多个头并在合并时要小心。如果不这样做，将稳定的更改基于未审核的变更集变得很容易，如果以后需要修复该未审核的变更集，将很难撤消。
在您提出的选项中，＃1和＃3可能是最简单的，仅取决于您是否可以到达对方的盒子。
在相关说明中：这是我的同事提出的问题，我开始开发Kiln，这是我们（Fog Creek的）Mercurial托管和代码审查工具。我们的计划和最初的原型将保留多个存储库，一个“中央”存储库和一堆“审查”存储库。审阅过程将通过将中央存储库克隆到服务器上的审阅存储库中，然后在两者之间运行完整的存储库差异而开始，并通过一个简单的Web界面来获取和查看差异。
我们已经对该工作流程进行了相当多的改进，但是总体思路仍然是相同的，即拥有一个分支存储库以将未审阅的更改推送到该存储库，以及一个界面在将它们推送到中央存储库之前对其进行审阅。我不想在这里做广告，但是我建议giving it a try。