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

Re: 'svn blame' speedup in 1.2

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-03-26 04:41:57 CET

On Fri, 2005-03-25 at 14:24 -0600, Ben Collins-Sussman wrote:
> 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...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + one way or

IE it needs to know explicitly what lines were added, and explicitly
what lines were deleted, in between two revisions.

Theoretically, one should be able to use the libsvn_diff API, which
tells you "lines from start to end in original were modified to become
lines start to end in new file", and produce the explicit adds and
deletes from that, but i haven't been able to get it to work right.

In fact, diff -n is more or less doing this in order to produce the info
it gives us. So we should be able to do it too :).

> 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.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 26 04:43:30 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.