Per project config options

[Steve Hoelzer]

On Wed, Apr 25, 2012 at 8:58 AM, Michael Diamond <dimo414 at gmail.com> wrote:
> On Apr 25, 2012 9:44 AM, "Steve Hoelzer" <shoelzer at gmail.com> wrote:
>>
>> I think it would be really useful for Mercurial to support per project
>> config options in addition to per repo and per user options. When I
>> say "per project", I mean that options would be version controlled and
>> transferred between repos on clone/push/pull operations, just like
>> hgignore rules.
>>
>> This idea came about while playing with the largefiles extension [1]
>> and considering it for my team at work. We would like everyone to use
>> standard options for `minsize` and `patterns`. Right now, the only way
>> to make that happen is for every person to manually set those options
>> (and not forget to do it, and not make a mistake). If our standard
>> changes, everyone has to manually update those options again. But if
>> these options could be set per project, just one person would make the
>> change and everyone else would get the new config when they pull.
>>
>> The obvious way to have project level config options is to track a
>> special file. For example, largefiles options could be moved to
>> `<repo>/.hglargefiles`. I bet that having per project config options
>> would be useful for more than just largefiles, though, so a general
>> purpose config file like `<repo>/.hgrc` would be better. It would be
>> just another config file where any option could be specified. The
>> order of precedence would be:
>>
>> 1. Per repo (<repo>/.hg/hgrc)
>> 2. Per project (<repo>/.hgrc)
>> 3. Per user ($HOME/.hgrc).
>>
>> I do realize that some things would not be appropriate as per project
>> options and could cause issues when transferred to a different repo. I
>> contend that this is a semi-advanced feature so the user should know
>> what they are doing. I also think that the benefits outweigh this
>> potential downside.
>>
>> What do you think?
>>
>> Thanks,
>> Steve
>>
>
> Easy solution,  which prevents malicious changes from going in undetected,
> is to track a .hgrc file in the repo root, which users can manually copy
> into .hg.
>
> Alternatively, I don't know if this is already possible, but it would be
> nice if you could include additional config files, that way you track
> $repo/.hgrc, and .hg/hgrc just has a "include=.hgrc" line. Users still have
> to manually add that line at checkout (or a build script could do it for
> you) but again, from a security standpoint that's desirable.

These are both good ideas that get me part way to what I want. I
hadn't been thinking of security implications.

By the way, including another config file is possible with:

    %include = relative/path/to/file


On Wed, Apr 25, 2012 at 9:05 AM, Angel Ezquerra
<angel.ezquerra at gmail.com> wrote:
> you should have a look at the ProjrcExtension
> (http://mercurial.selenic.com/wiki/ProjrcExtension), which comes
> bundled with TortoiseHg.

Very nice! The end result is pretty similar to my idea, but it is much
more complex. And again, it requires manual setup in the name of
security.


It seems to me that simple per project config files would be a great
feature. The problem is maintaining security. Here are a couple ideas
for potential security mechanisms:

1. Mercurial has a built-in blacklist of config options not allowed in
the per project hgrc file. Those options are ignored (and maybe alert
the user if those options exist).

2. Whenever the per project hgrc file changes, mark it as a merge
conflict and force the user to look at it.

I haven't thought about these much, so I'm sure there are flaws, but
maybe it will inspire more ideas...

Finally, what if I'm willing to forgo security? Any other options for
simple per project config?

Thanks,
Steve