Shawn Harrison wrote:
> I am a user who has been following this thread with interest. I
> implemented an advisory locking add-in for Microsoft Word, because we
> need some kind of locking mechanism to edit binary files. I've had six
> months of experience with "some kind of" locking mechanism with
> Subversion, in actual use. So, here's a user's perspective.
>
>>
>> Subject: User interface survey (command line)
>>
>> You have following working copy and you are about committing it:
>>
>> foo/
>> first_file.txt #locked, and modified
>> second_file.txt #locked, and unmodified
>>
>> svn commit ./foo
>>
>>
>> After that, what do you expect that will happen:
Well, that depends on why I am committing after only changing one of the files.
If I have decided that the changes are complete, and the second file happened
to need no change, then I expect (or want) one behaviour; if I am making a
partial commit and then will want to continue working on the files, then I
expect (or want) the other behaviour.
Note that if I had finished working on the first file and wanted to commit it
by itself, then this scenario would be inappropriate: I would expect to have to
use a commit command that identified that file by itself. I would have to do
so if I had already started to modify the second file, and so it would be
logical to do so even if I had not already started to modify the second file.
>> a) first_file.txt will been shown on the modified file list (on your
>> commit log editor), and it is still locked after the commit.
>
> This is what I would expect, that locking and committing are two
> different activities. I often commit partway through a lock, and I don't
> expect that I've lost my exclusive hold until I say so. "Commit" doesn't
> mean "check-in", just as "update" doesn't mean "check-out". This isn't a
> library, with only one copy of the file. This is a working copy of the
> repository.
What a word or a command means to you depends on how you have been taught. If
you had read the Subversion documentation in a certain frame of mind (I'm not
sying you haven't read it) then you would recognise "commit" and "ci" (short
for "check-in") as synonyms within the context of a Subversion that has no locking.
When we introduce a new feature like locking, we have to re-evaluate our
concepts and how they map to command names. Should we now say that "commit"
and "ci" are no longer strictly synonyms when locks are involved? Perhaps they
should have different defaults with respect to locks? Perhaps they should have
different actions with respect to locks, and no flags to alter that: they would
become separate commands. This would still be backward-compatible becaus they
would still behave the same as each other (and as they always did) in the
absence of locks.
[snip: locks help to avoid simultaneous changes to an unmergeable file]
> Leaving
> the locks in place is insurance against this kind of mess. Removing them
> by default potentially undermines the reason for implementing them in
> the first place.
Well, this idea of having a single "default" is a bit hairy. There are clearly
use cases where "commit and unlock" is most appropriate, and other use cases
where "commit and don't touch locks" is most appropriate. If we pick either of
those to be the default meaning of both "svn commit" and "svn checkin", then
> You could add something to the commit output to remind the user that the
> lock is still being held.
That is a potentially very good idea that I haven't heard or thought of.
>> b) first_file.txt will been shown on the modified file list (on your
>> commit log editor), and it is unlocked after the commit
>> (second_file.txt will be still locked).
>
> This is acceptable as long as I am notified that this has happened. But
> I would probably set my auto prop to no_unlock anyway.
(I don't know what "auto prop" you think you might be able to set.)
>> c) first_file.txt and second_file.txt have been shown on the
>> modified file list, and both of them have been unlocked after
>> the commit (even when content of second_file.txt was unmodified).
>
> This is pernicious, and it is Microsoftesque: The program is telling me
> it knows better than I do what I intend. If I locked a file and didn't
> work on it, it means I still want it locked. What a pain to lock a bunch
> of files, work on one, commit it, and have all my locks undone by
> so-called smart software.
Whoa! Hold on. No, no, no. It's just a matter of what concept we attach to
the command. Let's say you use the command "ci" (check-in) instead of
"commit". Does that make sense then? You are asking Subversion to check in
(commit and unlock) these two files. It does so. No problem. The only
problem is if you don't like using the command named "commit" to perform a
check-in.
(I am using your terminology here, not saying that Subversion should
necessarily adopt this terminology distinction, though perhaps it should.)
> If someone on the team _is_ stupid and gratuitously locks stuff he's not
> working on, then this is a human problem with a human solution:
> training, public shamings, reprisals, whatever.
Agreed.
> I don't like to have the
> software implement policy, because that is a passive-aggressive approach
> to life, and I've had enough of that from sysadmins for two lifetimes.
I suppose you mean that if the plain "svn commit" or "svn ci" command unlocks
files, then it's setting (or at least encouraging) a policy of not holding a
lock throughout a series of commits. It's not enforcing that policy, because
you can add "--no-unlock".
I suppose that someone who customarily hold a lock through a series of commits
will not be happy if the plain "commit" command (without a switch) unlocks files.
> As a project administrator, I often put locks on files that I don't want
> people to edit, even if I'm not actively working on it. I want to lock
> it and leave it, knowing that it will be preserved in that state until
> I'm ready for it.
That sounds like a bit of a crude way of implementing access control. You are
free to do that if it works for you, but I don't think that this discussion
should by influenced by a desire to facilitate that usage.
>> d) Something else, please tell us what?
>
> You could implement a new svn client command to do "commit and unlock".
> E.g., "svn cu target". Then you can easily get result (c) when you
> actually want it. If the file isn't locked, no harm done -- just as when
> you do "svn ci target" and target has not changed.
Yes, a command to do that is very much wanted I think. What that command
should be is a big question. ("checkin" ... except for the confusion with "ci"
being a synonym for "commit")
> One thing that I haven't seen discussed (I might have missed this) is
> what happens when a locally modified file is unlocked: If there are
> local changes, it would seem that the file should be committed before it
> is unlocked.
Why? Or do you mean "should be committed or reverted"?
> So in that case I would expect "svn unlock target" to fail
> with a warning, unless I use --force.
>
> Individual files and folders could have a svn:property that overrides
> the default behavior.
In what way? Basically, yuck! unless there is a very strong reason for this.
> Another thing that I love about Subversion is that it is extremely
> well-designed. So I realize that you guys really don't need my input.
> But I appreciate the opportunity to offer it.
Your input is valuable when we have difficult decisions to make and you have
real-world experience. Even though I have argued against most of what you
wrote, it brings up useful new points and ideas and makes the whole discussion
better.
- Julian
>
> Shawn Harrison
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 02:28:21 2004