views:

303

answers:

4

Is there any existing software which can help enforce code review process like below:

  • Dev user commit their changeset with proper comments, but the changeset does not goes into subversion repository directly, it will be pending in a "review software".
  • Reviewer can see all pending changesets in the "review software", review the changeset and decide whether to allow the change into the code trunk.
  • The dev user will receive notification either his changeset was accepted and merged into code trunk, or was rejected.
+1  A: 

If you're open for alternatives to Subversion, this is a textbook git workflow that you might want to check out: Pro Git

unixtippse
Agree that this is a textbook reason to use a DVCS.
Michael Hackner
I agree, but we can not afford to change the existing subversion source repository.
Long Cheng
+1  A: 

You could try Review Board. You can have the developer upload a diff against the trunk for review. If the review is accepted, the diff can be applied to the trunk.

Dingo
+3  A: 

Trac-Hacks has a CodeReview plugin and a PeerReview plugin that should integrate with your existing repository. (Obviously you'd need a working Trac installation.)

quack quixote
Yes we have trac installation. I checked the two plugins you mentioned. I've not installed them yet, but from what I understand, they are implementing "post-commit review" rather then "pre-commit review" I want.
Long Cheng
well, you could (theoretically) have it commit to a (temporary?) intermediate branch (or even a separate, intermediate repository) for review, then committed to trunk after acceptance. as i understand it, the initial commit is necessary to get the changeset into svn/Trac in the first place. otherwise your tool would need to reimplement that functionality entirely; it makes sense to use svn since it's already there.
quack quixote
A: 

I've used ReviewBoard. It's ok, but does not deal with multiple pending commits (a stack of patches) well at all, as all diffs are done vs. the repository, and you can't (so far as I know) give it a diff which is not vs. the repository. Because of this, if your policy is no commits unreviewed, it can slow you down, because only contextually independent diffs can be up for review at a time. If you have 10 diffs that are linked together in a sequence, one depending on the other, you can't load them all up into reviewboard at once, you have to do one, review it, do the next, review it, etc. It becomes a process bottleneck for purely technical reasons.

For this reason, I prefer just emailing patches around for review.

SteveC