All,
Right now our post-commit e-mails and other notifications do not occur when a file is locked or unlocked[0]. There are two options. The first is duplicate our existing post-commit hooks for the pre-lock and pre-unlock hooks. The alternative is to disable locking entirely. We don't really use them (often) and there's no active locks, so I'm inclined to want to do the latter. Feedback is desired though.
Thanks,
Chad
On Mon, May 3, 2010 at 5:24 AM, Chad innocentkiller@gmail.com wrote:
All,
Right now our post-commit e-mails and other notifications do not occur when a file is locked or unlocked[0]. There are two options. The first is duplicate our existing post-commit hooks for the pre-lock and pre-unlock hooks. The alternative is to disable locking entirely. We don't really use them (often) and there's no active locks, so I'm inclined to want to do the latter. Feedback is desired though.
Thanks,
Chad
I meant the post-lock and post-unlock hooks, obviously.
-Chad
On Mon, May 3, 2010 at 2:39 PM, church.of.emacs.ml church.of.emacs.ml@googlemail.com wrote:
We don't really use them (often) and there's no active locks, so I'm inclined to want to do the latter.
Killing locks entirely sounds reasonable if we don't use them and don't plan to use them anytime soon[1].
Regards, CoE
[1] i.e. before we move to git :P
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I went ahead and disabled them a few hours ago. Shouldn't be able to do svn lock anymore.
-Chad
Chad wrote:
All,
Right now our post-commit e-mails and other notifications do not occur when a file is locked or unlocked[0]. There are two options. The first is duplicate our existing post-commit hooks for the pre-lock and pre-unlock hooks. The alternative is to disable locking entirely. We don't really use them (often) and there's no active locks, so I'm inclined to want to do the latter. Feedback is desired though.
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.
-- Tim Starling
On Mon, May 3, 2010 at 6:30 PM, Tim Starling tstarling@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.
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?
Aryeh Gregor wrote:
On Mon, May 3, 2010 at 6:30 PM, Tim Starling tstarling@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
wikitech-l@lists.wikimedia.org