Re: Exclusive Locking: design in a nutshell

On 2004-05-19 16:54-0500, Ben Collins-Sussman wrote:

> * When somebody tries to write to any path, the filesystem checks to
> see if a lock-txn already exists for it. If so, and if the writer
> owns the lock-txn, then the new data is put into the lock-txn,
> overwriting whatever was previously there. (And obviously, if the
> writer doesn't own the lock-txn, the write is rejected.)
>
> * When somebody tries to read from a non-HEAD revision, everything
> is normal. When somebody tries to read from the HEAD revision,
> the system treats locked paths specially: instead of pulling the
> file's data out of the HEAD revision, it gets pulled out of the
> appropriate lock-txn.
>
> * The lock-owner ultimately ends up "unlocking" the file, which
> causes the lock-txn to be committed. Either that, or the lock
> owner destroys the lock, which aborts the lock-txn, and all
> changes are lost.
>
> The net affect of this (from a WebDAV client's point of view) is that
> a user can LOCK a file indefinitely and do any number of PUTs to it.
> People who do checkouts of HEAD, or just GETs of the file, will always
> see the file's latest text (that is, whatever text was most recently
> PUT by the lock-owner.)

I see following problems with this behavior:

1) You could get a version X of file at time T, and later, get a
   different content for the same file, for same version X.
  
   <http://svnbook.red-bean.com/svnbook/apa.html#svn-ap-a-sect-1>
   
       "In Subversion, the repository looks like a single
       filesystem. Each commit results in an entirely new filesystem
       tree; in essence, the repository is an array of trees. Each of
       these trees is labeled with a single revision number. When
       someone talks about .revision 54., they're talking about a
       particular tree (and indirectly, the way the filesystem looked
       after the 54th commit)."

   So you could now have two or more different trees for same version
   number. I think that this is a problem.

2) You could get a particular content for file (at version X), and
   later find that this data has vanished completely from system (Locker
   has done an unlock). This is problematic, because a version control
   system should let traces of all data that it handles, imho.

Ben told in IRC that this behavior is by WebDAV spec: every PUT to
the locked object is visible to the world.

Ben suggested that it might be possible to make lock-txns only
readable to the locker, when other world won't get mutable data from
HEAD. I am huge fan of that idea, and will purchase fans and flags
and wave them maniacally, if this semantic will be chosen for
Subversion.
 

BR, Jani

-- 
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org