Florian Weimer wrote:
>* Branko Čibej:
>
>>> 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.
>>>
>>>
>>>
>>>
>>Nope.
>>
>> When anyone except the lock owner tries to read from the HEAD
>> revision, everything is normal. When the lock owner tries to read
>> from the HEAD revision, the system treats locked paths specially: ...
>>
>>The point here is that a lock on a file (or directory, don't forget
>>about depth-infinity directory locks) creates a transaction. The
>>isolation principle says that the results of activities that happen in
>>the context of a transaction are not visible outside this context
>>until the transaction is committed. In other words, only the lock
>>owner can see uncommitted changes to the locked file.
>>
>>
>
>By default, yes. Dirty reads on HEAD are too surprising, IMHO.
>
>
Indeed.
>But I think it should be possible to view the pending commit, as
>stored in the repository. This enables some nifty applications (for
>example, you could render a document on the server and have the
>creator review it, before it is actually committed). It's not clear
>that it's worth the additional complexity, though.
>
>
That is a separate issue and in fact a separate planned feature. I'm
sure it could be useful, but it has no bearing on the locking design.
>>> * 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.
>>>
>>>
>>Ah...point of terminology here: "unlock" means "release the lock,
>>discarding changes"; "commit" means "release the lock, keeping
>>changes". It's much more obvious that way, and you don't have a third
>>destroy-lock function.
>>
>>
>If there's "commit", there also should be "abort" or "roll back".
>
>
My definition of "unlock" is exactly "abort".
---------------------------------------------------------------------
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:31:09 2004