On Dec 14, 2004, at 5:40 PM, 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?
>
The justification for my opinion is that I consider "locking" and
"changing" files to be independent actions. They aren't related to
each other; they live in different dimensions.
- a file can be changed, but not locked.
- a file can be locked, but not changed.
- a changed file can be committed, but the lock can remain.
- a file can be unlocked, but still have local changes.
In my world, the "commit" command finds all changed files, and commits
them. A locked file doesn't qualify as a "changed" file in and of
itself. That simple.
This logic is consistent, I think, with everyone's objection to the
idea of blurring the line between "svn lock" and "svn update" command.
We deliberately separated them: locking doesn't cause an update. Nor
does unlocking cause a commit. Once again, the idea here is that a
file lock/unlock state has nothing do with pushing or pulling data.
In a perfect world, I think neither 'svn up' nor 'svn commit' should
affect lock states at all. But I can understand adding a *convenience*
switch so that things which are committed automatically get unlocked.
(Just like cmpilato and I would like to see a convenience switch that
causes 'svn lock' to automatically update something.)
But unlocking things that were never committed? That's just completely
blurring concepts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 01:28:36 2004