Mercurial in a corporate environment (migration from CVS)

[Martin Geisler]

Dennis Brakhane <brakhane at googlemail.com> writes:

> Am 12.01.2012 10:37, schrieb Martin Geisler:
>> Dave Brosius <dbrosius at mebigfatguy.com> writes:
>>
>>> We have hooks to make sure the pusher is the same user as one of the
>>> pushed changesets commit user. Then a hook to make sure the pusher
>>> is a domain user in apache.
>>>
>>> This seems to do pretty much what is desired, right?
>> Yes, you're right, this might be what is desired. I went to Stack
>> Overflow and updated my answer there and included a section about
>> making the server reject pushes.
>>
>> The important thing to remember is that this *limits* collaboration:
>> it is no longer possible for Alice to push a changeset created by
>> Bob. It might be okay if this never happens in your organization, but
>> it's probably because centralized systems never allowed this before.
>
> I think the crucial part is "*one* of the pushed changesets commit
> user", as I understand it, the hook will only prevent a push if none
> of the commits was made by the one who pushed, which seems like a
> reasonable compromise.

Yeah, that's a great way to relax the requirements.

> But if Stephen only wants to ensure that people did not misconfigure
> their hg, why not create a hook that checks every author of every
> changeset to be push against a whitelist. This way, everyone can push
> changes of fellow developers, but the commit authors are reasonable
> correct.

That sounds like a good strategy to me. If maintaining a whitelist is
cumbersome, the hook could simply match the committer name against a
regexp like

  ^.+ .+ <[a-z]+ at company.com>$

to ensure that there is at least two parts to the name (first and
surname) and an email address at the right company.


The last thing I'll like to point out about such hooks is that it's
*difficult* for people to correct any mistakes when 'hg push' is
rejected. I think it's more difficult to fix a bad username in four
outgoing changesets than it is to set the username in the first place.

That's the downside to hooks that reject commits: you need to educate
people about how they can recover when the hook kicks in.

I've deployed similar hooks that checked that nobody made bad tags.
There I was careful to make sure that I only checked the tip of the
pushed changesets for problems: this allows people to fix a rejection by
creating a *new* changeset. We felt it would be too much if we required
people to fix the mistake by rewriting the history.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/