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

Re: Speeding up blame

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2004-05-28 22:24:30 CEST

On Fri, May 28, 2004 at 09:16:51PM +0200, Peter N. Lundblad wrote:
> > It would be neat if the fact that the WC adm area contains the
> > pristine BASE rev could be brought into play (perhaps the RA layer
> > would retrieve the delta from BASE->start rather than the fulltext
> > of start), but the wins in terms of network i/o are probably not
> > worth the additional implementation complexity.
> >
> I think this would be an optimization that is worth it when blaming a
> small revision range near BASE. But then you have little data transfered
> anyway... Don't think it is worth the complexity.
>

I agree.

> > One last blue sky idea:
> >
> > Right now, svn_client_blame() uses svn_diff_file_diff(),
> > but there is also a generalized interface that could be applied
> > to streams. Using that interface, it should be possible to
> > avoid constructing any of the fulltexts at all, since the
> > stream of revision N+1 can be computed from the stream of
> > revision N and the delta from N to N+1.
> >
> How do you apply this to a forward-only svn_stream_t? It needs to be able
> to compare arbitrary tokens, it seems.

Judging from the svn_diff_fns_t interface, the stream needs only to be
restartable, not random-accessible.

We already have a delta combiner...

>
>
> In ra_local, we don't need deltification at all. We just use
> svn_fs_file_contents for each interesting revision.
>

I'm not sure what this will gain us; the deltas will still need
to be combined somewhere.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 28 22:25:00 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.