On Tue, Oct 12, 2004 at 11:29:54PM -0700, Justin Erenkrantz wrote:
>
> Issue #5: Should 'svn commit' release a lock?
>
> I don't think so. I think that if a lock is explicitly requested, then it
> needs to (by default) be explicitly released. I'd reverse the commit
> behavior and have '--release-lock' be an option: the default should be to
> keep the lock.
>
> Here's a use case that I think is more common than not: I lock a file, I
> want to make some changes to the file. It's 5pm and I want to go home for
> the day, so I commit my changes so I can checkpoint my work (after all,
> that's the point of a SCM). By checking it in, I can let other people view
> my progress, but I still want to reflect to everyone else that I still have
> the lock on the file. (That is, if you break or steal it, be aware that I
> was doing something with it.)
>
Well, one counter argument is that many people will forget to release
their locks.
RCS's ci requires "-l" to keep the lock; i.e., releasing it is not 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.
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.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 13:55:12 2004