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

RE: Adding a no-op LOCK to mod_dav_svn

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2003-01-05 14:03:28 CET

> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Saturday, January 04, 2003 6:23 PM
> To: Julian Reschke
> Cc: dev@subversion.tigris.org
> Subject: RE: Adding a no-op LOCK to mod_dav_svn
> On Sat, 2003-01-04 at 07:17, Julian Reschke wrote:
> > This sounds like you're suggesting to allow multiple clients to
> > the same resource at the same time, obtaining the same lock token.
> I didn't say the lock token would only contain the crev or
> node-revision-id; it could also contain a uniquifier.
> Unfortunately, I can't come up with a totally correct abstract
> justification for a stateless lock mechanism. I could say that when the
> second client asks for a lock (or even asks for "lock discovery" per RFC
> 2518 section 6.6), the first client's lock is abstractly discarded. But
> that's not really true; the first client's lock will still be honored as
> long as the resource has not been changed.

I think this can't work by definition. LOCK creates a resource identified by
the lock token (which happens to be a URI), and that lock is associated both
with the HTTP resource being locked and the namespace it protects. RFC2518
(sect. 6.3) even calls a lock token a "state token".

> ...


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 5 14:04:34 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.