Ben Collins-Sussman wrote:
>
> 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.
Both perspectives are reasonable;
I personally would prefer unlocking unmodified files.
Scenario:
I want to work on diagram image files in a folder
documentation/diagrams/*.gif
Since I don't know which files I'm going to modify,
I lock all these files.
But then, when working on the documentation,
I only have to modify some of them.
At the end, I svn commit documentation/diagrams.
Not unlocking all files in this directory would make
it likely that these locks accidently remain "forever".
I would say that locking means telling other users
"I'm planning to modifiy these unmergable files.
Please don't modify them in parallel.",
but locking is no "promise" of modifying these file.
What is the practical advantage of not unlocking unmodified files?
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 02:55:20 2004