Автоматически помечать наборы изменений при фиксации или отправке в печь

Question

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

Я бы хотел, чтобы каждый набор изменений имел тег с версией / сборкойчисло.Я планирую сохранить свои номера версий / сборок в базе данных и хотел бы, чтобы скрипт извлек это значение из базы данных и добавил тег в набор изменений.Можно ли автоматически вызывать сценарий, чтобы сделать это как событие после фиксации или как событие после отправки, когда он помещен в хранилище печи?

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

Answer 1

Вместо создания тега для каждого набора изменений, почему бы не попробовать одно из следующего:

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

Описательная строка может быть сгенерирована из журнала с помощью этой команды:

hg log -r 1.7.2 --template '{latesttag}-{latesttagdistance}-{node}\n'

Результат принимает форму:

<latest tag>-<# changesets since latest tag>-<changeset hash>

Например, на моем локальном клоне репозитория Mercurial, это генерирует:

1.7.2-2-5e51254ad4d4c80669f462e310b2677f2b3c54a7

, который говорит мне, что было два коммита с момента тега 1.7.2, и текущий хэш ревизии равен 5e51254a.

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

Answer 2

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

Вы всегда можете написать хук пост-коммита, чтобы сделать это.

Я бы хотел, чтобы в каждом наборе изменений был тег с номером версии / сборки.

Теги полезны для определения важных моментов в вашей истории коммитов. Предоставление этим моментам значимого названия, связанного с разработкой продукта, такого как выпуск 1.0, выпуск 1.3 и т. Д.

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

Рассматривать тег как метаинформацию об наборах изменений. Не все из них заслуживают одинаковой важности. Не все из них требуют этой мета-информации.

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

На крючках

См .:

• http://www.selenic.com/mercurial/hgrc.5.html#hooks
• Полезные ртутные крючки
• https://www.mercurial -scm.org / вики / Hook

Пример. Запуск после добавления группы изменений с помощью push, pull или unbundle. Я использовал его для запуска автоматических сборок.

[hooks]
changegroup.yyyy = command 

Аналогично, есть пост-коммит, пост-пуш-хуки

[hooks]
post-<command> =  command