Mercurial in a corporate environment (migration from CVS)

[Martin Geisler]

Dave Brosius <dbrosius at mebigfatguy.com> writes:

> On 01/12/2012 01:27 AM, Martin Geisler wrote:
>> Stephen Rasku<mercurial at srasku.net>  writes:
>>
>>>>     - Is there a way to force the user specified in the log to be
>>>>     the Apache/SSH authenticated username, not just whatever the
>>>>     user has put in his/her ~/.hgrc file?
>> That's not possible by design:
>> http://stackoverflow.com/a/8805620/110204 The crucial reason is that
>> changesets are created locally and pushed later. You *cannot* change
>> anything in a changeset at that point without also changing the
>> changeset ID.
>
> Hmm.
>
> 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.

My experience is that hooks tend to create unnecessary constraints. If
you make a server-wide hook that prevents me from pushing a changeset
with your name in it, then what happens if I make

  1. Make a feature branch repository on the server

  2. Work there for a while

  3. Pulls from the main repo where Alice has pushed her changesets

  4. Merges and pushes that to my feature branch

The hook might now reject my push into my feature branch for no good
reason.

-- 
Martin Geisler

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