We're looking at a few code review tools for work, and I'm excited by
what I see in Review Board.

I'm trying to wrap my head around the best way to associate a review
with the correct file changes.

We use Subversion and we usually do regular commits while working on a
ticket (we use Trac) in order to not lose any local changes (e.g.,
drive failure, etc.).  So I think (?) that rules us out of using the
post-review model which relies on creating the review from all the
uncommitted local changes for a ticket.

The pre-review model (i.e., posting a diff of all the relevant code
changes) seems like it might work, but the process of gathering up all
the revisions for a ticket seems error prone.  A ticket could have
anywhere from 1 to 50 (or more) commits for it.  Although each commit
in our system is loosely tied to a ticket via the inclusion of a
ticket number in the revision comment, how could we systematically
pull in all of these revisions into one nice diff?

I'm very curious to hear how other users have successfully integrated
their code development/review with Review Board.  I'm sure I'm missing
the boat on some of this here.

Thanks for reading,
Eric P.

You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to