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, которая, как следует из её названия, позволяет сравнивать любые части репозитория и любые ревизии кода.
В-третьих, встроенная вики позволяет публиковать любою проектную документацию, в том числе и актуальный список проверок, которые должен сделать автор кода перед тем, как посылать его на просмотр. 
Ну и наконец обязательно нужно настроить рассылку уведомлений и обязательно использовать перекрестные ссылки: комментарии к задаче должны ссылаться на код, а комментарии к изменениям в репозитории должны ссылаться на соответствующую задачу. Хотя это нужно не только для рецензирования.
а здесь инфа по настройке
standalone http://rsdn.ru/forum/?mid=1769977
и вместе с apache http://rsdn.ru/Forum/Message.aspx?mid=1778590&only=1
правда где про апач, я с аутентификацией чуть с глючил, но думаю это не проблема.
Я правильно понял что рамочным предположением является то, что 100% кода должно быть проведено через рецензирование?
Дело в том, что это справедливо не для каждого проекта, хотя, безусловно, справедливо для больших и критичных к ошибкам вещей.
Еще один вопрос.
В каких случаях, по вашему, оправданее применять процесс рецензирования основанный на патчах, примерно так как это делается в Open Source проектах?
Для программистов на шарпе есть удобная вещь ReSharper, хотя и непосредственно данная программа не предназначена для review кода, тем не менее, предупреждения решарпера очень помогают. Сам стараюсь чтобы мой код не был раскрашен желтым и других программистов пинаю.
зы. тоже самое и для программистов на Java в среде Idea тоже от jetbrains.
зы. про FxCop думаю никому напоминать не надо
Да, FxCop хорош. Правда, много времени уходит на притирание набора включенных проверок к проекту и команде, но оно того стоит.
Да, хотя это небезусловное правило. Для некоторых изменений имеет смысл использовать другие методы проверки: юнит-тесты, статические анализаторы кода и т.д. Скажем, эффективность рецензирования больших кусков нового кода невелика. Стоит потратить время отведённое на рецензирование на тестирование того, как новый код интегрируется с существующим.
Само собой. Чем больше компнент зависит от кода (читай чем больше проект или популярнее библиотека) и чем больше ущерб от ошибок (финансы, 24×7 системы) – тем тщательнее приходится проверять код.
Я использую примерно такую градацию (от наименее строгого варианта к наиболее строгому):
1 & 2 имеет смысл только для совсем маленьких и незначительных проектов. Выбор между 3 & 4 зависит от мобильности команды и от “проверенности” уровня разрабочиков.
Скажем, если компания пишет коммерческий продукт, то строгости 4-ого варианта будут только мешать. Разработчики соответствуют некоторому минимальному уровню компетентности, сидят в одном офисе, материально заинтересованы и т.п. При возникновении проблем они могут быть решены достаточно оперативно.
С другой стороны в Open Source поекте патч может прислать кто угодно и качество присланого кода заранее не известно. Основное средство коммуникаций – e-mail тоже не обеспечивает нужной мобильности. Соотвественно используется 4-ый вариант. Хотя основные разработчики (как правило авторы проекта и наиболее активные и проверенные участноки) пользуются 2 или 3-им вариантом.
В общем всё зависит от: