10

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

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

2：作者和审稿人都从中心的tip中获取后，作者使用补丁，审稿人导入补丁。或者，

3：作者推送给审稿人或审稿人从作者那里拉取（但如何，确切地说？我读到的只是关于向/从原始服务存储库推送和拉取，和/或在同一个盒子上而不是在不同的 linux 盒子之间。）

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

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

4

3 回答 3

6

其中大部分是可能的，有些比其他的更乏味。

  1. 您可以通过将中央仓库的提示指定为--base：
    hg bundle --base 4a3b2c1d review.bundle
  2. 还不如只使用捆绑。这样，变更集数据也包括在内。
  3. 您可以向（从）任何具有共同祖先的存储库推送（和拉取）。如果你想从你的一位同事那里拉，他们只需要hg serve在他们的机器上运行，你就可以拉。
  4. 这也有效，但您必须维护多个头并小心合并。如果您不这样做，那么在未经审查的变更集之上建立稳定的变更会变得很容易，如果您以后需要修复该未经审查的变更集，这将很难撤消。

在您提供的选项中，#1 和 #3 可能是最简单的，这取决于您是否可以到达彼此的盒子。

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

我们已经对该工作流程进行了相当大的改进，但总体思路仍然是相同的，即拥有一个分支存储库来将未审查的更改推送到，并在将它们推送到中央存储库之前对其进行审查。我不想在这里做广告，但我建议尝试一下。

于 2010-08-27T17:05:27.227 回答
3

这个问题的一半答案是使用带有Mercurial 扩展的ReviewBoard。它允许通过发出以下命令来推送某些修订以供审查

hg postreview 提示

于 2011-06-08T22:29:27.427 回答
2

我将添加第 5 个选项 - 在命名分支上进行所有开发工作，最好是每个任务一个。允许将任何内容提交给名为“开发”的分支，无论它是否处于工作状态。

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

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

这个（对我来说）非常不受欢迎的工作流程有很多优点：

  1. 所有工作都已提交 - 您不必等待审核完成后再提交。

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

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

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

于 2013-04-15T22:04:30.493 回答