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

Re: Lock queues and avoiding races

From: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2004-10-14 20:54:45 CEST

On Wed, 2004-10-13 at 19:14, Daniel_Patterson@national.com.au wrote:
> While we're talking about locks, I just imagined this scenario:
> 1) User A locks a file and starts work (several hours worth)
> 2) User B tries to lock file 10 minutes later, only to find that it's
> already locked.
> 3) User B asks user A when they're going to be finished, user B will try
> again later.
> 4) User A tells user B that they've finished.
> 5) User B tries to lock the file, and find that user C has beaten them to
> it! User C wasn't waiting
> for the lock, but managed to slip in the window of opportunity.
> To mitigate this, could the following be implemented?
> svn lock --wait dir/file1
> where it only returns after a lock is granted. This would give us both
> non-blocking
> (which is what has been proposed so far, unless I've missed something), and
> blocking
> lock functionality.
> I'm imagining something like:
> $ svn lock --wait dir/file1
> svn: dir/file1 is already locked <by user X>. Waiting for lock.
> ....time period of time....
> svn: dir/file1 unlocked <by user X>. Other lock requests still exist.
> svn: dir/file1 locked <by user Y>
> ... some period of time....
> svn: dir/file1 unlocked <by user Y>
> svn: lock token dkfg23894 granted on dir/file1

Hmmm. I think that this is way too complex for what we're trying to do
here. No amount of technical wizardry is going to compensate for a lack
of communication within a team.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 20:55:34 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.