Обзор рабочего процесса Board для хранилища Mercurial

В моей компании мы пытаемся добавить методы проверки кода в наш процесс разработки, и для этой цели мы решили использовать Review Board.

В то время как обзорный совет должен работать из коробки для Subversion, рабочий процесс для Mercurial выглядит немного привлекательным. Во-первых, кажется, что для этого типа репо поддерживается только пост-обзор (через пост-обзор script). Во-вторых, документация неясно, поддерживает ли пост-обзор Mercurial (он упоминает только git).

Не могли бы вы описать свой рабочий процесс подробно?

Я правильно понимаю, что это должно быть примерно так:

Разработчик:

  • clone master repo
  • функция клонирования репо из локального репо-сервера
  • hack-hack в функции репо
  • фиксация в функции репо
  • каким-то образом запустить пост-рецензирование из репозитория функций в репозитории master master

Рецензент:

  • обзор diff
  • если ОК, затем перейдите к мастер-репо из функции репо

Ответы

Ответ 1

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

Основная проблема, с которой вы сталкиваетесь при использовании ReviewBoard с DVCS, - это то, где вы хотите, чтобы кто-то просмотрел изменение, скажем, ревизию 2, до версии 3, оба из которых находятся в вашем локальном репо, но не у мастера, к которому имеет доступ ReviewBoard, например, потому что вы все еще ожидаете рассмотрения изменений от версии 1 до версии 2.

Решение ReviewBoard для этого - это то, что он называет "parent diffs"; это означает, что вместо того, чтобы просто загружать исправление, которое вы хотите просмотреть, вам также необходимо загрузить разницу между последней версией в мастер-репо и родительской версией вашего патча. Это позволяет ReviewBoard восстанавливать исходные файлы для левой стороны своего бокового обзора.

Текущая версия ReviewBoard не поддерживает родительские различия для Mercurial, но я представил патч, который заставляет их работать; Я считаю, что это должно быть для RC3.

Я также исправил расширение ReviewBoard, упомянутое в предыдущем сообщении, чтобы он поддерживал различия между родителями. Я сделаю их доступными после отпускания RC3.

Ответ 2

Существует расширение для mercurial для того, что вы хотите сделать:

http://blogma.de/projects/mercurial-reviewboard.html
https://www.mercurial-scm.org/wiki/ReviewboardExtension

Поток работы, который вы представляете, кажется легким, поэтому я думаю, что вы на правильном пути. Способ обработки услуг DVCS (т.е. Битбакет или github) на самом деле тот же:

commiter:
шаги 1... 4 одинаковые
5. Отправьте запрос на перенос для сопровождающего (это ваш анализ кода подходит)

Рецензент:
1. рассматривает запрос на растяжение
2. тянет

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

Ответ 3

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

GitHub и Bitbucket решают эту проблему подходом, который не был жизнеспособным в эпоху предшествующих DVCS, используя так называемые тяговые запросы.

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

Возможно, вам захочется посмотреть Git Демонстрация рабочих процессов: что такое видеообъявление Integrator Workflow? на YouTube. Это относится и к Mercurial.

Ответ 4

Теперь есть расширение FileReview, которое интегрировано с TortoiseHg (начиная с TortoiseHg >= 0.9). Похоже, что обзоры интегрированы в репозиторий.

Это не удалось заставить работать в Windows, но я надеюсь, что это будет улучшено!