Монотонно увеличивающийся номер версии на основе Mercurial Commits

Question

Когда я использовал 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.

Answer 1

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

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

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

Answer 2

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

Answer 3

Все еще нуждаясь во что-то, чтобы попытаться поддерживать порядок и соответствие различных сборок разработки, я сначала попытался использовать метку времени 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 ))

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

Answer 4

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