On Nov 5, 2004, at 12:00 PM, Philip Martin wrote:
>
> I assume that if a lock is unlocked during a transaction then the
> transaction will fail. If so then svn_fs_apply_txdelta doesn't need
> to validate locks (although it might do it to error out early). In
> the end it's the function svn_fs_commit_txn that needs to check locks.
> All that apply_txdelta needs to do is add to the list of locks that
> commit_txn needs to verify.
You are correct. All of this fuss is about making a bunch of fs
functions "error early" when something is locked. Just like our
out-of-dateness checks, svn_fs_commit_txn() is the "main" and final
enforcer. See the stuff I just committed to
notes/locking/locking-implementation.txt. Point #4 in particular
discusses this in more detail.
>
> If svn_fs_apply_txdelta is responsible for validating locks then I
> think we need some mechanism to either prevent locks being unlocked
> while they are "in use" by a transaction, or to fail a transaction
> that is using a lock that has been unlocked. The latter appears to
> involve svn_fs_commit_txn again.
>
I don't think there's any problem here. User A begins a commit
transaction, and is changing a file he has already locked, thereby
making use of his lock-token. Meanwhile, user B forcibly breaks user
A's lock. User A finishes the transaction, and svn_fs_commit_txn()
does the "final" lock check: I don't think it should fail, just
because the lock was broken behind its back. It just means that the
final commit requires fewer lock-checks than the number of lock-checks
originally required "on the fly". No big deal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 19:36:06 2004