On Fri, 2004-11-05 at 13:04, Philip Martin wrote:
> 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
Incorrect. in svn_fs_commit_txn, all locks are validated again, so
based on this, the commit would fail.
> - User B has a locked, modifed, out-of-date foo.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 20:14:43 2004