date - 使用 Mercurial 执行历史构建

Question

背景

我们使用中央存储库模型来协调团队中所有开发人员之间的代码提交。我们的自动化夜间构建系统每天早上 3 点的代码提交截止时间，此时它会将最新代码从中央存储库提取到自己的本地存储库。

几周前，执行了一个包含 的构建。修订版 1 的 repo 。那时，构建系统并没有以任何方式跟踪用于执行构建的存储库的修订版(谢天谢地，它现在这样做了)。

  -+------- Build Cut-Off Time
   |
   |
   O    Revision 1

在构建截止时间前一小时，开发人员分支了存储库并在他们自己的本地副本中提交了一个新修订。他们没有在截止之前将其推回中央仓库，因此它不包含在构建中。这将是 修订版 2 在下图中。

  -+------- Build Cut-Off Time
   |
   | O  Revision 2
   | |
   | |
   |/
   |
   O    Revision 1

构建后一小时，开发人员将他们的更改推送回中央仓库。

   O    Revision 3
   |\
   | |
  -+-+----- Build Cut-Off Time
   | |
   | O  Revision 2
   | |
   | |
   |/
   |
   O    Revision 1

因此，修订版 1 将其纳入构建，而修订版 2 中的更改将包含在第二天早上的构建中(作为修订版 3 的一部分)。到现在为止还挺好。

问题

现在，今天，我想重建原始版本。看似显而易见的步骤是

确定原始版本中的修订版，

更新到那个版本，和

执行构建。

问题出现在第 1 步。在没有单独记录的存储库修订的情况下，我如何才能明确确定原始构建中使用了存储库的哪个修订？所有修订都在同一个命名的分支上，并且不使用任何标签。
log命令

  hg log --date "<cutoff_of_original_build" --limit 1

给 修订版 2 - 不是原始版本中的修订版 1!

现在，我明白为什么会这样了——修订版 2 现在是最接近构建截止时间的修订版——但这并没有改变我未能确定要重建的正确修订版的事实。

因此，如果我不能使用 --date log 的选项命令找到正确的历史版本，还有什么其他方法可以确定正确的？

Answer 1

考虑到撤消文件中可能存在的任何历史记录现在已经消失(我能想到的唯一可以给出指示的东西)，我认为将其缩小到特定修订的唯一方法是蛮力方法。

如果可能的修订范围有点大，并且建筑物大小或其他非日期方面的变化是线性的或足够接近线性的，您可以使用 bisect 命令基本上进行二进制搜索以缩小您正在寻找的修订版(或者可能只是接近它)。在每个版本中，bisect停止测试，您将在该修订版上构建并测试您使用的任何方面，以与当晚计划的构建进行比较。取决于测试，甚至可能不需要构建。

如果它真的像您描绘的图表一样简单并且可能性范围很短，那么您可以从可能的最新版本开始，然后向后走几个版本，针对原始版本进行测试。

至于比较两个构建的最终测试，散列测试构建并将其与原始构建的哈希进行比较可能有效。如果在夜间构建机器上的编译和在您的机器上的相同版本的编译不会产生二进制相同的构建，您可能必须使用二进制差异(例如使用 xdelta 或 bsdiff )并寻找最小的差异。

Mercurial 没有您想要的信息:

Mercurial 并没有开箱即用地记录和跟踪对存储库执行的每个操作，例如 push , pull , update .如果是这样，它将产生大量的日志信息。它确实提供了可用的钩子(Hook)，如果有人愿意，可以使用它来做到这一点。

它也不关心你对工作目录的内容做了什么，例如打开文件或编译，所以它当然不会跟踪它。这根本不是 Mercurial 所做的。

不确切知道计划的构建正在构建什么是错误的。您默认同意，因为您现在记录了该信息。之前缺乏这些信息只会反过来咬你，而且没有简单的方法可以摆脱它。 Mercurial 没有您需要的信息。如果中央存储库只是一个共享目录，而不是可能跟踪事件的 Web 托管存储库，则有关所构建内容的唯一信息是在编译版本中。无论是在源代码中声明的一些元数据成为构建的一部分，还是像文件大小这样幼稚的方面，或者您真的被散列文件卡住了，您都无法不费吹灰之力就得到答案。

也许您不需要测试每个修订版；可能会有一些修订，你可以确定不是候选人。知道编译时间只是作为测试修订范围上限的一个因素。你知道在那之后的修订不可能是候选人。您不知道的是在构建服务器从中提取时推送到服务器的内容。但是您确实知道，从那天开始的修订是最有可能的。您还知道，与线性修订和 merge 相比，并行未命名分支中的修订不太可能成为候选者。如果有很多并行的未命名分支，并且您知道所有开发人员都以特定方式 merge ，您可能知道是否应该基于 parent1 或 parent2 下的修订进行测试。

如果您可以从源代码中解析元数据以与您对特定构建的了解进行比较，那么您甚至不需要编译。

您可以自动执行搜索。使用线性搜索最容易做到这一点:设计的启发式更少。

最重要的是，Mercurial 在这种情况下没有提供帮助的魔术按钮。