[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-12-04 19:45:29 CET

On Sat, 4 Dec 2004, Philip Martin wrote:

> Greg Hudson <ghudson@MIT.EDU> writes:
> >> 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?
> >
> > Yes, by a mile.
> Why do we have to accept either option? Why not pass a revision and
> have the fs reject the request if the lock is not HEAD? We could
> make it optional to allow clients to lock HEAD unconditionally if
> wanted.
Yes, I'd to do this, too. If you get an error while unlocking,
you will be left with a lock on the server and a WC without the
token. This can be solved by breaking the lock, but I think this a
usability problem. That was what I meant by saying that the operation
wouldn't be atomic. (BTW, you only need to check that the path is at the
last committed revision or later, but that's a detail.)

This means pushing this check into the FS. I'm not sure everybody will
like that:-) This could be seen as a client asking for a lock on a
particular revision and the server only allowing locks on the last
committed revision or later.


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