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

"Brian W. Fitzpatrick" <fitz@collab.net> writes:

> 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

Ben wrote

  "I don't think it should fail, just because the lock was broken
   behind its back."

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

Brian wrote

   "all locks are validated again, so [...] the commit would fail."

If svn_fs_commit_txn validates locks (which is what I expect to
happen) why does svn_fs_apply_txdelta bother? I can see that it
allows an error to be generated earlier during the commit, is that
all?

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