[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Locking] commit and unlock

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-15 01:27:17 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.