- 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
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 UTC