[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking UI comments

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-10-19 00:37:48 CEST

Justin Erenkrantz wrote:

> --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.

If the environment is such that you expect people to stand in line
waiting to pounce on your file as soon as you (accidentally) unlock it,
then IMHO there's something wrong with the team. :-)

Really, I don't see this as a problem. You can still tell "svn ci" to
keep the lock, and I think this kind of checkpointing will be the less
common case.

[OT: It's also solved by two-stage commits, where you checkpoint to the
working copy/local repos...]

> 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.

Yes, I expect it would be a bit too complicated to change that and
people would tend to forget about such a config option and leave lock
lying around. We could have a config option (off by default) telling the
client to prompt for confirmation about releasing locks on "svn ci".

>> 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.

No no, I just wanted to stress that with "svn up", combining "--lock"
with any "-r" other than "-rHEAD" is invalid.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 19 00:37:56 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.