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