Greg Hudson wrote:
>On Sat, 2004-11-20 at 17:37, Peter N. Lundblad wrote:
>
>
>>Should I interprete you as saying that svndiff gives us information such
>>as "this range deleted, this range added, ...". I am surely missing
>>something obvious, but I don't understand how. svndiff says things like
>>"take this from the source, then this from another place in the source,
>>then this new data, etc." I don't see how to translate this into what we
>>want. Please open my eyes.
>>
>>
>
>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.
>>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. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 21 02:55:14 2004