On Sat, Oct 15, 2011 at 2:10 PM, Christian Hammond <chip...@chipx86.com> wrote:
> 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 real
>>> 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
> 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
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