[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-17 19:15:04 CET

On Wed, 17 Nov 2004, C. Michael Pilato wrote:

> Ben Collins-Sussman <sussman@collab.net> writes:
>
> > In svn 1.0, 'blame' was about 100x slower than CVS. In svn 1.1, it's
> > about 10x slower. I really can't think of any way to make it faster,
> > other than doing what CVS does: keeping a cache of contextual diffs on
> > the server, so the server can instantly generate annotation. We
> > should probably start a different thread on this, to discuss (A) if we
> > want to open an issue for this, (B) if/how we want to prioritize this
> > enhancement at all.
>
> CVS does keep contextual diffs, but we wouldn't need to store all of
> that. All we'd need to store is what we actually want -- annotation
> information. The username, date, and revision are stored as
> revprops. All we lack are the line numbers, really.
>
You mean at each commit, a list of changed lines is stored?

I and sussman is discussing another way on IRC right now. That's doing the
blame from the newest file and backwards. Then you could ask for ranges of
lines and stop early, get feedback earlier (think GUI editor) and stop
early if the whole file was changed sometimes (not sure if this owuld be
common, though).

Best,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 17 19:04:33 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.