Version-controlled extension configuration in Mercurial

Question

Normally, I would enable extensions by adding the following to .hg/hgrc:

[extensions]
hgext.win32text=
[encode]
** = cleverencode:
[decode]
** = cleverdecode:

However, I want this configuration to be versioned, i.e. part of the repository, so that it is enabled for anyone else (coworkers, build machines) cloning the repository. Note that whomsoever clones the repository should not be required to do anything to enable these extensions.

It appears it is not possible from the documentation, but does anyone know any neat tricks that can help me here?

Answer 1

You want mercurial to do something automatically when you clone a repo (update the hooks or config). Documentation says it is not possible and gives some very good reasons:

Hooks do not propagate

In Mercurial, hooks are not revision controlled, and do not propagate when you clone,
or pull from, a repository. The reason for this is simple: a hook is a completely    
arbitrary piece of executable code. It runs under your user identity, with your 
privilege level, on your machine. No comments

It would be extremely reckless for any distributed revision control system to 
implement revision-controlled hooks, as this would offer an easily exploitable way to 
subvert the accounts of users of the revision control system. No comments

So clearly, mercurial itself won't solve your problem. You clearly state that you want nothing but mercurial to solve your problem, so the answer is: what you are asking is not possible.

The only way to solve your problem is that all your users will have to run/install at least once a given script that perform the actions you want, something like installing the right hooks.

If you want to be clever about this:

• create a one-time script to run that will install a hook to copy the right config into the .hg or the user
• make sure that the hook, once installed, can update the script to distribute config updates to the users
• make the hook add some special marking to commit messages
• refuse on the central repository commit that do not carry the special message

A bit complicated, but that's the closest I can imagine to your requirements:

• user run a script once and they forget
• you can make sure that if the did not run it, they can not commit to your central repo