W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: DAV:lockdiscovery on a checked-out resource

From: Greg Stein <gstein@lyra.org>
Date: Mon, 26 Mar 2001 18:47:11 -0800
To: Steve K Speicher <sspeiche@us.ibm.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20010326184711.L27539@lyra.org>
If you're going to have DAV:auto-version == "never", then I'd simply suggest
refusing the LOCK request.

As an empirical data point, mod_dav with Subversion for a back-end will NOT
support locking at all (nor auto-versioning). Some future version, maybe.
Instead, we will simply require a version-aware client (which is fine; the
SVN command line client is our only required client at this time, and it is
certainly aware :-)

Cheers,
-g

On Mon, Mar 26, 2001 at 09:39:38AM -0500, Steve K Speicher wrote:
> 
> > Acquiring a LOCK on a checked-in version-controlled resource is harmless,
> > but versioning semantics will prevent the content of the checked-in
> > version-controlled resource from changing anyway.
> 
> Take the following typical actions of a non-versioning aware client:
> LOCK /foo
> GET /foo
> PUT/foo
> UNLOCK /foo
> 
> If the resource is a VCR, then I think what you are saying is that the LOCK
> will succeed and the PUT will fail (if DAV:auto-version is "never"), since
> the resource is DAV:checked-in and modifying it would therefore change an
> already existing version of /foo (not good).
> Though, if the PUT would fail with Locked status-code (assuming it would)
> but the client would realize that they owned the lock on the resource and
> think, "Now what do I do?".
> 
> I realize that wanting your versioning server to be DAV class 2 compatible,
> you wouldn't/shouldn't have DAV:auto-version  of "never".  Do I have a
> point?  I guess I just want some justification on my interpretation of this
> and if the PUT does fail, with what status-code: "423 Locked", ???
> 
> Thanks,
> Steve

-- 
Greg Stein, http://www.lyra.org/
Received on Monday, 26 March 2001 21:47:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT