Jan Koprowski wrote:
..... When review is done and submitted
developer can change everything he want in working tree and commit
everything he want. I'm thinking how be sure that reviewed changes is
commited changes.

For us, we are just using the honour/honor system, i.e. no checks :-) This mostly works BUT occasionally people do make mistakes (e.g. submit an extra file that was not in the review) so a check would be nice, for me personally I'm not sure it is worth spending the time on it.

For a central based SCM (like svn) you could add a commit hook that pulls the diff from reviewboard and compare the diff with what the SCM has been given, as you suggested. I suspect this is the easiest thing to setup and would help catch accidents .... rather than deliberate deceptive developers ;-)

The other idea similar to your manual reviewer idea would be for a script to pull the diff from RB (that is marked with "Ship It!") and submit the change (assuming the patch applies cleanly). If patches don't apply cleanly the review could be marked with "patch didn't apply cleanly to [rev in SCM]" and the developer an resubmit. If you already have a buildbot system this is probably your best option (especially if you have tests as part of the build bot, you could add additional rejection checks).

I've deliberately minimized the procedures/policies we have for RB at our site so this isn't something I plan on implementing myself but I can see the value.


Want to help the Review Board project? Donate today at 
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to