Lieven Govaerts <lgo_at_apache.org> writes:
> First of all, because that's not guaranteed to be or stay that way.
> Take for instance svnsync. It currently sends two non-pipelined
> OPTIONS requests (to my surprise) from:
> 1. svn_ra_serf__exchange_capabilities
> 2. svn_ra_serf__v2_get_youngest_revnum
>
> I consider the request sent by svn_ra_serf__v2_get_youngest_revnum in
> this case a bug. The second OPTIONS request and response is identical
> to the first, the only reason why it's sent is because ra_serf doesn't
> cache the latest revision number from the response to the first
> request.
>
> So suppose I fix that bug, your assumption isn't valid anymore for svnsync.
It's possible that some operations will fail, but if they fail they will
do so in exactly the same way they currently fail right now. The user
handles it in exactly the same way: modify the config to enable the
extra OPTIONS probe.
> Second, IMO the bottleneck is not in having to send the extra second
> request, but the fact that we have to wait for the response to any
> second request before we can start pipelining the 3rd,4d... request.
> It's better to send two small requests to find out the capabilities of
> the whole chain asap, instead of having to retry a potentially
> expensive update REPORT (takes time to create, to spool to disk, to
> re-read and stream over the network).
Not all REPORTs are expensive. Your example, syncsync, sends very
simple REPORTs.
It's much more convenient for the user if the client just works. We can
still notify to suggest that the user sets the config option to enable
the OPTIONS probe.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
Received on 2013-07-09 13:59:58 CEST