Question

Background

We use a central repository model to coordinate code submissions between all the developers on my team. Our automated nightly build system has a code submission cut-off of 3AM each morning, when it pulls the latest code from the central repo to its own local repository.

Some weeks ago, a build was performed that included Revision 1 of the repo. At that time, the build system did not in any way track the revision of the repository that was used to perform the build (it does now, thankfully).

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

An hour before the build cut-off time, a developer branched off the repository and committed a new revision in their own local copy. They did NOT push it back to the central repo before the cut-off and so it was not included in the build. This would be Revision 2 in the graph below.

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

An hour after the build, the developer pushed their changes back to the central repo.

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

So, Revision 1 made it into the build, while the changes in Revision 2 would’ve been included in the following morning’s build (as part of Revision 3). So far, so good.

Problem

Now, today, I want to reconstruct the original build. The seemingly obvious steps to do this would be to

1. determine the revision that was in the original build,
2. update to that revision, and
3. perform the build.

The problem comes with Step 1. In the absence of a separately recorded repository revision, how can I definitively determine what revision of the repo was used in the original build? All revisions are on the same named branch and no tags are used.

The log command

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

gives Revision 2 – not Revision 1, which was in the original build!

Now, I understand why it does this – Revision 2 is now the revision closest to the build cut-off time – but it doesn’t change the fact that I’ve failed to identify the correct revision on which to rebuild.

Thus, if I can’t use the --date option of the log command to find the correct historical version, what other means are available to determine the correct one?

Answer 1

Apologies, it’s probably bad form to answer one’s own question, but there wasn’t enough room to properly respond in a comment box.

---

To Joel, a couple of things:

First – and I mean this sincerely – thanks for your response. You provided an option that was considered, but which was ultimately rejected because it would be too complex to apply to my build environment.

Second, you got a little preachy there. In the question, it was understood that because a separately recorded repository revision was absent, there would be ‘some effort’ to figure out the correct revision. In a response to Lance’s comment (above), I agree that recording the 40-byte repository hash is the ‘correct’ way of archiving the necessary build info. However, this question was about what CAN be done IF you do not have that information.

To be clear, I posted my question on StackOverflow for two reasons:

1. I figured that others must have run into this situation before and that, perhaps, someone may have determined a means to get at the requisite information. So, it was worth a shot.
2. Information sharing. If others run into this problem in the future, they will have an online reference that clearly explained the problem and discussed viable options for remediation.

---

Solution

In the end, perhaps my greatest thanks should go to Chris Morgan, who got me thinking to use the central server’s mercurial-server logs. Using those logs, and some scripting, I was able to definitively determine the set of revisions that were pushed to the central repository at the time of the build. So, my thanks to Chris and to everyone else who responded.