You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <lu...@softhome.net> on 2004/05/10 10:35:02 UTC
Re: Speeding up blame
On Mon, 26 Apr 2004 kfogel@collab.net wrote:
> Greg Hudson <gh...@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
Re: Speeding up blame
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 23 May 2004, Greg Hudson wrote:
> On Sat, 2004-05-22 at 18:51, Peter N. Lundblad wrote:
> > I don't understand this. If we add a new function pointer to the rA
> > vtable, then any RA implementation that is done for 1.0 will be
> > ABI-incompatible with 1.1. Or isn't the compatibility guarantees about
> > ABI?
>
> We don't actually have a mechanism for third-party RA implementations.
> (We have a mechanism for dynamic loading, but that's still controlled by
> a hardcoded table in libsvn_ra.) So we don't have to worry about that.
>
Thansk. That was what I wanted to hear:-)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Speeding up blame
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-05-22 at 18:51, Peter N. Lundblad wrote:
> I don't understand this. If we add a new function pointer to the rA
> vtable, then any RA implementation that is done for 1.0 will be
> ABI-incompatible with 1.1. Or isn't the compatibility guarantees about
> ABI?
We don't actually have a mechanism for third-party RA implementations.
(We have a mechanism for dynamic loading, but that's still controlled by
a hardcoded table in libsvn_ra.) So we don't have to worry about that.
We do need to probably bump the libsvn_ra ABI number for 1.1, to provide
a clear error message if someone tries to accidentally load a 1.0 RA
module into a 1.1 set of libraries. The reason is that RA modules have
dependencies, so, for instance, {1.0 built with neon} overlaid with {1.1
built without neon} will result in an inconsistent set of libraries.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Speeding up blame
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>>On Mon, 26 Apr 2004 kfogel@collab.net wrote:
>>
>>> new RA function can go into 1.1, as long as no interfaces are taken
>>>away.
>>>
>>>
>I don't understand this. If we add a new function pointer to the rA
>vtable, then any RA implementation that is done for 1.0 will be
>ABI-incompatible with 1.1. Or isn't the compatibility guarantees about
>ABI?
>
>
The RA vtable is a structure, and adding new fields to the end of a
structure is guaranteed to not change the layout of the existing fields.
This means that a 1.1 client that expects a new RA function wouldn't
work correctly with a 1.0 library, but a 1.0 client _would_ work
correctly with a 1.1 library.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Speeding up blame
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > > A new RA function can go into 1.1, as long as no interfaces are taken
> > > away.
>
> I don't understand this. If we add a new function pointer to the rA
> vtable, then any RA implementation that is done for 1.0 will be
> ABI-incompatible with 1.1. Or isn't the compatibility guarantees about
> ABI?
Can't we add new functions to the end of the table, due to C's
guarantees about structure member ordering and alignment? I presume
these guarantees apply even to structures of function pointers...
(In which case this work does not need to be done on a branch.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Speeding up blame
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Hi,
Now that the svn_cmdline_printf stuff is almost done (modulo encoding
possible regressions:-(, I'm actually considering giving this a try.
My plan is to start in the repository with a new API to get all revisions
of a file in deltas (as discussed earlier). That shouldn't have an impact
on the rest of the code because it is a new API. Then, I'm going to
continue on each RA implementation. This will change the ra vtable, so at
least this part should be done in a branch, I suppose.
Do you want me to do all of the work in a branch, or just the last part.
Of course I can't guarantee it will be ready for 1.1.
> On Mon, 26 Apr 2004 kfogel@collab.net wrote:
>
> > A new RA function can go into 1.1, as long as no interfaces are taken
> > away.
> >
I don't understand this. If we add a new function pointer to the rA
vtable, then any RA implementation that is done for 1.0 will be
ABI-incompatible with 1.1. Or isn't the compatibility guarantees about
ABI?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Speeding up blame
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Mon, 2004-05-10 at 06:35, Peter N. Lundblad wrote:
>
>
>>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.
>>
>>
>
>If we're using the editor implementation, it would have to be done as a
>series of independent edits, or we'd be abusing the editor contracts. I
>would only recommend taking this route if we foresee extending this
>function to handle directories as well as files, and I haven't thought
>through the ramifications of that (nor have I identified a use case for
>it).
>
>
The case for blaming a directory is the same as the case for diffing a
directory -- to see who added which file when. A directiry diff would of
course show how the directory changed through history. We sort of show
that in a diff, but the format is not exactly readable. But we'v had
long discussions about a generalized patch format, anyway...
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Speeding up blame
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-05-10 at 06:35, Peter N. Lundblad wrote:
> 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.
If we're using the editor implementation, it would have to be done as a
series of independent edits, or we'd be abusing the editor contracts. I
would only recommend taking this route if we foresee extending this
function to handle directories as well as files, and I haven't thought
through the ramifications of that (nor have I identified a use case for
it).
> 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);
That might be best. Try to avoid the cosmic gargantuan type name;
something like svn_ra_file_rev_handler_t should be sufficient.
> 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?
Good question. We could just pass all the rev-props as a hash; that
doesn't seem too specialized.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org