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
apply_text_delta
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
function?
Any opinions?
Thanks in advance,
//Peter
---------------------------------------------------------------------
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