Насколько хорош мой метод встраивания номеров версий в мое приложение с использованием хуков Mercurial?

Question

Это не совсем конкретный вопрос, и мне больше нравится критика моего нынешнего подхода.

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

Мой метод работает следующим образом:

1. В моей ссылке на файл .hg / hgrc на version_gen.sh
2. version_gen.sh состоит исключительно из: hg parent --template "r{rev}_{date|shortdate}" > version.num
3. В make-файле строка version="%__VERSION__% в основном скрипте заменяется содержимым файла version.num.

Есть ли лучшие способы сделать это? Единственный реальный недостаток , который я вижу , заключается в том, что если вы фиксируете только конкретный файл, version.num будет обновляться, но не будет зафиксирован, и если я попытался добавить, всегда фиксирующий файл это приведет к бесконечному циклу (если я не создал временный файл, чтобы указать, что я уже был в коммите, но это выглядит ужасно ...).

Answer 1

проблема

Как вы уже определили, вы действительно создали ситуацию 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. В make-файле убедитесь, что version_gen.sh запущен до того, как version.num используется для установки параметра версии.

Мои причины

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

То, что вы пытаетесь сделать, называется расширением ключевых слов, которое не поддерживается в ядре Mercurial .

Вы можете интегрировать это расширение в make file или (проще) с расширением Keyword .

Это расширение позволяет расширять RCS / CVS-подобные и определяемые пользователем ключи в текстовых файлах, отслеживаемых Mercurial.
Расширение происходит в рабочем каталоге или / и при создании дистрибутива с использованием "hg archive"

Answer 4

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

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

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