1. interesting. I tried "parent" but it didn't seem to work the way I
expected. It should compare the current revision with the parent revision,
but didn't seem to do that. I suspect I probably did not set up the test
correctly.  In any case, I'll give it another try.

On Sat, Oct 30, 2010 at 11:01 AM, Andrew Schwartz <aschwa...@gmail.com>wrote:

> If I'm understanding you correctly, you're saying two things:
> 1. As a new changeset is created by the developer, the developer will
> update the review request to be based at the same original revision but with
> the set of changesets under review including all of the original changesets
> under review + the new changeset.  This is already doable in the postreview
> Mercurial extension with the "parent" argument.
>
> 2. You want comments to be translated over to the new revision.  I don't
> know that this is currently doable in ReviewBoard.  Chris, am I missing
> something?
>
> On Thu, Oct 28, 2010 at 10:59 PM, J Arrizza <cppge...@gmail.com> wrote:
>
>> On Thu, Oct 28, 2010 at 12:46 PM, Andrew Schwartz <aschwa...@gmail.com>wrote:
>>
>>>   - have a "rollup" mechanism. As the additional revisions are added, the
>>> changes are rolled up into one aggregate diff. (I assume this would be very
>>> complicated code and so might not be doable without significant risk)
>>>
>>> What do you mean?
>>>
>>>
>>>>
>>>>
>> Say there are 2 diffs/revisions in the CR. The diff is then between v1 and
>> v2. Comments are applied to lines in v2. So far so good.
>>
>> A new version v3 is added to the CR. The diff is then "rolled forward" so
>> it now shows the diffs between v1 and v3. The comments applied to lines in
>> v2 are moved to the correct lines in the version 3 text. (And there is no
>> more "v2" anymore, there's one and only one diff).
>>
>> A new version v4 is added to the CR and the diff is rolled forward again
>> to show the difference between v1 and v4; comments in v2 and v3 rolled
>> forward too; v3 is removed.
>>
>> And so on...
>>
>> Another way to look at it is it's a "left-anchored diff". The left-hand
>> side of the diff never changes, only the right hand side does.
>>
>> Like I said, the algorithm likely has many edge conditions and exceptions
>> and so is likely to be very complicated code.
>>
>>
>> John
>>
>>
>>
>>
>>  --
>> 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<reviewboard%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>



-- 
John
blog: http://arrizza.blogspot.com/
web: http://www.arrizza.com/

-- 
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