С первого прочтения звучит так, будто вы хотите убедиться, что клон репозитория является клоном правильного репозитория, а не каким-то резервным самозванцем.Однако, если идентификационная информация, которую вы собираетесь использовать, клонируется со всем остальным, тогда самозванец все равно пройдет этот тест.Вы должны хранить этот идентификатор отдельно, чтобы его можно было сравнивать с информацией в клоне.
Независимо от того, является ли это вашей целью или нет, любой файл в .hg, который клонируется, вы, возможно, не захотите редактировать,Вам нужно добавить файл для отслеживания в других областях репо, кроме .hg.Однако на самом деле вам не нужен дополнительный файл вообще, поскольку хеш-код набора изменений не просто около определенного, но очень точного, поэтому информация для удобной идентификации хранилища встроена в само хранилище..
В командной строке вы можете получить короткие или полные версии самого хеш-идентификатора самого первого набора изменений:
> hg id -i -r0
89abf5502e3c
> hg log -r0 --template "{node}"
89abf5502e3c5c65e532db04d8d87141f0ac8b73
Если я не ошибаюсь в вашем желании сравнить 2 идентификатора, чтобывы или кто-то еще знаете, что клон репозитория является истинным клоном, а не ложным клоном, у вас будет один и тот же идентификатор набора изменений, доступный отдельно, чтобы кто-то мог использовать одну из указанных выше команд, чтобы увидеть идентификатор своего клона и сравнить его счто вы говорите, так и должно быть.Это очень похоже на то, как много веб-сайтов с загружаемыми исполняемыми файлами показывают хеш-идентификатор рядом со ссылкой на скачивание, так что вы можете сами хешировать файл и сравнивать результат с хешем на веб-сайте.
Редактировать относительно вашего комментария, который проливает свет на цель этого :
Так как вам нужно иметь возможность прочитать его из файла, есть пара вариантов:
Отслеживаемый файл в корне репозитория
Существует один файл, который вы можете рассмотреть, кроме создания собственного: .hgtags.
hg tag -r0 ident
... помечает самую первую ревизию, позволяявы должны использовать ident как ссылку на этот набор изменений, а не -r0.Mercurial всегда использует информацию тегов из последней версии .hgtags, независимо от того, какой набор изменений обновляет рабочий каталог, но это может не иметь значения для вашего приложения.hg tag добавляет такую строку в файл .hgtags, создавая файл, если он не существует:
a247494248c4b96a571bbd12e90eade3bf559281 ident
Это наиболее удобно, если у вас еще нет файлов тегов вваши репозитории, потому что это будет первая строка в файле для легкого поиска.Вы можете подумать, что можете просто написать этот файл самостоятельно, но тогда вам все равно придется позвонить hg, чтобы получить идентификатор набора изменений, и снова в какой-то момент, чтобы добавить его в отслеживание и затем зафиксировать: hg tag сделает все это за вас.
Если уже есть возможность рассмотреть файл тегов, это тоже нормально, потому что они, как правило, относительно короткие, и вам просто нужно найти 1 строку, которая заканчивается выбранным вами именем тега.Mercurial предназначен только для операций добавления к .hgtags, но все будет работать нормально, если вы вставите строку для этого тега в качестве самой первой строки, если .hgtags уже существует, потому что: 1. Тег никогда не будет перемещен или удален,2. Вы будете использовать имя тега, еще не использованное в этом файле.
Чтение кишок hg
Есть файлы, которые обычно только в самой Mercurial затрагиваются глубже в .hgэто можно прочитать, чтобы получить хэш первого набора изменений.Я посмотрел в форматах файлов Mercurial , Revlog и RevlogNG , и, по крайней мере, для 2 моих собственных репозиториев .hg\store\00changelog.i содержит хэш первого набора изменений со смещением0x20 (длина 20 байт).Вероятно, по крайней мере, начиная с Mercurial 0.9, он будет одинаковым во всех репо.RevlogNG также отмечает, что первые 4 байта этого файла будут указывать номер версии RevB и флаги.Хотя идентификатор набора изменений в настоящее время имеет длину всего 20 байтов, фактическое поле для него имеет длину 32 байта, вероятно, для будущего расширения до более длинного хэша.
Поскольку эта опция не требует изменения существующих репозиториев и включает в себя только чтение первых 52-64 байтов основного индекса, я, вероятно, пойду с этим. Если бы я ловил это требование на ранних стадиях продукта до того, как какие-либо репозитории, которыми он управляет, вышел в дикую природу, я бы склонялся к пользовательскому подходу к файлам, потому что у меня, вероятно, был бы мой собственный файл метаданных, созданный и добавленный с начала репо .