Aryeh Gregor wrote:
On Mon, May 3, 2010 at 6:30 PM, Tim Starling
<tstarling(a)wikimedia.org> wrote:
I've used locks quite a few times,
they're quite useful when you're
doing major work on a file and you know half a dozen people are trying
to fix your spacing at the same time. I don't think they should be
disabled.
You can only discover that there's a lock on the file when you
actually commit, though, right? So instead of you having to merge
some conflicts when you commit, their commit fails and they have to
save their patch somewhere and merge their changes with yours later.
That doesn't seem like a big improvement overall -- it's more
convenient for you and less convenient for them. Particularly if they
forget to commit again later, or don't bother saving their changes
anywhere.
The situation would be greatly improved if Chad added a pre-lock hook
which sent a message to IRC.
If you really want this effect, though, couldn't
you just resolve the
conflict by overwriting their commit? I mean, when you get the merge
conflict, just resolve it completely in favor of you, and say in the
commit message that they should recommit their changes. This will
only work if there are no interactions with other files, but really,
how often does this happen? Do you habitually keep changes in your
local copy for days at a time or something?
Yes it's really what I want, and no it wouldn't be better. The
scenario you're talking about, where if someone gets a lock message,
they give up, make a patch and then forget about the patch, is totally
unrealistic. They just have to wait for a bit, update and try again.
The situations I've used it are the exact opposite of keeping changes
in my local copy for days at a time. I used it so that I could commit
intermediate copies of my work, at a stage before it is ready for
other people to start working on it, instead of working in private.
The best example was with SecurePoll, when intermediate commits
attracted hoardes of developers trying to remove all the line-ending
spaces.
I've also used it for file rewrites in certain cases. I know from
experience that when you tell certain developers "I am rewriting your
file, please do not touch it until I next commit," they go ahead and
do a little refactoring anyway. A lock in this case serves as an extra
little reminder that I meant what I said.
I don't use it very often, but it seems kind of silly to disable a
useful feature just because it's rarely used. As far as I know, I'm
the only MediaWiki developer who uses it. But I think more people
would use it if they had read the section on it in the manual, and
knew how useful it can be.
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
-- Tim Starling