Re: svn commit: r11750 - branches/locking/subversion/include

Ben Collins-Sussman <sussman@collab.net> writes:

> 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.

Really?

- User A begins commit
- Commit (svn_fs_apply_txdelta) validates lock on foo
- User B breaks A's lock on foo
- User B locks foo
- User B edits foo
- Commit completes even though foo is no longer locked
- User B has a locked, modifed, out-of-date foo.

User B cannot commit the locked, modified foo as it is out-of-date.
Isn't that the very thing locks are supposed to avoid?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org