使用Mercurial执行历史构建

Question

背景

我们使用中央存储库模型来协调团队中所有开发人员之间的代码提交.我们的自动夜间构建系统每天凌晨3点都有一个代码提交截止日期,当时它将最新代码从中央存储库提取到自己的本地存储库.

几周前,执行了包含回购的修订版1的版本.那时,构建系统没有以任何方式跟踪用于执行构建的存储库的修订(现在,幸运的是).

  -+------- 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. 确定原始版本中的修订版本,
2. 更新到该修订版,并且
3. 执行构建.

步骤1中出现问题.在没有单独记录的存储库修订版的情况下,如何确定原始版本中使用的repo修订版？所有修订都在同一个命名分支上,并且不使用任何标记.

该log命令

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

给出了修订版2 - 而不是修订版1,它是在原始版本中!

现在,我理解为什么会这样做 - 修订版2 现在是最接近构建截止时间的修订版 - 但它并没有改变我无法确定要重建的正确修订版的事实.

因此,如果我不能使用命令--date选项log来查找正确的历史版本,还有哪些其他方法可用于确定正确的历史版本？

Answer 1

考虑到撤销文件中的历史记录现在已经消失了(我唯一能想到的就是可以给出指示),我认为将其缩小到特定修订版的唯一方法是蛮力方法.

如果可能的修订范围有点大并且构建的大小或其他非日期方面的变化是线性的或接近线性的,您可能能够使用该bisect命令基本上进行二进制搜索以缩小范围您正在寻找什么样的修订版(或者可能只是接近它).在每个bisect停止测试的修订版本中,您将构建该修订版本并测试您用于比较当晚生成的预定构建版本的任何方面.根据测试,甚至可能不需要建造.

如果它真的像你描绘的图形一样简单,并且可能性的范围很短,你可以从它可能的最新版本开始,然后向后走一些修改,对原始版本进行测试.

至于比较两个构建的最终测试,散列测试构建并将其与原始构建的散列进行比较可能有效.如果夜间构建机器上的编译和同一版本的机器上的编译不生成二进制相同的构建,则可能必须使用二进制差异(例如使用xdelta或bsdiff)并查找最小的差异.

Mercurial没有您想要的信息:

水银不,开箱即用,使之成为业务记录和跟踪每一个动作有关存储进行,比如push,pull,update.如果是这样,它将产生大量的日志信息.如果需要的话,它确实提供了可用于执行此操作的钩子.

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

如果不确切知道预定构建的内容是错误的.你暗示同意,因为你现在记录了这些信息.之前缺乏这些信息只是简单地回过头来咬你,而且没有简单的方法.Mercurial没有您需要的信息.如果中央存储库只是一个共享目录而不是可能跟踪活动的Web托管存储库,那么有关构建内容的唯一信息就是编译版本.无论是在源代码中声明的某些元数据成为构建的一部分,还是像文件大小这样天真的方面,或者你真的被困在哈希文件中,你无法轻易得到答案.

也许你不需要测试每个版本; 可能有一些修改你可以肯定不是候选人.知道编译的时间仅仅是作为测试修订范围的上限的一个因素.你知道那段时间之后的修改可能不是候选人.您不知道的是构建服务器从中拉出服务器时被推送到服务器的内容.但是你确实知道那天的修订是最有可能的.您还知道并行未命名分支的修订不太可能是线性修订和合并的候选者.如果有很多并行的未命名分支,并且您知道所有开发人员以特定方式合并,您可能知道是否应该基于parent1或parent2进行测试.

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

您可以自动执行搜索.使用线性搜索最简单:设计的启发式算法较少.

最重要的是Mercurial在这种情况下没有魔术按钮来帮助.

Answer 2

抱歉，回答自己的问题可能是不好的形式，但评论框中没有足够的空间来正确回复。

对乔尔来说，有几件事：

首先 - 我是真诚的 - 感谢您的回复。您提供了一个经过考虑的选项，但最终被拒绝，因为它太复杂而无法应用于我的构建环境。

其次，你有一点说教的成分。在该问题中，据了解，由于缺乏单独记录的存储库修订版本，因此需要“一些努力”来找出正确的修订版本。作为对 Lance 评论（上面）的回应，我同意记录 40 字节存储库哈希是归档必要构建信息的“正确”方法。然而，这个问题是关于如果您没有该信息可以做什么。

需要明确的是，我在 StackOverflow 上发布了我的问题，原因有两个：

1. 我想其他人一定也遇到过这种情况，也许有人已经找到了获取必要信息的方法。所以，值得一试。
2. 信息共享。如果其他人将来遇到这个问题，他们将有一个在线参考，清楚地解释了问题并讨论了可行的补救方案。

解决方案

最后，也许我最大的感谢应该归功于 Chris Morgan，他让我考虑使用中央服务器的Mercurial-server日志。使用这些日志和一些脚本，我能够明确确定在构建时推送到中央存储库的修订集。所以，我感谢克里斯和其他所有做出回应的人。