Инструмент для проверки кода в хранилище Mercurial

В нашей команде мы практикуем проверку кода для каждой фиксации. Я имею в виду локальный анализ кода, когда рецензент находится рядом с вами. С Subversion (мы использовали TortoiseSVN) мы использовали для сортировки изменений в наборах следующим образом:

Теперь мы используем Mercurial (через TortoiseHG). TortoiseHG не поддерживает группировку изменений в рабочем каталоге.

Локальные коммиты помогают немного, но есть проблема с просмотром кучки локальных коммитов. Невозможно "отметить" (например, с флажками) файлы, которые уже просмотрели.

Есть ли какой-нибудь инструмент, который решает эти проблемы? Кроме того, будет очень интересно прочитать о вашем опыте с обзором кода в Mercurial.

Ответ 1

Мы используем инструмент Atlassian Crucible Это, безусловно, один из лучших PR-инструментов, и он легко сочетается со всеми другими атласскими инструментами лучший выбор. Это может быть дешево для небольшой команды, все еще довольно дешевой для более крупного предприятия.

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

Часто мы будем спарить программу и просматривать изменения по плечу или поймать людей. Мы либо используем нашу IDE (IntelliJ IDEA), либо DiffMerge просмотреть изменения прямо на компьютере. Это не инструмент PR, это инструмент для разграничения/слияния, который мы также используем для слияния, но смесь DiffMerge и Crucible довольно хорошо помогает нашим гибким процессам.

Я надеюсь, что это поможет.

Ответ 2

Я вижу по крайней мере два способа выполнения проверки кода в Mercurial | TortoiseHG:

без стороннего инструмента
с использованием дополнительных продуктов

Внутренний CodeReview

В этом случае используются только Mercurial и его названные ветки. Предварительный рабочий процесс и соглашения * ветвь по умолчанию - это ветвь слияния. Все развитие происходит в отдельных (личных -? Feature -?) Ветвях; * Только доверенный QA имеет слияние прав по умолчанию;

как это работает

Когда DEV хочет отобразить некоторые изменения из ветки FEATURE в QA, он нажимает интересующую ветвь (hg push -b) на QA (или отрывную ветвь QA)
Каждый рассмотренный набор изменений (или вся ветка после просмотра всего пакета) объединяется в дефолтную (или любую другую ветвь "mainline" ) и по умолчанию перенаправляется в "авторитетный репозиторий", из которого "принятые изменения" могут быть вытащены всеми другими DEVS

CodeReview с внешними инструментами

ReviewBoard

TortoiseHG из 2.0 имеет диалог ReviewBoard, интегрированный в интерфейс Workbench. Вы можете загрузить, установить, настроить ReviewBoard (остерегайтесь - Django) или войдите в RBCommons (размещен на сайте ReviewBoard), и после этого следуйте этому небольшому HowTo, чтобы получить интеграцию TortoiseHG и ReviewBoard

Assembla, BitBucket

При использовании forked repos и pull-запросов вы также можете иметь CodeReview (в некоторой степени)

Ответ 3

Если вы работаете с Mercurial + Visual Studio, я могу порекомендовать Review Assistant.

Мы используем его для проверки кода в нашей компании. Мы делаем в первую очередь проверку кода после фиксации.

Кроме того, вы можете настроить интеграцию с TortoiseHG.

Ответ 4

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

Dev A: hg diff > uncommited.patch

Dev B: hg patch --no-commit uncommited.patch

Ответ 5

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