[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 21:27:31 CET

Peter N. Lundblad wrote:

>On Sun, 21 Nov 2004, [UTF-8] Branko �^Libej wrote:
>>No, we already know at least two ways to get the information we want.
>>One way is already being used by "svn blame" -- it interprets context
>>diffs. Another way would be to extract the info from svndiffs (which is
>>harder). A third way is to use the algorithm in libsvn_diff, but to feed
>>it different tokens (e.g., bytes instead of lines).
>Heh. It would be interesting to whach the performance of svndiff with
>bytes as tokens.
Yikes, more terminology problems. "libsvn_diff" and "svndiff" are
different things.

>>What we need to figure out is how to encode this information in the
>>repository so that a) it is compact, b) can be used to calculate the
>>blame info bachwards in time instead of forwards, and c) can be
>>interpreted by the client without knowledge about the generating
>>algorithm. Storing a list of added and deleted byte ranges seems like a
>>logical choice.
>his would make the algorithm O(n). Storing, for each revision, range
>added in revision X would make the algorithm O(1), so there is room for
I must admit I understand every word in the above, but I haven't the
faintest idea what it means...

>Maybe we should take a step back and do some more testing before
No "maybe" about it at all.

-- 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 21:28:22 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.