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

'svn blame' speedup in 1.2

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-25 21:24:46 CET

After chatting with Daniel Berlin in IRC, let me explain what's going
on with 'svn blame' in 1.2, for those who haven't been following.

The goal is to bring what is essentially a 5x speedup to absolutely
everyone. In order to achieve that speedup, Daniel's plan looks like
this:

    A. use xdelta instead of vdelta in the repository.

    B. expand svn_ra_get_revisions() to optionally return fulltexts in
       youngest->oldest order, rather than our current oldest->youngest
       order.

    C. teach the client a new algorithm to process the incoming
       youngest->oldest fulltexts.

Part (A) is finished and committed. Even by itself, this change makes
reconstruction of older files much faster. (Admins will need to
dump/reload to see this benefit, of course.)

Part (B) is done, and is the patch Daniel just posted. It implements
the server-side code for delivering fulltexts in the new order, as
well as all three RA implementations of the new request. It could be
committed anytime.

Part (C) is the current blocker. The new annotation algorithm needs
to read commands to explicitly add and delete lines... it's what 'diff
-n' shows. libsvn_diff has no such API -- it merely says "change this
set of lines to this new set." So as a temporary shim, Daniel's patch
is calling out to GNU diff... which really isn't acceptable.

What would be great is if someone could add the new API to libsvn_diff
(sander?), so we can finish and commit (C).

Our other option is to punt on (C), and not have svn 1.2 clients call
the new RA request yet. If we did that, then the 'svn blame' speedup
would still be apparent on files with relatively short history (less
than 5000 versions). But for files with really long history (like
those in gcc), the speedup wouldn't be there. The client would still
be asking for oldest->youngest fulltexts, and there's a huge delay
before the server even begins to send the first file. :-(

I hope this clarifies what's going on here. I'd really like to have
(C) make it into 1.2, since that means gcc (and potentially other very
old, prestigious projects) can finally convert to svn.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 25 21:25:57 2005

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.