On Tuesday 14 December 2004 18:40, Julian Foad wrote:
> John Szakmeister wrote:
> > Ben Collins-Sussman wrote:
> >>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!
> >
> > I agree with you Ben. I often have several changes running through
> > my working copy.
>
> See my reply to Ben: how do you justify wanting any locks on unchanged
> sibling files to be left alone while, already, any changes to sibling
> files get committed?
IMHO, if the file isn't modified (whether it has a lock or not), it
shouldn't be committed. Hence, the lock should remain. It was that
simple.
I can see arguments the other direction too though, especially in the case
of the clumsy user who locks a bunch of stuff, edits the one file that
was important, and then commits. Hmph. I suppose that now that I think
about it, Julian and Peter have a point. I can definitely see if we
didn't release the locks, that people would end up stealing them on a
regular basis. I see another use case in favor of this too. Mainly, I
want to ensure that some related files don't get changed while I modify
one of the files in the group (this would be handy for me today if I
could do it).
I withdraw my objection. We should definitely release the locks. It
seems more intuitive for the users. While I may not consider having a
lock to be justification enough to consider it part of the commit and
release it, I can see many users thinking it is.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 12:12:44 2004