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

Exclusive Locking: 2nd draft

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-05-20 18:22:21 CEST

Great discussion, folks. Allow me to take back the microphone and
create a new, simpler proposal based on yesterday's threads.

I'm now in the camp with ghudson and jpieper: I don't think we need
special "lock-txns" at all. It's a bunch of unnecessary complexity.
All we need is a lock table that describes which paths are locked by
whom.

Use case #1: svn client

   LOCK -----> path cannot be locked or committed by anyone else.

   GET -----> returns path@HEAD universally. existence of lock is
                irrelevant.

   commit ----> allowed on path IFF you own the lock.
                (ra_svn does this using its own protocol,
                 ra_dav does this via deltaV:
                       MKACTIVITY, CHECKOUT, PUT, MERGE)

   UNLOCK ----> lock is removed. others can lock or commit the path.

Use case #2: dumb dav client

   LOCK -----> path cannot be locked or committed by anyone else.

   GET -----> returns path@HEAD universally. existence of lock is
                irrelevant.

   PUT ----> if (autoversioning is on)
                   instant commit. allowed, assuming you own the lock.
                else
                   return error("Use deltaV, you dummy.")

   UNLOCK ----> lock is removed. others can lock or commit the path.

Note that the autoversioning feature already exists: if turned on, an
ignorant PUT is already treated as a {MKACTIVITY, CHECKOUT, PUT,
MERGE}. The reason you can't open a file in MS-Word directly from the
repository is simply because we don't support the LOCK/UNLOCK methods
yet. That's why current users of autoversioning have to "drag and
drop" a file into a repository, just to get a lone PUT to happen.

In any case, this seems like a very simple proposal to me. I know
that Branko still wants to create 'lock-txns' for his ACL strategy,
but I'd like to know more about that.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 20 18:26:53 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.