Trac: плагин просмотра кода

Ответ 1

Мы были в той же ситуации. В итоге мы решили установить Review Board параллельно с Trac. Хотя это не плагин Trac, это отличный инструмент, и до сих пор мы очень этому довольны.

Он также имеет базовую поддержку Trac, так что, например, при проверке исправлений ошибок вы получаете автоматические ссылки на билет Trac.

Ответ 2

В моей компании мы кратко рассмотрели плагин "peerreview" на TracHacks и были очень разочарованы этим.

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

У нас не было возможности просмотреть любой другой плагин (CodeReviewPlugin).

Ответ 3

Я думаю, что PeerCodeReview лучше для того, чего вы хотите.

Однако предыдущий плакат правильный, вы должны просмотреть исходный репозиторий и выбрать код, который вы хотите просмотреть, и аннотировать его. Он ничего не знает о наборах изменений.

Это хорошо, если у вас есть кто-то (например, архитектор или ведущий), который активно смотрит на код и идентифицирует вещи, которые могут быть проблематичными.

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

Если вы ищете что-то, что ассоциируется с фиксацией и обрабатывает diff, посмотрите ReviewBoard (приложение DJango):

Ответ 4

Я также разочарован PeerCodeReview. Он связывает комментарии с конкретным пересмотром, и когда вы повторно обновляете новую версию для пересмотра, вы закрываете старый обзор и открываете новый, но все комментарии остаются в старом обзоре! Таким образом, нет простого способа увидеть комментарий вместе с новым источником, который обращается к нему. Вместе с полным отсутствием поддержки для просмотра commits/diff, это делает PeerCodeReview непригодным для меня.

Плагин CodeReview кажется приятным (на самом деле его не пытались), но я все еще не могу прокомментировать определенные строки.

Я не должен, чтобы мой вариант использования был не классическим "обзором кода", а просмотром одного документа LaTeX. Это имеет разные требования:

• Проверка перед фиксацией не требуется; напротив, "рабочий процесс конвейерный" имеет решающее значение: комментарии отзыва создаются, когда рецензент имеет свободное время, и обращаются, когда писатель добирается до них, часто в гораздо более поздних совершениях.

• Было бы неплохо отслеживать, какие части текста были просмотрены при каких изменениях.
  Это не критично, так как просмотр обычно выполняется разделом за раз, и это легко достаточно, чтобы отслеживать вручную.

• Есть много небольших независимых комментариев. Каждый комментарий должен быть отслежен независимо, одно разрешение "одобрить/отклонить" для фиксации.

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

Правильный поток для этого заключается в том, чтобы открыть билет для каждого комментария, закрыв их с помощью фиксации при обращении. Единственная проблема заключается в том, что нет простого способа привязать билет к определенным строкам в файле, что делает его довольно громоздким. Я соблазн написать минималистский плагин, который связывает билеты с источниками/линиями. Кто-нибудь еще, как такой зверь?

То, что я, вероятно, сделаю на практике, - это поместить комментарии TODO внутри самого источника и не использовать для этого интерфейс Fancy Trac. Контроль версий гарантирует, что комментарии останутся там, где они находятся между изменениями.

[В частности, для LaTeX я, вероятно, буду использовать пакеты todonotes и/или fixme, чтобы хорошо отображать комментарии, и, возможно, latexdiff для визуальных различий.] Я отредактирую это позже, чтобы сообщить, как оно прошло...

Кстати, этот подход не ограничивается документами - я работал с командой, которая много использовала ее для анализа кода во время интенсивной гибкой разработки, и она работала достаточно хорошо. У них было такое же желание "проложить" процесс пересмотра - развитие должно продолжаться, но все изменения должны быть пересмотрены до выпуска. Самая сложная часть - отслеживание того, что было или не было просмотрено, что было сделано путем пометки "чистых" ревизий и отличий от них; в ретроспективе, имея "пересмотренную" ветку, и сбор вишни в ней будет работать лучше. (Конечно, нелокализованные, архитектурные вопросы будут идти в Trac билеты вместо этого или начнутся как комментарии TODO и будут перенесены в билеты, если они оказались нетривиальными для адресации.)