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.
Regards,
//Peter
---------------------------------------------------------------------
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