On Wed, 2010-01-06 at 08:37 -0800, Justin Erenkrantz wrote: > On Wed, Jan 6, 2010 at 7:54 AM, Mark Phippard <markp...@gmail.com> wrote: > > Apparently, the PROPFIND is using the proxy at a time when it needs to > > be using the master. > > The client has no knowledge of the master - the slave a completely > transparent proxy. The only way to distinguish between a PROPFIND for > an update or a commit is to have the client give some indication about > what it's intending.
It doesn't sound like we're asking quite the right question. Rather than "Is this PROPFIND for an update or is it for a commit?", I think we need to be asking something like "Does this PROPFIND need to see a more recent revision than the latest cached revision? It does if this client has (ever) created or is currently creating a newer revision." Another way to look at the whole issue is that the proxy should give the client a consistent view of what revision is "head". It doesn't matter if that revision number is a bit older than the master's head, but as soon as that client has reason to have any knowledge of a newer revision (e.g. by doing a commit), the proxy should from that moment onwards provide a view of that newer revision. The question then is how to identify "this client" - if the best information we have is to recognize "this client connection" then we can't support multi-connection requests automatically (except by heuristics). In that case, the information the client needs to supply is some sort of unique client id, or alternatively its last known head revision number. I don't think any sort of "operation name" is sufficient, because, for example, "svn commit" followed immediately by "svn up" should be guaranteed to update the WC to at least the revision number of the commit, whereas with the proposed operation-name scheme I think it would update to the last cached revision which can be older than the commit. - Julian > By using an HTTP header, the slave can check > header and then proxy that PROPFIND to the master. (This will likely > make all PROPFIND's on a commit hit the server, but, eh, so be it.) > -- justin
