Per project config options

[Michael Diamond]

Meant to send to list...

On Apr 25, 2012 9: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.
>
> Michael Diamond
> dimo414 at gmail.com
>
> Sent from my phone - please excuse the brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120425/a7605fae/attachment-0002.html>