Hi Andrew,

Today, a single review request represents a single change represented by a
single diff. Additional changes for a feature should be separate review
requests. If you're using the diff functionality as intended, then any
particular diff should be pre-first-diff to post-second diff, because each
diff is based off a certain change. The diff revisions are not meant to be
used as patches in a series.

If you're working with a DVCS setup where you might have two changes, one
requiring the other, then you can use post-review with the --parent option
to generate a diff against a parent branch or change. This doesn't change
the model above, though.

The current model for review requests is not likely to change, with the
exception being the newly drafted DVCS support. One of our Summer of Code
students this year is working on improved DVCS support that would allow a
review request to be able to have multiple diffs instead of a single diff
that represents that change. The intent is still that a review request
represents one logical change, but this one change may be broken up into
separate smaller diffs instead of being one large diff, in order to ease
review. This is still in the design phases, but the idea is that it could
maybe go in for 1.6, if it's in a good state by then.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Fri, May 7, 2010 at 5:00 PM, Andrew <aschwa...@gmail.com> wrote:

> Hi guys.  I've been playing with the multiple revisions support in
> ReviewBoard.
>
> I was wondering what people think about these two suggestions:
>
> 1. It would be nice to be able to compose changesets.  For instance,
> if I have one changeset under review, it then gets reviewed, then I
> post a second changeset that is based on the first changeset, it would
> be neat to be able to see the diff from pre-first diff to post-second
> diff.  I understand that currently, it is possible to see the diff
> from post-first diff to post-second diff.
>
> 2. Given that #1 is not currently a feature, I am instructing all of
> my users to update review requests with changesets that are based on
> the same initial revision.  This way, the reviewer can see what's new
> in the second revision, as well as the full second revision.  I'm
> wondering whether it would be worth optionally enforcing this as a
> feature, or warning the user if the different revisions have different
> parents.
>
> My question #2 may be related to my other question at
>
> http://groups.google.com/group/reviewboard/browse_thread/thread/aefd7a770dca771a
>
> Thanks.
>
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to