Ben Collins-Sussman wrote:
>On Thu, 2004-05-20 at 15:15, Josh Pieper wrote:
>
>
>
>>>The DAV spec speaks of shared (read and write) locks, but doesn't
>>>specify how they behave. Therefore we can do anything that's reasonable.
>>>IMHO the only thing that's reasonable is for all clients that have a
>>>shared lock on the same object to see the same contents. Ergo,
>>>transaction-per-lock.
>>>
>>>
>>If every PUT caused a commit without using shared transactions, the
>>same result would occur, correct? All clients who hold the shared
>>lock would see the results as soon as a PUT is issued. It would just
>>have the side effect of allowing clients who don't have the shared
>>lock to see the results of each PUT as well.
>>
>>
>
>Yes, you're right. That's how I understand it.
>
>A "lock", whether it be shared or not, is just a row in a table that
>means, "this person (or persons) has exclusive rights to commit to the
>HEAD version of this path."
>
>
Can we now please stop letting DAV specifics drive our FS design? We've
moved from FS functionality to LOCK/PUT/UNLOCK semantics as if there's
no difference between the two. Basing the FS functionality on the DAV
functionality can never be the right way to go about this, for one thing
because DAV is stateless and web-centric and therefore has to make all
sorts of compromises. It is *not* a good example for desigining version
control features.
I insist we should approach this the other way around: decide first
about how we want the FS to behave, from the point of view of a
versionable transaction-based filesystem. Then we can decide how to map
that to DAV.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 21 08:53:15 2004