Выполнение исторических сборок с помощью Mercurial

Предпосылки

Мы используем модель центрального репозитория для координации отправки кода между всеми разработчиками моей команды. Наша автоматизированная система ночной сборки имеет отсечку для отправки кода каждое утро в 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 внесена. это в сборку, в то время как изменения в Revision 2 должны были быть включены в сборку следующего утра (как часть Revision 3). Пока все хорошо.

Задача

Сегодня я хочу восстановить первоначальную сборку. На первый взгляд очевидные шаги для этого -

  1. определить ревизию, которая была в исходной сборке,
  2. обновить эту ревизию и
  3. выполнить сборку.

Проблема возникает на шаге 1. В отсутствие отдельно записанной ревизии репозитория , как я могу окончательно определить, какая ревизия репозитория использовалась в исходной сборке? Все ревизии находятся в одной и той же названной ветке, и никакие теги не используются.

Команда log

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

дает Версия 2 - а не Версия 1, которая была в исходной сборке!

Теперь я понимаю, почему это происходит - версия 2 теперь является версией, наиболее близкой ко времени окончания сборки, но это не меняет того факта, что я не смог определить правильную ревизия, которую нужно перестроить.

Таким образом, если я не могу использовать параметр - date команды log , чтобы найти правильную историческую версию, какие другие средства доступны чтобы определить правильный?

6
задан kopaka 25 June 2014 в 20:56
поделиться