2013-08-20 1 views
6

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

Как я понимаю, я могу пометить текущий набор изменений через hg tag stable.

Каков правильный способ перемещения метки? Когда я пытаюсь запустить hg tag stable снова он говорит мне:

прерывания: тег «стабильный» уже существует (используйте опцию -f для форсированного)

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

+2

Похоже, что это [предполагаемое поведение] (http://selenic.com/pipermail/mercurial/2012-May/042762.html). Weird. – mpen

+1

Вы связались с автоматическим сообщением в списке рассылки, когда была отправлена ​​ошибка. Текущий статус [в Bugzilla] (http://bz.selenic.com/show_bug.cgi?id=3589) «RESOLVED INVALID», и есть комментарий, объясняющий, почему. –

+0

(psst, эй, не могли бы вы создать вики для vcs-тегов?) – Will

ответ

10

Я не вижу такой тег «движение» операцию, но она, по существу, копирование и удаление что-то оригинальное, так:

hg tag --remove stable 
hg tag -r newrevisionhash stable 

или добавить какой-то суффикс в теги, как номер версии. Это также позволит вам отслеживать ваши релизы.

Мнение 1: Я всегда, хотя mercurial был больше связан с сохранением истории, а в то время как под git вы могли что-то изменить, в mercurial вам вместо этого пришлось бы переписать его.

Мнение 2: другой альтернативой маркировке стабильных выпусков было бы держать их в одной ветке. Где я работаю default имеет только стабильный код. Все остальные работы выполняются в изолированных ветвях.

Грязный один вкладыш, чтобы сделать обновление метки:

current=`hg log -l1 --template '{node}'`; hg tag --remove stable; hg tag -r $current stable 

, кажется, что это злодеяние может быть даже добавлены как ртутный псевдоним в .hgrc:

[alias] 
movetag=!(current=`hg log -l1 --template '{node}'`; $HG tag --remove stable; $HG tag -r $current stable) 

я захвачу значение тока tip, так как удаление/добавление тегов совершают сами по себе, поэтому они «перемещают» кончик (не вижу ничего плохого в пометке tip - это только ради точности). Конечно, есть потенциал сделать его красивее, но это сработало для меня.

+0

Что касается варианта 2, это в основном то, что мы делаем. Все работы выполняются в других филиалах, но мы объединяем их по умолчанию, когда они готовы, а затем выполняем интеграционное тестирование. Существует период, когда «default» может быть fubar, если есть плохое слияние. Таким образом, я хочу сохранить стабильный тег по умолчанию и только перемещать его после завершения/проверки интеграции. – mpen

+0

Номер версии не работает. Это будет крупная ПИТА. Я хочу, чтобы все обновлялись до «стабильных», прежде чем приступать к работе над новой проблемой; не могут постоянно просматривать последний номер версии. Номера версий могут дополнять его, но мне нужен тот, который всегда относится к последнему. Для этого должна быть какая-то обычная практика. Лучше всегда удалять тег или просто иметь десятки одного и того же тега? Фактически, «удалить» на самом деле ничего не удаляет. Он просто добавляет фиктивную запись в '.hgtags', а затем, когда вы добавляете новую, она всегда дублирует фиктивный тег. – mpen

+0

Ну, он больше не указан напр. 'log', поэтому он что-то делает. И, как я уже сказал, возможно, отслеживание всего лишь «меркуриального пути». Я не думаю, что это когда-либо вызывало у меня проблемы. Что касается номеров версий: я видел проект, в котором дата развертывания была суффикса для имени тега (если все прошло хорошо) - своего рода избыточность, но это было удобно для разработчиков. – guessimtoolate

7

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

Вы пишете в комментарии выше, что

Вся работа делается на других отраслях, но объединить их в «по умолчанию», когда они готовы, а затем выполнить тестирование интеграции. Существует период, когда «default» может быть fubar, если есть плохое слияние. Таким образом, я хочу сохранить стабильный тег по умолчанию и только перемещать его после завершения/проверки интеграции.

Для этого вам понадобится дополнительная именованная ветка - назовите ее stable. Затем смените проверенные и одобренные изменения на default на stable в своем собственном темпе.Это не имеет значения, если default имеет ревизии, которые до сих пор проходит испытания, когда ревизия X проходит испытания, вы

$ hg update stable 
$ hg merge X 

содействовать X в качестве стабильной ревизии. Потомки X (на default) остаются неизменными, то есть они еще не отмечены стабильными.

+1

Я думал об этом. Я думаю, что это решает отслеживать выпуски, но не дает разработчикам цель вытащить и построить, поскольку теперь они строятся на «стабильной» ветке. Им нужно будет объединиться с дефолтом или некоторыми такими. –

3

Как уже указывалось @guessimtoolate и @Martin Geisler, вы можете использовать именованную ветку для размещения всех хороших версий (что также связано с тем, как мы используем hg в компании). Другой способ - использовать bookmarks, которые действуют как подвижные ярлыки, прикрепленные к одной ревизии.

Смежные вопросы