> > 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.
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.
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
1. notifying the server
2. just dropping the connection.
1 would require asynchronous handling of some sort, would it not?
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.
--Dan
---------------------------------------------------------------------
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:24:49 2005