Монотонно-возрастающий номер версии на основе Mercurial Commits

Когда я использовал subversion для кода для приложения, я мог бы добавить период и результат svnversion к номеру версии, чтобы создать уникальный и монотонно увеличивающий номер версии, а также гарантировать, что любая регистрация той же версии кода будет генерировать тот же номер версии.

В Mercurial, поскольку номера версий не обязательно согласованы между клонами, локальный номер ревизии не подходит. Хэш является уникальным и последовательным, но не создает число, увеличивающее монотонность. Как я могу создать подходящее число для добавления к номеру версии на основе репозитория Mercurial?

edit: У меня есть приложение, которое имеет автоматическую проверку обновлений, которая зависит от номера версии, которая представляет собой цепочку целых чисел, разделенных периодом, для определения того, является ли новая версия новой или нет. Общепринято, что во время между выпусками у меня есть некоторые пользователи, которые тестируют тестовые сборки. Часто эти сборки решают проблему, испытываемую тестером, поэтому тестер останавливает использование выпущенной версии и переключается на тестовую сборку. Мои первоначальные цели в добавлении дополнительного компонента к номеру версии были следующими:

убедитесь, что при выпуске релиза те, кто использует тестовую сборку, также были автоматически обновлены.
быть в состоянии легко сказать, использовал ли тестер самую последнюю тестовую сборку

Например, версия 0.5.0 имела номер версии 0.5.0.410; до выпуска 0,5,1, были установлены тестовые сборки с номерами версий 0.5.1.411, 0.5.1.420 и 0.5.1.421; то выпуск 0.5.1 имел номер версии 0.5.1.423.

Ответ 1

Все еще нуждаясь в чем-то, чтобы попытаться поддерживать упорядочение и сопоставление различных сборок разработки, я сначала попытался использовать временную метку unix для последнего коммита:

REV=$(hg tip --template '{date|hgdate}' | cut -f1 -d' ')

Это, однако, досадно долго (10 цифр). (И, конечно же, он не гарантированно будет уникальным, но в проекте, где я единственный разработчик, вероятность двух коммитов за одну секунду составляет по существу 0; на самом деле вероятность двух коммитов в течение 1 минуты друг друга по существу 0.)

Поскольку "базовый" номер версии (часть, к которой добавляется этот номер версии), изменяется только сразу после выпуска с тегами, то, что я использовал, - это количество минут между подсказкой и последним предшественником с тегами:

HG_LAST_TAG_TIMESTAMP=$(hg log -r "$(hg log -r '.' --template '{latesttag}')" --template "{date|hgdate}\n" | cut -f1 -d' ')
HG_TIP_TIMESTAMP=$(hg log -r '.' --template "{date|hgdate}\n" | cut -f1 -d' ')
REV=$(( ($HG_TIP_TIMESTAMP - $HG_LAST_TAG_TIMESTAMP) / 60 ))

(изменение: использование tip было ошибкой, так как оно относится к последней фиксации любой ветки; использование log -r '.' относится к ревизии, на которой основана рабочая копия.)

Ответ 2

Как сказал @Matthew, вы не можете ожидать, что какое-либо сравнение между номерами версий через клоны будет иметь какое-либо значение. Однако, если вы создаете приложение вокруг одного репозитория и всегда возвращаетесь в этот центральный репозиторий из любых клонов, тогда вы можете положиться на этот единственный номер центральной версии, пока вы придерживаетесь одной ветки.

По сути, если вы используете Mercurial таким образом, который имитирует Subversion, т.е. с одним центральным репозиторием, вы можете использовать номер версии в качестве маркера в своих приложениях.

Надеюсь, что это поможет.

Ответ 3

Вот как Fog Creek выполняет построение версий с использованием Mercurial + некоторых других предложений: http://kiln.stackexchange.com/questions/2194/best-practice-generating-build-numbers

Ответ 4

Ты в значительной степени ударил ноготь по голове. Использование любого монотонно возрастающего локального номера ревизии может противоречить распределенной природе. Нет никакого элегантного пути вокруг этого фундаментального дизайнерского решения.