Ben Collins-Sussman wrote:
>The main idea is: a user "locks" a file in the filesystem. This means
>than a new (potentially) long-lived transaction is created in the
>filesystem which represents this one locked file. There's a 1-to-1
>mapping between a locked file and a lock-txn. We keep this mapping in
>a new 'locks' table that maps a path to a txn-id.
>
> * 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.)
>
>
O.K.
> * When somebody tries to read from a non-HEAD revision, everything
> is normal.
>
O.K.
> 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.
This is consistent with current behaviour of SVN's commit transactions.
One benefit is that the locks table doesn't have to be checked on read
operations _except_ if a lock ID is provided.
I realise this is a change from the current locking-plan.txt, but I
believe it's a necessary change. I also understand that this behaviour
is different from the DAV spec, but that doesn't worry me because an
unrelated DAV client can't actually *prove* that we're hiding the
locker's PUTs from him. Several cooperating DAV clients that share the
changed contents of a locked file should be sharing the lock token, too.
> * 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.
>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.
>
>
Yes.
>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.)
>
No, as per above.
> If somebody else tries to do a normal
>Subversion commit which includes a change the locked file, the entire
>commit will be rejected. Ultimately the owner UNLOCKs the file and a
>new revision is created.
>
>
Yes. Note that the meaning of the DAV UNLOCK method is not the same as
the meaning of svn_fs_unlock should be, but we should not let DAV
nomenclature drive our design.
>Really, we envision at least two APIs to end the lifecycle of a
>lock-txn:
>
> 1. A call to svn_fs_unlock() will attempt to commit a single
> lock-txn and create a new revision.
>
> 2. A new svn_fs_commit_txn2() function will take a "main" txn as
> usual, but also take a list of lock-txns. It would first merge
> the lock-txns into the main txn, then merge the whole thing with
> the HEAD revision.
>
>
As I said, svn_fs_unlock should mean something else; othewise, it's just
a synonym for svn_fs_commit_txn2 with a NULL main txn ID and a single
entry in the lock list.
>Depending on how we design the new commit function, we might also want
>to give users the option to "hold on" to their lock-txns after the
>commit completes. (In other words, delete the temporary main txn, but
>not the lock-txns.)
>
>
Yes, this is usually the check-in command's "keep checked out" option in
locking VC systems; sometimes known as "checkpoint" instead of "check-in".
Note that if you want to completely simulate DAV behaviour, then PUT on
a locked object could be implemented as a checkpoint rather than a
checkin; and UNLOCK suddenly becomes the same as svn_fs_unlock. The
drawback is that you generate a new revision with each PUT.
>There's at least one annoyance with this design: operations like
>'move' and 'delete' must verify that no locks exist for paths below
>the deleted/moved thing. This requires scanning the table of locked
>paths, or doing a 'reverse directory walk'. Actually, it may be slow
>in general to scan a locks-table -- we're talking about doing it for
>every read of a path@HEAD and every write of a path.
>
>
A reverse directory walk is not necessary if the locks table is designed
correctly (in fact, correct layout of the locks table is *the*
interaction point between locks and ACLs; since both features require a
lookup table, it makes sense to use the same table and do the lookup
once). I'll talk about the structure of the lookup (locks) table in a
separate post.
-- Brane
---------------------------------------------------------------------
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:09:35 2004