[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-11-05 20:27:35 CET

"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

Philip Martin
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:28:15 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.