On Tue, Dec 14, 2004 at 10:56:20PM +0000, Julian Foad wrote:
> Ben Collins-Sussman wrote:
> > On Dec 14, 2004, at 12:11 PM, Peter N. Lundblad wrote:
> >> IN any case there is the question if only the committables (the files that
> >> were actually changed) or all files specified by the targets (and possibly
> >> recursively) should be unlocked. I think the latter is the best. If you
> >> commit a subtree with some locked files, a lock shouldn't be left just
> >> becvause the file wasn't modified.
> >
> > I disagree about this. People often have multiple changesets going on
> > in their working copies. For example, I may lock foo/bar/baz.jpg
> > because I plan to edit it as part of Changeset A. Then I might switch
> > gears and change a bunch of other files in foo/bar/, as part of
> > Changeset B. Then I run 'svn commit foo/bar/' to commit Changeset B. I
> > would be really annoyed if that released my lock on baz.jpg!
>
> What? While I can see that you might find that a convenient way to work if
> 'commit' behaves the way you imply it should, I don't see that as an argument
> for 'commit' to behave that way.
>
> A contrasting scenario: Instead of "I may lock
> foo/bar/baz.jpg [for] Changeset A", let's say "I may
> _modify_ foo/bar/baz.jpg as part of Changeset A", and
> proceed as before. Then I am aware that I can't check in
> Changeset B by running 'svn commit foo/bar/'. Why would
> you find that restriction annoying in your scenario?
> Surely you would understand that a recursive command won't
> selectively ignore some of the given tree, and would
> instead use a more appropriate command?
Am I the only one that finds this unpersuasive? Isn't this
reasoning saying, 'Since it is sometimes tedious to checkin,
it should be tedious always?'
Perhaps I have a difference viewpoint because I work in an
environment where locking is enforced. Developers have
non-trivial work to do on multiple files, and typically the
scope of work is known ahead of time (eg, 15 files +/- will
need to be changed by one developer over the course of days
or even weeks), but not committed all at once. The files are
locked by the developer when we starts; the work
proceeds by degrees, with changes committed periodically
(files are left locked); and then finally, when the whole
'chunk' of work is done, the files are all unlocked. This
may not be the use case in front of the Subversion
development team daily, but it is out there.
Here is how I envision the two options functioning in our
typical development scenario at work. This disregards
command-line switches or user configuration to supersede
default operation; the concern is strictly with 'what makes
sense for a default'.
Option A: unlock on checkin:
1. Work sequence
svn lock file1 ... file15
<edit some>
svn ci file1 file2 file3
svn lock file1 file2 file3
<edit some>
svn ci file2 file4 file6 file8 file10
svn lock file2 file4 file6 file8 file10
<edit some>
svn ci file3 file5 file6 file8
svn lock file3 file5 file6 file8
...
svn unlock
2. Note that 'svn ci' is never applicable, because it will
clear the locks, necessitating another long unlock
command. Also note that the locks are released for a
moment after every checkin.
Option B: no unlock on checkin
1. Work sequence
svn lock file1 ... file15
<edit some>
svn ci
<edit some>
svn ci
<edit some>
svn ci [occasionally file list may be needed]
...
svn unlock
2. There is a reason 'svn ci' and friends are recursive by
default: it makes things easier for the user. Clearly,
not auto-locking on checkin is the only way to retain
this benefit in this use-case.
Granted, there are use cases wherein it would be nice to
clear all the locks upon commit. But if that doesn't happen,
the remedy is simple: just an extra 'svn unlock'. Compare
that to the nuisance auto-clearing of locks inflicts on the
use case I've described above, and the choice is clear.
Furthermore, the defaults in Subversion have always tended
on the side of safety. While there is, strictly speaking, no
safety issue here (the local working copy is not lost), the
consequences of forgetting a '--no-unlock' switch are
potentially more serious than those of forgetting a
'--release-locks' switch in terms of trying to reconcile
concurrent updates.
I truly believe that Ben's original line of reasoning was,
and continues to be, both valid and persuasive: locking and
committing are orthogonal operations. Checking in a file
does not imply that you want to unlock it; frequently it is
not the case.
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 07:40:50 2004