Jani Averbach wrote:
>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.
>
>
Do you know I completely forgot about this argument? And it's better
than mine.
>Ben told in IRC that this behavior is by WebDAV spec: every PUT to
>the locked object is visible to the world.
>
>
That's true, IMHO broken, but also irrelevent, I think.
>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.
>
>
+1eU+03C0 GREEK SMALL LETTER PI
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 20 01:27:32 2004