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