Custom Configuration of Sets of Repositories in .hgrc

This page summarizes a lengthy discussion on the developer mailing list. It originated with [http://www.selenic.com/mercurial/bts/issue918 issue 918: Option to copy some of .hg/hgrc upon local clone].

What's the idea?

One often has several local clones of the same project. Sometimes these clones all require the same extra configuration in their local .hg/hgrc files ([email] to=mercurial-devel@selenic.com for all clones of hg, for instance). It's easy to forget adding that when creating a new clone. The idea now is to:

• Do this extra configuration in such a way that new clones are automatically configured correctly.

Obviously, this defines a notion of sets of clones where such extra configuration should apply, as opposed to others where it does not.

Key issues:

• By what grouping mechanism can we define the sets of clones?
• How are new local and remote clones added to existing sets?
• Where do we define the sets we want to add extra configuration for?
• Where do we put the extra configuration?

• Can we update the extra configuration centrally (like ~/.hgrc)?

• Must be secure.

• Don't conflict with managing ~ using hg.

• Can read config before touching repo (see http://www.selenic.com/pipermail/mercurial-devel/2008-January/004291.html).

Recap Of Discussion Up To Jan 15, 2008

Copy elements from .hg/hgrc on local clone

This was the initial proposal. A repo's .hg/hgrc would contain instructions as to which of its elements to copy over when cloned locally. See [http://www.selenic.com/mercurial/bts/issue918 issue 918] for details.

This proposal stands apart from the others:

• The local clone operation groups the source and target repos into a set for the duration of the clone only. New remote clones are never automatically added to a set, and thus never auto-configured.

• The extra configuration is kept where it usually is, in .hg/hgrc, which is augmented by copy-on-clone directives.

• We cannot update extra configuration centrally as its replicated in all of the clones.

Grouping Mechanisms

We discussed two approaches which both apply extra config to qualifying repositories dynamically. They differ in the selector by which repos are included in a set (grouped):

• Based on directory hierarchy. Assumption is that people will usually keep multiple local clones of the same project as children of a common parent directory.

• Based on hg id -r0, that is, the hash of revision 0. Assumption is that this neatly identifies separate projects. While nifty, this [http://www.selenic.com/pipermail/mercurial-devel/2008-January/004308.html will not always work].

Definition Of Sets

We discussed:

• Indicator-files in parent dirs of repos. For example, /sources/hg/.hgrc-ref-python would make all repos under /sources/hg/ members of the set python.

• Rev0 hashes used directly as set names. For example, [email@b626de8b95d1].

• Path prefixes or patterns used directly as set names. For example, [email@/sources/hg/**].

• Explicit configuration in ~/.hgrc. For example:

[sets]
hg = ~/dev/hg/
afc = ~/dev/afc/, /public/repos/afc/ # multiple selectors
nb = glob:/sources/netbeans/*
jdk = re:.*/jdk/.*
jcite = rev0:b626de8b95d1

Note that in the last example, there is no need to support all the listed selector options. And I didn't list the other explicit definition syntax proposals here because this one seems least likely to cause problems with special characters like : in selectors.

Configuration Location

We discussed these approaches for where to keep the extra config:

• In ~/.hgrc within tagged sections like [defaults@specific-set]:

[defaults@nb]
log = -M

[email@hg]
to = mercurial-devel@selenic.com

• In ~/.hgrc-specific-set, which looks exactly like ~/.hgrc.

• In an arbitrary file with the .hgrc format, configured per set in ~/.hgrc. This would even allow to use multiple extra config files per set to configure different aspects. Example (from ~/.hgrc):

[set-configs]
hg = ~/.hgrc-hg, ~/.hgrc-python
afc = ~/.hgrc-java
jcite = ~/.hgrc-java, ~/.hgrc-sourceforge

• In .hgrc files in parent dirs of a given repo. We dropped this approach because it is [http://www.selenic.com/pipermail/mercurial-devel/2008-January/004234.html not secure].

What Now?

I, Peter Arrenbrecht, favor a first implementation using just:

[sets]
hg = ~/dev/hg/ # path prefix as default and only option for selecting repos
afc = ~/dev/afc/, /public/repos/afc/ # multiple selectors allowed

[set-configs]
hg = ~/.hgrc-hg, ~/.hgrc-python
afc = ~/.hgrc-java
jcite = ~/.hgrc-java, ~/.hgrc-sourceforge

I think Jesse Glick favors the variants using [section@set-name] in ~/.hgrc, but I guess he could accept the above [set] element.

Maxim Dounin thinks introducing sets and section suffixes is overkill, and still suggests much more simple syntax:

[include]
/path/prefix = /path/to/included/config

Where Matt stand now, I have no idea.

Note that my and Jesse's favorites could coexist, but I think that would be overkill for a feature that will likely not see that much use in practice.

Comments

Paul Crowley said (on IRC):

• if there were some sort of "source" directive for hgrc files then that would fix a disadvantage of "copy hgrc on local clone" - the "source" directive would also be copied

Peter Arrenbrecht said (on IRC):

• I also had an idea on how to fix Jesse's rev0 idea. We could add an explicit, versioned .hgidentity file. Then projects could identify themselves.

Marcin Kasperski said (shamelessly writing inside this page):

• What is wrong with the idea of handling .hgrc file INSIDE the repository in addendum to the .hg/hgrc? Such file would be normally versioned, cloned everywhere - whether locally, or remotely, and would be perfect for all sticky settings except those personal... And one could make it so .hg/hgrc overwrites this when necessary....

  • This would basically introduce same security issues as looking for .hgrc in parent directories. Additionally, this wouldn't solve original Jesse's use case - he want to use other user name for set of repos. -- MaximDounin

    • Every solution which works only locally seems to be only improving confusion, I get used to have clones copying setting, then suddenly when I clone to test machine or so, everything is lost. -- MarcinKasperski

      Regarding security -- I feel that the problem is somewhat mitigated when we talk about the file which belongs to the cloned repo, but ... it exists. And there are two possible approaches. Either catalog "safe" settings and allow only for them (so, for example, allow to enable some extension, but do not allow to set its path), ignoring the rest, or require review on every change (I imagine solution in which after pulling changes to .hgrc mercurial would require the user to accept or reject them via some dedicated command, accepted changes could be moved to .hg/hgrc). -- MarcinKasperski

  Revisiting the above: maybe the crucial idea would be to "offer" the hgrc changes to be accepted (and many sources may be used, even both in-repo .hgrc and parent dir and sth else) and save those accepted to .hg/hgrc (using normal merging algorithm). This way the user would review changes and could even patch them appropriately (say, changing the extension path) -- MarcinKasperski

CategoryNewFeatures