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!
>
> IE you request blaming for revision 0-1000,
> We discover, after getting to revision 950, that all the lines have been
> blamed.
>
> There is no need for us to continue to get revision 0-950.
Exactly.
>
> 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.
> The server will be in the middle of sending us a report (in the case of
> dav), or sending us the file-revs data, and i don't believe any of those
> have provisions to handle getting data sent back in the middle.
>
Right. But draining the pending data is much better in certain
scenarios than dropping the connection. By passing a "max revcount"
parameter, a tighter limit is placed on the amount of pending data
that would need to be drained.
It also might make sense to make the drain/close behaviour a parameter;
the svn command-line client could happily close the connection and
return control to the user more quickly, while libraries that would
rather not abandon the connection could get the other behaviour.
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.
--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 04:16:38 2005