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.
"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
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu May 20 01:15:39 2004