[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-11-21 21:49:13 CET

On Sun, 21 Nov 2004, [UTF-8] Branko ^Libej wrote:

> 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.
I meant libsvn_diff. Sorry.

> >>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
> >discusssion.
> >
> >
> I must admit I understand every word in the above, but I haven't the
> faintest idea what it means...
It is the difference between having to consult the actual revision and
that revision and possibly everyone older than that revision.

> >Maybe we should take a step back and do some more testing before
> >
> No "maybe" about it at all.
Yes. I think it is time to file an issue for this so it can be addressed
when time permits. Anyone objecting that I add an "blame performance"


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:39:17 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.