В Подвижном, как я могу связать набор, соглашается на единственную проблему в нашем bugtracker?
Гм, да, это корректно. Вы даже ссылаетесь на соответствующие документы.
Можно, например, запустить скрипт крона на стороне сервера, проверив подвижный журнал (использующий hg журнал) и затем обновляющий Bugzilla с номером выпуска, который Вы нашли от журнала. Например, параметр - дата 26.01.2011 к журналу hg дает только сообщения журнала в течение определенного дня, который намного быстрее для обработки, чем все записи в журнале каждый раз.
Вы не можете добавить сообщения при продвижении к серверу, только при фиксации.
Важно помнить, что наборы изменений (почти) неизменяемы, а это значит, что уже слишком поздно добавлять номер ошибки, когда разработчики запускают hg push . Команда push только перемещает ревизии, а не меняет их.
Однако, hg push , конечно, хорошее время, чтобы пойти и обновить Bugzilla, поскольку разработчики находятся в режиме онлайн при отправке в центральный репозиторий. Таким образом, вы можете попросить разработчиков установить ловушку вроде
[hooks]
pre-push.bugzilla = pick-bug-number.sh
. Сценарий pick-bug-number.sh должен сначала проверить, что разработчики отправляют в ваш центральный репозиторий (а не, скажем, в какой-то другой репозиторий на своем ноутбуке), а затем спросите у них номер ошибки. Когда разработчик вводит номер ошибки, сценарий может посмотреть на hg outgoing и связать исходящие ревизии с ошибкой в Bugzilla.
Это один из способов связать ревизии с внешней системой отслеживания проблем. В наборах изменений не будет ничего, что связывает их с ошибкой Bugzilla - только Bugzilla знает, что наборы изменений относятся к каким ошибкам.
Другой способ - встроить номера ошибок в сами наборы изменений. Это можно сделать с помощью именованных ветвей в Mercurial. Пусть ваши разработчики запустят
$ hg branch bug-123
перед тем, как начать работу над ошибкой номер 123. Следующие коммиты будут содержать внутри себя метку «bug-123». При отправке на сервер легко проанализировать отправленные наборы изменений (в ловушке changegroup ) и обновить Bugzilla.
Вы также можете попросить разработчиков указать номер ошибки в сообщении о фиксации, как и в случае с Subversion. Никакой онлайн-проверки не будет, но они могут следовать примерно так же, как и в Subversion. Проверить сообщение фиксации лучше всего, настроив ui.editor . Сделайте собственный сценарий, который будет запрашивать номер ошибки, поместите его в шаблон сообщения фиксации, а затем запустите и редактируйте, чтобы разработчики могли ввести сообщение фиксации.
Использование сообщений фиксации лучше, чем использование именованных ветвей, если вы планируете имеют тысячи номеров ошибок. Сам Mercurial довольно хорошо масштабируется с учетом количества именованных ветвей, но многие инструменты ожидают, что смогут отображать все ветки в одном раскрывающемся меню. Это хорошо работает, когда у вас их 10 или 20, но не работает, когда у вас их 5000. Это больше похоже на UI,