Per project config options

[Michael Diamond]

On Wed, Apr 25, 2012 at 2:38 PM, Steve Hoelzer <shoelzer at gmail.com> wrote:

> 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
>

The general use case for not needing security goes something like this: "My
project doesn't need to worry about Mercurial security concerns, because {I
trust my developers | it's totally internal | I'm the only person using it
| it's not a standard source code repository}."  There's two issues with
this, most notably, all of those factors can change, and when they do it's
highly likely repository configuration security is not going to be a top
concern.  Secondly, such use cases are far from the norm, and far more
often people *think* security isn't a concern for their repository, but are
mistaken.  These two factors all but guarantee (in my mind) that this will
never be an option in core Mercurial.  I'm not saying your in that second
category, just that if you are in fact safe from security concerns, that's
far from the norm.

The consequence of these two factors is that no matter what, you will have
to do a second step after hg clone to apply new configuration files, be
that enable an extension (or have it enabled for the user already) or run
some sort of script.  Matt pointed out some of the issues of your solution
#1, and #2 would require a hook or extension of some sort, and to me seems
like a very rough and unintuitive behavior.

I think your best bet is the extension Angel suggested, or if that's too
much for what you need, track a .hgrc file, and expect users to run `echo
"\n\n%include = ../.hgrc" >> .hg/hgrc` or drop that into a bash script like
'update_hgrc.sh', then you can quite easily do (or instruct users to do):

hg clone http://example.com/hg/myproject
cd myproject
./update_hgrc.sh

And you're golden.  Doesn't seem like too much work to me, and has the
added advantage of ensuring that anyone using the repo must knowingly apply
the changes to their hgrc file.

Another factor to remember is that one (highly intentional) "limitation" of
distributed VCS is that you can't enforce any sort of settings, hooks, or
extensions on other people's repositories, and you should never trust new
changes to have been created with your configurations in place.  The only
guarantee you have is that they cannot change the history without you
knowing.  If you need additional control, you do this by designating a
centralized repository people push/pull to, and locking down access to that
repository, and/or applying push restrictions via a server-side hook.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120425/dd95c168/attachment-0002.html>