2012-05-24 6 views
4

У нас есть приложение Java под контролем Mercurial. Мы работаем над внедрением в приложение versioning schema, и мне интересно, как TortoiseHG может помочь в этом. Можно ли сделать что-то вроде приращения версии сборки, когда совершаются коммиты, или это должно быть сделано до разработчика? Наш текущий план включает создание закладок для каждого номера версии, когда мы отправляемся в UAT.Форсировать номера версий с TortoiseHG

ответ

9

В принципе, вы должны сделать это за пределами TortoiseHg - работа Mercurial (и, следовательно, TortoiseHg) заключается в том, чтобы сохранить состояние вашей рабочей копии точно так, как было, когда вы нажали «Commit».

Возможно, вам поможет небольшая помощь: TortoiseHg может инициировать это «внешнее» действие с помощью pre-commit hook. Это скрипт, который запускается до запуска hg commit, и этот скрипт имеет возможность изменять файлы.

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

Наконец, позвольте мне упомянуть, что Mercurial имеет latesttagdistance template keyword, который может быть очень полезен для централизованной машины сборки: он вычисляет расстояние до самого последнего тега, и это расстояние, как правило, монотонно увеличивается на машине сборки. Используйте его как

hg parents --template "{latesttag}+{latesttagdistance}-{node|short}" 

См. Mercurial setup.py file для большего количества вдохновения.

3

Лучше всего, чтобы система сборки вставляла текущий идентификатор версии в ваш архив распространения и/или имя файла.

Первый вопрос: как вы приобретаете этот идентификатор версии. Существует, в основном, три способа:

  1. Предоставив серверу сборки команду hg id, чтобы узнать ошибку сборки.
  2. Имея файл version, который заполнен крюком changegroup, настроенным в конфигурации вашего Mercurial repo.
  3. С помощью файла version, который заполняется с помощью расширения ключевого слова. (Не рекомендуется!)

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

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

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

Возможно, лучше всего пойти на гибридный подход 1 и 2, который сначала попытается приблизиться к 2, и опустится на подход 1, когда файл version не найден. Чтобы лучше поддерживать hg archive источник экспорта, вы также можете проверить файл .hg_archival.txt.

Второй вопрос в том, какие ценности вы используете номер сборки:

  1. Идентификатор версии (от hg id -i).
  2. Номер местной редакции (от hg id -n).
  3. Идентификатор с использованием latesttag и latesttagdistance, см. Ответ Мартина.

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

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

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