[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Make svn clients indicate their operation name to backend(right now only to DAV)

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 06 Jan 2010 17:11:14 +0000

I (Julian Foad) wrote:
> 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.

When I say, "I think ...", I mean that I am just thinking through in my
head how I suppose this would work. I hope someone more knoledgeable or
who is prepared to test it will correct me if I'm wrong.

- Julian
Received on 2010-01-06 18:11:54 CET

This is an archived mail posted to the Subversion Dev mailing list.