[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Exclusive Locking: design in a nutshell

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: 2004-05-20 11:01:40 CEST

Ben Collins-Sussman wrote:

> On Wed, 2004-05-19 at 18:42, Greg Hudson wrote:
>
>>Well, as others have pointed out, you've invented something that works
>>for WebDAV and doesn't work for Subversion.
>
>
> Yeah, looks like a semantic incompatibility, eh?
>
> DAV says that every PUT to a resource, regardless of whether it's locked
> or not, should be GETtable by the whole world.
>
> Subversion then has the choice of (1) making every PUT into a commit,
> which can get very messy and annoying with most auto-saving DAV clients,
> or (2) violate DAV, and make a lock-holder's GET show something
> different than what the general public sees.
>
> Gstein, our resident DAV expert, has a proposal to resolve this. I just
> alerted him to this thread, so he'll be posting shortly.

This sounds a bit like we have two entirely different use cases, and
trying to implement them using one mechanism (not surpringly) doesn't
work well.

Case #1: "Edit with Office (Word)"

As others have pointed out, Office LOCKs the file, and sends PUT each
time the clients saves (not sure about auto-saving). It also refreshes
the lock each 180 seconds (WebDAV locks may come with a timeout; but
that's optional). Only when the file is closed, Office sends a PUT and a
final UNLOCK.

Most people will expect (and RFC2518 requires this) that any change that
was PUT will be visible to other users (note if it's not you will also
have to consider HTTP caching!).

This scenario works absolutely wonderful with a server that supports
RFC32523-style autoversioning (I think svn does). See
<http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_auto-version>.

Case #2: "Lock through SVN client"

I hear that this shouldn't only keep other people from modifying the
file, it also shouldn't publish changes to other users until the svn
lock is gone. It seems to me that the simple answer to this *extended*
requirement is not use WebDAV LOCK/UNLOCK alone, but also to use
RFC3253's working resources.

In the case where a single file is locked this would mean:

- LOCK the file (keep others from modifying it)
- CHECKOUT a working resource
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.9>), this
creates a new version controlled resource (with a new URI)
- (possibly LOCK that one as well)
- keep modifying (GET/PUT)
- CHECKIN and UNLOCK original resource

This will satisfy the requirement of the contents of the original file
not changing until the transaction is finished.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 20 11:02:07 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.