RE: deltaV write-locks and GET requests

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