[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Enhancing svn blame (Was: Case study: Mono switches to Subversion)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-11-21 02:54:26 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.