On Sat, Oct 15, 2011 at 2:20 PM, Robert Munteanu
> On Sat, Oct 15, 2011 at 2:10 PM, Christian Hammond <chip...@chipx86.com>
>> On Sat, Oct 15, 2011 at 4:03 AM, Robert Munteanu <robert.munte...@gmail.com>
>>> On Fri, Oct 14, 2011 at 10:35 PM, Christian Hammond <chip...@chipx86.com>
>>>> Hi Robert,
>>>> Sorry I didn't get to this sooner, but you're correct. It's a virtual
>>>> line number that is based on the generated diff using our specific
>>>> algorithm. We use virtual line numbers rather than real numbers because
>>>> numbers wouldn't necessarily make sense depending on how you generate the
>>>> diff (different algorithms may decide to insert lines differently, or fall
>>>> back on replaces more, or whatever).
>>> Hi Christian,
>>> Thanks for confirming the general algorithm. I suspected I would be in for
>>> a fun ride :-)
>>> For my purposes I need to get 1-to-1 mapping with the line numbers shown
>>> on ReviewBoard . I guide myself after the unified diff algorithm as
>>> generated by diff from diffutils . Is that a safe path to take or does RB
>>> perform this mapping differently?
>> Using our exact output is safe. Don't try to fork the algorithm, as we don't
>> guarantee it'll stay the same release-to-release (even though it has so far
>> -- we've only changed the core part once, but still..).
>>>> What you can do is take our generated diff from the API and use that to
>>>> reverse-map the virtual line numbers back to the real ones.
>>> That's what I started on. To ask a related question, does RB preserve the
>>> exact patch submitted, e.g. for Subversion, or does it serve an equivalent
>>> patch, possibly adjusted for its internal purposes?
>> We've been known to mess with certain diffs, often inadvertently. Sometimes
>> things get stripped. That'll only be extra headers, though, and not the
> That should be safe for my usage, thanks.
>> If you use the API, you can actually get the raw diff opcodes that you would
>> need to perform this mapping. Don't spend time trying to re-implement any of
>> our stuff. Instead, look at:
>> This should make your life much easier.
>> (Note that this is per-FileDiff.)
> Much easier, indeed, thanks!
> This should also be much safer rather than performing my own mapping.
> A final question: are the diff_data -> chunks objects present for all
> lines of the old/new files or show I expect gaps where there are no
To answer this myself, the chunks have no gaps.
Thanks for the answers, and definitely thanks for a well-built API.
>> Christian Hammond - chip...@chipx86.com
>> Review Board - http://www.reviewboard.org
>> VMware, Inc. - http://www.vmware.com
>> 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
> Sent from my (old) computer
Sent from my (old) computer
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