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!
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 14 19:28:04 2004