Default reviewers helps with merges, the other one depending on the
structure of the code is to divide the diff into multiple review requests.
This allows reviewers to digest the change in a manageable piece. How you
divide it would depend on the type of work, but we have done some where all
the make/build system changes are in one review, addition of new api calls
are in another, and then a 3rd which contains the usage of those new calls.
The only thing that would be nice is if there was a way in reviewboard to
say that two review requests are linked or depend on each other.
On Tue, Mar 15, 2011 at 12:00 PM, Bobman <bobpa...@gmail.com> wrote:
> At my company we have a recurring issue (we use CVS) when we merge a
> branch back to the trunk, where (if it has been several months) the
> changes and conflicts need to be reviewed by many people.
> Ideally, we would run a diff between the two branches and publish that
> for others to review, but a 50,000-line diff is hard to digest without
> Does Review Board work well in this scenario? Does anyone here have
> experience with scenarios like this and/or have any suggestions for
> how to handle this?
> 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
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