On Wed, 2010-01-06 at 08:37 -0800, Justin Erenkrantz wrote:
> On Wed, Jan 6, 2010 at 7:54 AM, Mark Phippard <markphip_at_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.
> 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
Received on 2010-01-06 18:04:00 CET