On Tue, Mar 29, 2005 at 12:18:29PM +0200, Peter N. Lundblad wrote:
> On Thu, 24 Mar 2005, Daniel Berlin wrote:
>
> > Sussman asked me to post the current work i have on streamy blame (done
> > by blaming files from youngest revision to oldest, instead of the other
> > way around) since it was hoping to be ready for 1.2.
> >
> I think this improvement is worthwhile, but I thought it was mostly about
> streaminess, not speed. sussman gave another impression in his mail.
>
There are two speed improvements (that I'm aware of):
The O(n^2) blame bookkeeping is gone, replaced with a new datastructure.
I haven't looked at the new one, but it could hardly be worse. The new
datastructure allows for early termination, which can be a big win.
There is also a perceived speed improvement due to the reduced latency
(gcc blames were spending a long time server-side before the revision list
was sent to the client). This should also improve overall system
scalability, since it takes load off of the server.
> >
> > Otherwise, i plan on testing and committing the server side and api
> > changes(IE everything but the call to reverse_blame and the associate
> > reverse blame functions on the *client* side), because it adds an
> > argument to svn_ra_get_file_revs, which is new API for 1.2, and thus, if
> > we don't do it now, we're going to have to add *another* function in
> > 1.3.
> >
> I don't see a problem with revising another API. I don't like pushing in
> an API change this late in the 1.2 cycle, though. And since this
> functionality won't be used before 1.3 anyway (it isn't for a patch
> release), I don't see the point in doing this.
>
> > Unless someone has a better idea, or believes we should put it all off
> > *anyway*,etc.
> >
> >
> I think the idea is fine and I'm willing to work with you with it for 1.3.
> But I htink we should punt for 1.2. (Blaming bing ChangeLog files isn't
> that a common use case, is it?:-) > --Dan
>
I think they're worth the disruption. We're putting in locking!
That's a much bigger thing, IMO, and much more likely to have bugs.
> I also have some API comments, which might make my arguments stronger...
>
> > Index: subversion/include/svn_error_codes.h
> > ===================================================================
> > --- subversion/include/svn_error_codes.h (revision 13634)
> > +++ subversion/include/svn_error_codes.h (working copy)
> > @@ -884,6 +884,12 @@
> > SVN_ERRDEF (SVN_ERR_CLIENT_MISSING_LOCK_TOKEN,
> > SVN_ERR_CLIENT_CATEGORY_START + 13,
> > "Path has no lock token")
> > +
> > + /* @since New in 1.2. */
> > + SVN_ERRDEF (SVN_ERR_CLIENT_DONE_WITH_BLAME,
> > + SVN_ERR_CLIENT_CATEGORY_START + 14,
> > + "Client finished blame early")
> > +
> >
> Earlier, we've rejected new error codes for such special cases. For
> example, I have a memory of us rejecting the Java bindings wanting to ad
> an error code for filtering exceptions.
>
> Also, I don't like the implementation technique. This is the same
> technique that svn log --limit used to exit early. The problem is that it
> leaves the connection useless afterwards (mostly thinking of svnserve
> here). We should consider designing the protocol in such a way that we can
> exit gracefully, so that other users than libsvn_client could use it,
> without having to punt on the RA session.
>
How about adding a "max revisions" parameter? The client can always
restart where it left off if it wants more revisions. Choosing a number
like 20 would remove ~95% of the latency of roundtripping for each
revision, without leaving the client to drain the firehose of 10000
changelog revisions.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 03:12:55 2005