W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2002

deltaV write-locks and GET requests

From: Ben Collins-Sussman <sussman@collab.net>
Date: 04 Nov 2002 12:16:24 -0600
To: ietf-dav-versioning@w3.org
Message-ID: <86k7jt42vb.fsf@kepler.ch.collab.net>


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:17:23 GMT

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