- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 4 Nov 2002 13:49:08 -0500
- To: ietf-dav-versioning@w3.org
- Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED533@SUS-MA1IT01>
Yes, a PUT to a write-locked item should be immediately visible to a subsequent GET on that write-locked item. Any other behavior is relatively certain to confuse existing clients. Cheers, Geoff -----Original Message----- From: Ben Collins-Sussman [mailto:sussman@collab.net] Sent: Monday, November 04, 2002 1:16 PM To: ietf-dav-versioning@w3.org Subject: deltaV write-locks and GET requests Hi, I'm Ben, one of the main developers for the Subversion project. (http://subversion.tigris.org) You're probably aware that our 'server' is mod_dav_svn, a provider to mod_dav which implements a subset of DeltaV. I'm investigating what it would take to implement auto-versioning, so that programs like MS Office could operate directly against a Subversion repository, using vanilla RFC 2518 requests: LOCK, GET, PUT, PUT, PUT, UNLOCK. At the moment, mod_dav_svn doesn't support any locking at all. But I hope to change that. :-) Anyway, here's my question: if the holder of an exclusive write-lock executes a PUT on a write-locked item, does the change become immediately visible to the world? Will subsequent GETs from non-lock-holders see the latest version? Or should they see the 'old' version (as it looked before the write-lock), until the the resource is unlocked? I've scoured both rfc 2518 and 3253, and this question doesn't seem to be answered explicitly. My intuition is that every single PUT should be publically visible, whether a resource is write-locked or not. On the other hand, it would be a lot easier to implement the latter behavior in Subversion. The only section I could find that *might* be relevant is this. It doesn't say much: RFC 2518, 7.1: A write lock MUST prevent a principal without the lock from successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock. Anyway, I thought I'd turn to this discussion group for feedback. Thanks in advance for your help.
Received on Monday, 4 November 2002 13:49:53 UTC