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

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