Per project config options

[Steve Hoelzer]

On Wed, Apr 25, 2012 at 2:20 PM, Michael Diamond <dimo414 at gmail.com> wrote:
> 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.

Very good points. I think I'm convinced that security should always be
a priority. Thanks for your detailed response.

Steve