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

Re: [locking] out-of-dateness checking during lock

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-04 17:14:20 CET

On Dec 4, 2004, at 9:09 AM, Greg Hudson wrote:

> On Sat, 2004-12-04 at 08:28, Peter N. Lundblad wrote:
>> The current RA API lock function doesn't allow the client to provide a
>> revision number. We can ask the server for last committed revision of
>> the
>> path, but that wouldn't atomic. Maybe someone has a plan for how to
>> deal
>> with this. sussman? fitz?
>
> Get the lock.
>
> Then check and make sure you have the most recent version.
>
> If you don't, error out and release the lock.
>
>

Aha, yes, this technique prevents a nasty race condition within the
'svn lock' command.

    "I have revision N of the file, is that the latest?" --> "yes."
    (in a split-second, somebody commits new version of file)
    "Okay, lock the file." --> "locked."

I have two concerns here:

   * I'd rather not see every RA->lock() implementation have to
duplicate this logic. Peter, can you put it into svn_client_lock()
instead, so it's shareable?

   * I'm worried that if an admin has post-lock and post-unlock hook
scripts, there's going to be 2 useless emails generated whenever
somebody even *attempts* to lock an out-of-date wc file.

I'd like to point out that another solution to this problem is to

      - get the lock
      - check for out-of-dateness
      - if out-of-date, update the file.

I know that the idea of 'svn lock' automatically doing updates was shot
down weeks ago, with people screaming about how bad it is to mix
subcommand concepts together. But now it seems the only alternative is
to make the 'svn lock' command behave a bit schitzo: "lock the file...
oh wait, nevermind, unlock it!" Is that behavior the lesser of two
evils?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 4 17:16:42 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.