On Tue, 29 Mar 2005, Mark Benedetto King wrote:
> On Tue, Mar 29, 2005 at 08:23:38PM -0500, Daniel Berlin wrote:
> > > > 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.
> >
> > I'm not sure what you guys are suggesting.
> > You guys understand that the error is returned when we discover we've
> > blamed all the lines necessary to present to the user before we hit the
> > oldest revision they request. This happens when, for example, an entire
> > file is replaced in some revision.
>
> What we're suggesting is that whether or not an error is returned, it
> would be nice if the connection could be left in a reusable state.
>
> As an aside, perhaps an extra output parameter could be used to indicate
> the nature of the completion, rather than a distinguished error code?
> It isn't really an error at all; in fact, it's a good thing!
>
I like that better than abusing the error mechanism:-) OTOH, we treat
cancelation as an error. Not sure where to draw the line.
> >
> > So unless you are saying i should have blame be requesting revisions in
> > batches of 100 or something (I'm not sure how slow this is) and just eat
> > the extra 50 revisions (which still seems like a waste), there's no
> > "good" way to handle this other than
>
> That's exactly what I was suggesting, except that I was thinking 20.
> I suppose the client could adaptively adjust the batch size based on
> the rate of blame convergence or something, but I'll bet some number
> between 20 and 50 works pretty well most of the time.
>
> > 1. notifying the server
> > 2. just dropping the connection.
> >
> > 1 would require asynchronous handling of some sort, would it not?
>
> Yes, so it's a non-starter.
>
Not so sure. We already have that in the editor in libsvn_ra_svn. Take a
look at editorp.c. The edit consumer can return an error response early.
Then the producer stops (after a while). I don't know how
libsvn_ra_dav/mod_dav_svn handles this. But it has to drop connections for
a single sesson for other reasons, so maybe it just does that. Maybe the
0.25 release will help here.
This is a more complex solution than your "fetch some revisions at a time"
proposal. the performance difference might be worth investigating, though.
> PS:
>
> Another nice thing about the reverse blame is that it can notify
> a UI as lines are blamed; that means that a GUI could actually fill
> in blame info incrementally.
>
Yes, this is nice, maybe cool as well:-) svn_client_blame would have to be
allowed to pass the information out-of-order then.
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 30 13:36:42 2005