[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: Sander Striker <striker_at_apache.org>
Date: 2004-10-13 14:06:06 CEST

> From: Mark Benedetto King [mailto:mbk@lowlatency.com]
> Sent: Wednesday, October 13, 2004 1:54 PM

> Well, one counter argument is that many people will forget to release
> their locks.

As long as locks are breakable/stealable, I don't really see the problem.

> RCS's ci requires "-l" to keep the lock; i.e., releasing it is not the
> default.

Is or isn't it the default?

> VSS requires a non-default checkbox. I'm not familiar with the locking
> functionality in any other SCMs, so I can't produce other examples.

>> I just don't think it's intuitive for 'svn commit' to release the lock
>> when I explicitly requested it with 'svn lock.' 'svn unlock' should
>> be the desired usage path we lead users towards. (UIs like TSVN or
>> whatnot can have a checkbox for allowing the user to release the lock
>> on commit. I'm only concerned about what our command-line GUI does.)
 
> Shifting the default between UIs is evil. It would be nice if TSVN
> users and command-line users could expect similar semantics from the
> logical operations that they perform.

Well, I disagree here. On commit TSVN is able to show unversioned
files which can be added when you 'Commit'. Showing locks and being
able to release them at that same point in the GUI seems logical.
But I digress...

Keeping the lock by default seems the best option to me. An explicit
lock is followed by an explicit unlock.

>> I suppose keeping the lock by default would be more palatable to me
>> if the commit feedback process reminded users of their open locks:
>>
>> $ svn commit -F msg foo.c
>> Sending foo.c (keeping lock)
>> Transmitting file data.
>> Committed revision 42.
>>
>> or, alternatively
>>
>> $ svn commit -F msg foo.c
>> Sending foo.c
>> Keeping lock on foo.c
>> Transmitting file data.
>> Committed revision 42.

+1 (in concept).

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 14:06: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.