Jani Averbach wrote:
> Or what about if we use our svn-users list and ask there?
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:
>
> 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.
Bear in mind: With binary files, the consequences of editing without a
lock are potentially more costly than the consequences of holding a lock
that is no longer in use and thus locking someone out. Waiting a week to
work on a file is less trouble than merging changes from two different
Word documents. And with Word, merging is relatively straightforward,
because there is a reliable diff2 mechanism (Word's "merge" function, on
the other hand, is horribly broken: let the buyer beware): Give a typist
the two diffs and training him/her to merge them with tags showing who
did what. Then the editor reads through and decides. Okay. It's a lot
easier to wait a week. And I can't imagine what would be required to
merge changes to two different Adobe Illustrator file versions. 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.
My implementation of advisory locking works this way, and in that case
each lock/unlock is committed as a revision, because it involves
creating/deleting a file. With locking as an unversioned property, it
makes even more sense to do it this way, because committing doesn't have
anything to do with locking.
You could add something to the commit output to remind the user that the
lock is still being held.
>
> 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.
>
> 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.
A plea: One of the things that I love about Subversion is that it treats
me like I know what I'm doing.
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. 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.
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.
>
> 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.
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. 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.
--
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.
Shawn Harrison
Senior Editor
Tyndale House Publishers
________________
harrison@tbc.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 00:53:05 2004