Насколько хороший мой метод встраивания номеров версий в мое приложение с помощью Подвижных рычагов?

То, что вы используете хук pre-commit, вот что беспокоит. Вы не должны помещать остаток version_gen.sh в исходные файлы thesemves, только в артефакты сборки/релиза, что вы можете сделать более точно с помощью хука 'update'.

Вы не хотите, чтобы Makefile действительно изменялся в репозитории с каждым коммитом, это просто превращает слияние в ад. Вы хотите вставлять версию после проверки файлов перед сборкой, что и делает хук update.

В распределенных системах, таких как Mercurial, фактический «номер версии» не обязательно означает одно и то же во всех средах. Даже если это проект для одного человека, и вы очень осторожны, имея только свое центральное репо, вы все равно, вероятно, захотите использовать вместо него sha1-sum, поскольку это действительно уникально для данного состояния репозитория. Sha1 можно получить через шаблон {node}

В качестве предложения я думаю, что лучше использовать вместо них теги, которые, кстати, также являются локальными для вашего репозитория, пока вы не отправите их вверх по течению. Не записывайте свой номер в файл, а вместо этого пометьте код выпуска значимым тегом, например
RELEASE_2
или
RELEASE_2010-04 -01
или, может быть, сценарий и использование шаблона для создания тега?

Затем вы можете добавить тег в свой не версионированный (в .hgignore) файл version.num, который будет добавлен в сборка. Таким образом вы можете дать выпускам осмысленные имена и привязать выпуск к уникальному идентификатору.

Проблема

Как вы определили, вы действительно создали ситуацию Catch-22 здесь.

Вы не можете поместить значимую информацию в файл version.num до фиксации изменений, а поскольку вы храните version.num в хранилище, вы не можете зафиксировать изменения в хранилище, пока не заполните файл version.num.

Мое решение

Я бы предложил следующее:

1. Избавьтесь от хука "pre-commit" и hg forget файла version.num.
2. Добавьте version.num в файл .hgignore.

3. Настройте version_gen.sh следующим образом:

   hg parent --template "r{node|short}_{date|shortdate}" > version.num

4. В makefile убедитесь, что version_gen.sh будет запущен до того, как version.num будет использован для установки параметра версии.

Мои причины

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

Однако я бы не рекомендовал этого делать - в моей собственной системе сборки сборка не удавалась, если не удавалось извлечь информацию о ревизии.

Кроме того, как советует @Kai Inkinen, использование номера ревизии не является переносимым. Ревизия 21 на одной машине может быть ревизией 22 на другой. Хотя сейчас это может и не быть проблемой, но может стать в будущем, если вы начнете сотрудничать с другими людьми.

Наконец, я объясняю причины, по которым мне не нравится расширение Keyword, в вопросе, который затрагивает проблемы, схожие с вашим вопросом:

Я рассматривал расширение Mercurials Keyword, поскольку оно казалось очевидным решением. Однако чем больше я смотрел на него и читал мнения людей, тем больше приходил к выводу, что это не то, что нужно.

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

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

Затем в комментариях к ответу, в котором предлагалось использовать расширение keyword:

... Я отказался от использования расширения ключевого слова, поскольку было бы слишком легко закончить тем, что строка "$Id$" будет скомпилирована в исполняемый файл. Если бы расширение ключевых слов было встроено в mercurial, а не в расширение, и было бы включено по умолчанию, я мог бы рассмотреть этот вариант, но в нынешнем виде это было бы просто ненадежно. - Марк Бут

Я не думаю, что может быть более надежное решение. Что если кто-то случайно повредит .hg или будет собирать не из клона, а из архива? - Mr.Cat

@Mr.Cat - Я не думаю, что может быть менее надежное решение, чем расширение keywords. Везде, где вы явно не включили расширение (или кто-то отключил его), вы получите литеральную строку "$ID$", скомпилированную в объектный файл без каких-либо претензий. Если mercurial или репозиторий повреждены (не уверен, что вы имели в виду), вам в любом случае нужно сначала исправить это. Что касается hg archive, мое оригинальное решение не компилируется, если вы пытаетесь собрать его из архива! Это именно то, чего я хочу. Я не хочу, чтобы исходники компилировались в наши приложения без контроля ревизий! - Mark Booth