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

Re: Exclusive Locking: 2nd draft

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-05-22 03:09:20 CEST

Ben Collins-Sussman wrote:

>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.
>
>
I think this seems reasonable, modulo the missing specification of what
happens on move and what happens to depth=infinity directory locks. I
see cmpilato already explained those satisfactorily

>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.
>
>
The locks table and the fact that there's a lookup into it is where the
locks and ACLs implementations must cooperate, but I never said we need
long-lived txns for ACLs. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 22 03:09:46 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.