[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:04:20 CET

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
Received on Fri Nov 5 20:04:37 2004

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