Как найти самый последний тег для текущей ревизии в Git/HG / Bzr?

В настоящее время в моей практике я использую файл версии для хранения: 

major=2
minor=0
fix=1

Что означает, что исходники для продукта версии v2. 0. 1 или новее.

Перед каждым релизом я должен фиксировать обновление этого файла, поэтому тег с именем tag2. 0. 1 или release-2.0.1 покрывает содержимое выше (а не предыдущую версию!).

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

Посмотрите на историю rev: 

  +--+-----+----------------------+-YY--+----+------+------+-HH-->
  dev|     |            ^     ^   |     |    |      |      |
     |     |            |     |   |     |    v      v      v
     |     |            |     |   |     |    +--+------+-ZZ---+-->
     |     |            |     |   |     |    b2 |      |      |
     |     |            |     |   |     |       v      v      v
     |     |            |     |   |     |      t2.0.0 t2.0.1 t2.1.0
     v     v            |     |   v     v
    t0.1.0 +---+--XX--+-+---+-+-----+------+------+------+------+--->
           b1  |      |     |       |      |      |      |      |
               v      v     v       v      v      v      v      v
              t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3

В точке XX версия 1.0.0, в точке YY версия является 1.0.2, в точке ZZ версия является 2.0.1.

Для точки HH - это не знаю, как установить версию. Я думаю, что так и должно быть.1.0.2, потому что мы не сливаем ветвь dev с ветвью release b2.

Я читаю: 

  $ hg help revsets

Но не вижу, как я могу найти ближайший тег к данной ревизии. С Git и Bzr у меня меньше опыта...

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

ПС.Файл версии, необходимый для поддержания зависимости пакета и идентификации исходного состояния продукта в отзывах пользователей.

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

5 2
mercurial version-control branch bazaar

5 ответов:

Вы могли бы использовать что-то вроде этого: 

hg log --template "{latesttag}-{latesttagdistance}-{node|short}\n" --rev <REV>

, который возвращает строку типа:

2.1.4-2-12eeab7a8073

Это говорит нам о том, что:

  • самый последний тег перед этим коммитом был 2.1.4
  • текущая ревизия - это 2 коммита мимо этого тега
  • идентификатор набора изменений-12eeab7a8073

Прочитайте о шаблонах для получения дополнительной информации.

Git имеет встроенный describe команда, которая обеспечивает то же самое информация. Однако вы должны понимать, что по умолчанию он работает только с аннотированными тегами (Подробнее см. man-страницу).

5

bzr tags --sort=time | tail -n1 | cut -d ' ' -f1

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

Вы даже можете создать внешний псевдоним bzr с помощью плагина extcommand. bzr branch http://bzr.oxygene.sk/bzr-plugins/extcommand/ ~/.bazaar/plugins

Затем вы можете добавить следующее К ~/.bazaar/bazaar.conf 

[EXTERNAL_ALIASES]
last-tag = bzr tags --sort=time | tail -n1 | cut -d ' ' -f1

Тогда вы можете сделать: 

$bzr last-tag
v0.9.0-SNAPSHOT
3

Вы смотрели на git describe для мерзавца? Он покажет самый последний тег, который доступен из фиксации.

2

У Git есть команда, которая точно предназначена для этого: git-describe. Как именно его использовать, зависит от ваших потребностей, но в целом git describe [opts] <commit> выдает что-то в виде <tag>-<n-commits>-<short-hash>, сообщая вам самый последний тег, сколько коммитов было сделано с тех пор, и сокращенный хэш коммита. Например, он может дать вам v1.7.8-rc0-32-g87bf9a7.

Соответствующие варианты:

  • --tags - включить все теги, а не только аннотированные теги. Ты, наверное, этого хочешь.
  • --match <pattern> - включить только соответствующие теги данный шаблон, так что вы можете ограничиться версиями тегов и ничего постороннего.
  • --abrev=<n> - Используйте n цифры хэша (установите 0, чтобы подавить его)

И еще несколько - смотрите manpage.

Что касается вашего файла версии: вы обычно не должны отслеживать его. Необходимость вносить в него изменения обречена на провал; фиксация содержит файл, и поэтому версия (слегка) изменяется, когда вы изменяете ее и фиксируете. Вместо этого вы можете автоматически сгенерировать его как часть процесса сборки / развертывания,а также включить его в исходные дистрибутивы. Вы можете посмотреть на источник Git для хорошего примера этого-есть скрипт под названием GIT-VERSION-GEN , который вызывается файлом Makefile и по сути является легкой оболочкой вокруг git-descript. Он создает файл версии, который затем упаковывается в исходные тарболы, и содержимое которого используется остальной частью процесса сборки, чтобы записать номер версии во время компиляции.

2

bzr tags выводит список тегов (и их соответствующих редакций) в текущей ветви. Я считаю, что самый последний тег указан первым, поэтому вы, вероятно, могли бы сделать что-то вроде этого: 

bzr tags | head -n1 | cut -d ' ' -f1
1