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.

Where Maxim and 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.

CategoryNewFeatures