Re: Locking UI comments

--On Friday, October 15, 2004 12:53 AM +0200 "Branko ?ibej" <brane@xbc.nu>
wrote:

Of your proposed examples, I find one that I disagree with:

> * "svn commit" also accepts --lock, meaning "commit but keep the
> lock". By default, "svn commit" releases all locks.

I honestly am not convinced that the command-line interface should respect
that default. It's not at all what I'd expect: my expectation is that a
resource that is locked may undergo multiple commits as I checkpoint progress
towards the resolution of the issue that caused me to lock the file in the
first place. I don't know if this is open enough to introduce a config
argument to change the 'default' behavior. A GUI allows for a checkbox, but
our command-line interface doesn't.

> The open question is whether "svn lock --update" should mean the same as
> "svn upate -rHEAD --lock"

I don't think we're planning on introducing a revision aspect to the locking.
I could be wrong though. It has been discussed though, and I'm vague about
the concept of how out-of-dateness will be enforced unless we go with Greg
Hudson's suggestion of requesting the lock unconditionally (error out if
someone has it), then running the update. If it turns out that we're out of
date, immediately release the lock and error out to the user. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 06:55:42 2004