Re: Locking UI comments

On Wed, Oct 13, 2004 at 08:48:52AM -0700, Justin Erenkrantz wrote:
> On Wed, Oct 13, 2004 at 11:43:43AM -0400, Ben Collins-Sussman wrote:
> > Aha, this is a different strategy. Rather than make 'svn lock' do an
> > automatic update, you're suggesting that it *require* that an update
> > happen first? I like it!
>
> To be pedantic, there's a race condition between an update and then a lock.
> This is why WebDAV clients usually LOCK then GET. But, it'd most likely be
> small enough for our command-line client to require this behavior. -- justin
>

I think it should be atomic, in the following way:

Client -> Server

LOCK /foo.c @ r1234

Server -> Client

one of:

1.) SUCCESS: TOKEN is xxxx

2.) ERR: RESOURCE ALREADY LOCKED

3.) ERR: REQUEST OUT OF DATE

r1234 need not be HEAD, it just must be the youngest
revision of /foo.c. The server must provide the necessary serialization
to make sure that, server side, the check for up-to-dateness doesn't
race against the lock acquisition.

For locking directories, a WC reporter would be required, due to the
possibility of mixed-rev WCs under the directory being locked.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 19:23:28 2004