Thanks Christian. That certainly addresses my question #1.
I am using a DVCS (Mercurial).
Let me restate and add to my #2:
- would it be possible to warn the user and/or the reviewer if the parent
of two diffs in the same review request are different?
- would it be possible to show in the interface the diff's parent
revision? Currently, it seems to show the parent diff's parent revision.
- The user interface when there are multiple revisions of a diff is
slightly unintuitive. For instance, see
http://demo.reviewboard.org/r/1688/diff/4/ . It would be slightly more
intuitive if the "4" in the "Changes between r4 and" line were deleted.
As-is, the user interface seems to indicate that we are currently looking at
"Changes between r4 and 4", which is not what we are looking at ("Changes
between r4 and 4" would represent an empty diff).
On Fri, May 7, 2010 at 5:49 PM, Christian Hammond <chip...@chipx86.com>wrote:
> 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 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
>> 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
>> My question #2 may be related to my other question 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
> 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