On Sun, 21 Nov 2004, [UTF-8] Branko Ä^Libej wrote:
> Greg Hudson wrote:
>
> >I think you're right. Our binary deltas get random access to the source
> >and target within a window, which enables them to be smaller
> >(particularly if the source is the empty stream) but renders them
> >useless for blame, as far as I know.
> >
> >
> You can calculate from the vdelta what was added and what was removed in
> any commit. It's not completely trivial, but my gut feeling is that it's
> no harder than a delta combiner. The fact that vdelta is also compresses
> does complicate matters a bit. But not much more than a context diff,
> which isn't always right for blame, either.
>
I'm still not convinced, but then I'm just a simple programmer. I created
a little program that outputs the instructions of a svndiff and played
with it. I don't see how to generate the ranges from that output.
> >>Else, I think Karl's proposal is good as far as it goes.
> >>
> >>
> >I don't understand how Karl's proposal can work, but perhaps others can.
> >
> >
> Karl proposes that we store a diff as if it were created byte-by-byte
> instead of line-by-line.The advantage of storing byte ranges is that you
> don't care how you came by them, i.e., they're independent of the actual
> diffing agorithm (line-based context diffs reveal a fair amount about
> the generating algorithm). This means that theoretically, we could have
> an implementation of "blame" that does something sensible with bitmaps
> or -- ouch! -- even video streams. Or XML, which would probably have a
> larger target audience. :-)
>
We can talk about exactly how to store this information later. First I
need to be convinced that we can get the information we want. :-)
regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 21 18:28:55 2004