[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: Peter N. Lundblad <lundblad_at_softhome.net>
Date: 2004-05-10 12:35:02 CEST

On Mon, 26 Apr 2004 kfogel@collab.net wrote:

> Greg Hudson <ghudson@MIT.EDU> writes:
> > On Sat, 2004-04-24 at 17:06, Peter N. Lundblad wrote:
> > > Please note that I am relatively new to the svn codebase, so my
> > > terminology above may look a bit strange. However, I'd like to know if I
> > > am on the right track and if this is a good way to improve the speed of
> > > the blame command. I think this task shouldn't be too hard for a beginner
> > > like me:-)
> >
> > This plan looks sane to me. You may find that performance doesn't
> > improve by as much as you'd hoped for, because blame will still be
> > incurring a round-trip delay for each revision. Breaking that barrier
> > would require a specialized RA function to retrieve all the revs of a
> > file within a certain revision range.
> I'd like to stress Greg's point, perhaps more than even he would:
> The real speed problem here, for WAN users anyway, is the round-trips,
> because they make 'svn blame' latency-sensitive. I'm not sure it's
> worth addressing svn blame's speed problems without addressing that.
> A new RA function can go into 1.1, as long as no interfaces are taken
> away.
OK. Should I use the svn_delta_editor_t mechanism for this new function.
It would be used in a somewhat unusual way it seems, since
would be called many times on the same file. Would it be better to invent
a new callback, i.e.:
typedef svn_error_t *(*svn_ra_file_revision_handler_func_t)(void *baton,
  svn_revnum_t rev,
  svn_txdelta_window_handler_t *handler, void **handler_baton,
  apr_hash_t *changedprops);

or something. IN that case, we could add the information needed for blame
(path, author, date), but this is maybe too specialized for an RA layer

Any opinions?

Thanks in advance,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 12:25:50 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.