Greg Hudson wrote:
> On Wed, 2003-10-22 at 16:52, Tobias Ringström wrote:
>
>>The current implementation of both ra_svn and ra_dav are implemented
>>without overlapping requests. In other words they always wait for the
>>response from the server for the previous request before sending the
>>next request.
>
> That's not true; ra_svn defers the responses to many requests in order
> to reduce the round trip count.
True. The remaining culprits are close-file and close-dir.
>>So what do you think? Can we make the protocols streamy? Should I create
>>an issue?
>
> The big question is, "how?" I think it would be especially hard with
> ra_dav, but just thinking about ra_svn, here are the options I see:
>
> * Defer edit errors until close_edit(). This would destroy the
> property that commits fail before file data is transmitted, and would
> mean that if a big import fails close to the beginning, the client
> wouldn't find out until it has transmitted all the data.
This one would be simple to implement.
> * Defer edit errors until close_dir(). This wouldn't make the
> protocol quite as streamy as you'd like, but would preserve the commit
> property and would reduce the number of round trips. It would also mean
> that big imports would fail reasonably quickly after an error occurs.
This one feels like a half-hearted solution, and if you have lots of
directories with few files in them you will be hurt by this.
> * Add a new editor function called something like
> get_deferred_error(), which would be optional to implement (the default
> implementation returns SVN_NO_ERROR). Defer ra_svn errors until
> close_edit or get_deferred_error time. The driver then gets to decide
> how to trade off round trips versus failure latency. commit might call
> get_deferred_error() just once before sending the postfix deltas; import
> might call it once per directory or something.
All of these suggestions are protocol changes, but it is possible to
solve this without changing the protocol. I don't think it's *too* hard
to implement overlapping requests, as in the following example.
1. send file 1
2. send file 2
3. read status (for file 1)
4. send file 3
5. read status (for file 2)
6. etc.
The protocol will never be out of sync since all requests are serialized
and we know what we have sent. (Unless of course the status for file 1
means that we may not send file 2.)
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 23 01:44:04 2003