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?
> My feeling is: 'svn commit' should only change the things it
> committed. That's how it works now, and it seems pretty simple and
> clear. If 'svn commit' started removing locks just because they're
> "nearby" things that were committed, we'd be violating the rule.
It depends on what we feel we mean by "changing" a thing, and what we mean by
"the things it committed". I know what they mean in Subversion without
locking, but we could adjust our concepts so that we don't feel that unlocking
a file is changing it, and/or so that we do feel that an item which was locked
but not changed is still logically part of the commit for the purposes of such
discussions.
There is certainly merit in your argument, but I don't think your previous
paragraph is any support for it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 14 23:57:47 2004