Trac：代码审查插件

Question

我正在寻找一个代码审查插件为我们的trac安装。

我发现这两个为 “trac code review” 查询顶部结果对谷歌

• PeerCodeReview
• CodeReview

我倾向于PeerCodeReview插件。

要求SO社区输入关于这些插件的信息，以帮助我们选择一个用于trac安装的插件。

如果你知道其他插件，请让我知道这些。 :)

什么，我在插件

• 寻找一种方式与注释注释代码。
• 批准/不批准;有点像按钮来通知代码需要改变。可能会创建一个错误。
• 一种将代码审查“任务”分配给某个人的方法。

第一个功能是必需的（我想这就是整点）;其他人是可选的。我可以破解trac以获得与该工作流相似的内容。希望！ ;）

Answer 1

我们是同样的情况。最后，我们选择与Trac并行安装Review Board。虽然它不是一个Trac插件，但它是一个很好的工具，到目前为止我们对它很满意。

它也有基本的Trac的支持，这样，例如，检讨错误修正时，你会得到自动链接到Trac的车票。

Answer 2

在我的公司，我们简单地看了一下TracHacks上的“peerreview”插件，并对此非常失望。

对我们来说，一个代码审查插件自然会默认假设整个Subversion提交应该进行代码审查，这似乎很明显。不幸的是，peerreview插件强制您手动确定要查看的代码行。它甚至不会给你提示哪些行可能因特定的提交而改变，这意味着如果你没有输入那些经过仔细修改的行，最终可能会反复检查相同的代码行。

我们没有机会详细回顾其他插件（CodeReviewPlugin）。

Answer 3

我认为PeerCodeReview更适合您的需求。

但是，上一张海报是正确的，您必须浏览源代码库并选择您想要查看的代码并对其进行注释。它对变更集一无所知。

如果您有人（如建筑师或主管）主动查看代码并确定可能存在问题的事情，这很好。

如果您想查看与变更相关的每一块代码，它并不会奏效。

如果你正在寻找的东西，与关联提交和处理的diff，然后看ReviewBoard (a DJango app):

Answer 4

我也对PeerCodeReview感到失望。它将评论与特定修订相关联，并且当您“重新提交”一个新的修订版以供审阅时，您将关闭旧评论并开启一个新评论 - 但所有评论仅保留在旧评论中！所以没有简单的方法可以看到一个评论以及解决它的新的源代码。再加上完全不支持审查提交/差异，这使得PeerCodeReview不适合我。

的代码审查的插件看上去不错（实际上并没有尝试），但我还是很怀念在特定行进行评论的能力。

我不应该说我的使用情况下，是不是经典的“代码评审”，但回顾单一的LaTeX文档。这有不同的要求：

• 在不需要提交之前进行检查;相反，一个“流水线”工作流程 是至关重要的：当审稿人有空余时间， 创建评审意见和当作家变得对他们来说，经常要晚得多提交解决。

• 它会是不错的跟踪其文本部分都在什么修改了审查。
  这并不重要，因为审阅通常一次完成一个部分，并且很容易手动追踪 。

• 有许多小型的独立意见。每个评论应独立跟踪 ，一个提交的“批准/拒绝”解决方案。

• 多数意见是在文件中以及本地化的，所以我想，允许在文件中附加 他们特定的地方流动，他们应该保持自己的位置时，该文件是 编辑。

的权流因为这将是开出罚单为每个评论，与寻址时提交挂钩关闭它们。唯一的问题是，没有简单的方法将票证绑定到文件中的特定行，使其非常麻烦。我很想写一个简单的插件，将门票绑定到源/差线。会有其他人喜欢这样的野兽吗？

我在练习中可能会做的事情是将TODO注释放在源代码本身中，并且完全不使用花哨的Trac接口。版本控制将确保评论留在编辑之间它们所属的位置。

[乳胶具体而言，我可能会使用todonotes和/或fixme包很好地显示评论，也许latexdiff视觉diff文件]我将修改这个稍后向警方如何去...

顺便说一句，这种方法并不局限于文档 - 我曾与一个团队合作，在密集的敏捷开发过程中使用它进行代码审查，并且运行良好。他们也有类似的愿望来“审视”审查过程 - 发展必须继续下去，但在发布之前必须审查所有变更。最难的部分是跟踪什么已经或没有被审查，这是通过标记“干净”的修订和差异来完成的;回想起来，有“审查”分支和樱桃采摘到它会更好。 （当然，非本地化的架构问题可能会转化为Trac门票，或者会以TODO评论的形式出现，并且如果证明这些问题不是很重要，那么它们将被迁移到门票中。）