Учитывая, что какая-либо история, которая могла быть в файлах отмены, к настоящему времени утрачена (единственное, что я могу придумать, это может дать указание), я думаю, что единственным способом сузить ее до конкретной ревизии будет грубая сила подход.
Если диапазон возможных ревизий немного велик, а продукт здания изменяется по размеру или другой не датированный аспект, который является линейным или достаточно близким к линейному, вы можете использовать bisect* Команда 1005 * в основном выполняет бинарный поиск, чтобы сузить, какую ревизию вы ищете (или, возможно, просто приблизиться к ней). При каждой ревизии, которую bisect останавливает для тестирования, вы будете собирать эту ревизию и тестировать любой аспект, который используете, чтобы сравнить с тем, что запланированная сборка произвела той ночью. Может даже не требовать сборки, в зависимости от теста.
Если это действительно так просто, как график, который вы изображаете, и диапазон возможностей невелик, вы можете просто начать с последней ревизии, которой она может , и пройти несколько ревизий в обратном направлении, проверяя оригинал строить.
Что касается окончательного теста, сравнивающего две сборки, то может сработать хеширование сборки теста и сравнение ее с хешем исходной сборки. Если компиляция на машине ночной сборки и компиляция на вашей машине той же ревизии не производят двоичные идентичные сборки, вам, возможно, придется использовать двоичное различие (например, с xdelta или bsdiff ) и найдите наименьшую разницу.
У Mercurial нет нужной вам информации:
Mercurial не ставит перед собой задачу регистрировать и отслеживать каждое действие, выполненное в отношении хранилища, такое как push, pull, update. Если бы это было так, то было бы много информации. Он делает доступными крючки, которые можно использовать для этого, если кто-то этого желает.
Также не важно, что вы делаете с содержимым рабочего каталога, например, открываете файлы или компилируете, поэтому, конечно, это вообще не будет отслеживаться. Это просто не то, что делает Mercurial.
Было ошибкой не знать точно, что строила запланированная сборка. Вы соглашаетесь неявно, потому что теперь вы регистрируете именно эту информацию. Недостаток этой информации раньше просто вернулся, чтобы укусить вас, и нет легкого выхода из этого. У Mercurial нет нужной вам информации. Если центральное хранилище - это просто общий каталог, а не веб-хранилище, в котором может быть отслежена активность, единственная информация о том, что было построено, находится в скомпилированной версии. Будь то некоторые метаданные, объявленные в источнике, которые становятся частью сборки, наивный аспект, такой как размер файла, или вы действительно застряли в хэшировании файлов, вы не сможете получить ответ без особых усилий.
Может быть, вам не нужно проверять каждую ревизию; могут быть изменения, которые вы можете быть уверены, что они не являются кандидатами. Знание времени компиляции является лишь фактором, определяющим верхнюю границу диапазона ревизий для тестирования. Вы знаете, что изменения после этого времени не могли быть кандидатами. То, что вы не знаете, это то, что было отправлено на сервер во время извлечения сервера сборки с него. Но вы знаете, что пересмотры с того дня являются наиболее вероятными. Вы также знаете, что ревизии в параллельных неназванных ветвях являются менее вероятными кандидатами, чем линейные ревизии и слияния. Если имеется много параллельных неназванных ветвей, и вы знаете, что все ваши разработчики объединяются особым образом, вы можете знать, следует ли проверять ревизии в parent1 или parent2.
Может быть, вам даже не нужно компилировать, если есть метаданные, которые вы можете проанализировать из исходного кода, чтобы сравнить с тем, что вы знаете о конкретной сборке.
И вы можете автоматизировать свой поиск. Проще всего это сделать с помощью линейного поиска: меньше эвристики для проектирования.
Суть в том, что Mercurial не имеет волшебной кнопки, чтобы помочь в этом случае.