[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: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2004-11-05 20:14:10 CET

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.


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

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.