On Sat, Oct 15, 2011 at 2:20 PM, Robert Munteanu <robert.munte...@gmail.com> wrote: > 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> >> wrote: >>> >>> On Fri, Oct 14, 2011 at 10:35 PM, Christian Hammond <chip...@chipx86.com> >>> wrote: >>>> >>>> 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 >> content. > > 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: >> >> http://www.reviewboard.org/docs/manual/dev/webapi/2.0/resources/file-diff/ >> >> 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 > changes?
To answer this myself, the chunks have no gaps. Thanks for the answers, and definitely thanks for a well-built API. Robert > > Thanks, > > Robert > >> >> Christian >> >> -- >> 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 >> 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 > > > > -- > Sent from my (old) computer > -- Sent from my (old) computer -- 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
