Trac

На мой взгляд, Trac – одна из лучших, если не самая лучшая, bug tracking система для малых и средних по размеру проектов. Особая прелесть Trac состоит в том, что она органично объединяет вики, интеграцию с Subversion и ведение списка задач/ошибок. Именно то, что нужно команде для ведения проекта. Более того, стандартная функциональность позволяет организовать рецензирование кода, не смотря на то, что никакой специальной поддержки рецензирования в Trac нет.

_Кстати, существует плагин, добавляющий в Trac средства рецензирования: PeerReviewPlugin. _

Итак что для этого нужно? Во-первых, поскольку Trac не может визуализировать посторонний diff, нужно позаботится о дополнительных ветках в структуре репозитория. Изначально, каждое изменение должно производиться в ветке, специально выделенной для рецензирования и лишь после внесения всех исправлений, изменения будут копироваться в основную ветку. Напрашивается вот такая схема:

/trunk
	/feature_foo
		/feature_foo_review
	/feature_bar
		/feature_bar_review
	/bugs
		/bugs_review

Update: Замечу, что не смотря на отступы на схеме, все ветки создаются в одном и том же каталоге branches. Отступы на схеме нужно только чтобы показать порядок синхронизации веток, т.е. “trunk <-> feature_foo <-> feature_foo_review”, но не “trunk <-> feature_foo_review” напрямую.

Изменения сначала попадают в ветку «xxx_review». Отрецензированный код затем копируется в ветку «feature_xxx» или «bugs». Далее, изменения, пройдя соответствующее тестирования попадут в «trunk». В большом проекте такая иерархия может быть многоуровневой, однако все «_review» ветки будут оставаться в самом низу.

Также имеет смысл использовать отдельные «_review» ветки для каждого разработчика:

/trunk
	/feature_foo
		/feature_foo_xxx_review
		/feature_foo_yyy_review
		/feature_foo_zzz_review
	/feature_bar

Тем самым разработчики не будут мешать друг другу, коммитя непроверенный код.

Во-вторых, Trac предлагает очень удобные средства для просмотра изменений в репозитории.

Автор кода может просто добавить ссылку на changeset с изменениями [xxx] в комментариях к задаче (ticket), а затем присвоить задачу рецензенту. По завершению просмотра рецензент добавит свои комментарии по коду и присвоит задачу обратно автору кода.

В сложных случаях, когда изменение охватывает несколько changeset-ов поможет страница anydiff, которая, как следует из её названия, позволяет сравнивать любые части репозитория и любые ревизии кода.

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

Ну и наконец обязательно нужно настроить рассылку уведомлений и обязательно использовать перекрестные ссылки: комментарии к задаче должны ссылаться на код, а комментарии к изменениям в репозитории должны ссылаться на соответствующую задачу. Хотя это нужно не только для рецензирования. :-)