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