[PATCH] Check for .hgrc files in ancestor directories above the repository

[Peter Arrenbrecht]

Jesse, I think I found a problem with your rev0 approach. Consider
someone or an organization that starts new projects by cloning a
central template repo (which, for example, includes predefined build
scripts, documentation structure, etc.). These would then all have the
same rev0 despite being different projects.
-peo

On Jan 13, 2008 9:08 PM, Jesse Glick <jesse.glick at sun.com> wrote:
> Matt Mackall wrote:
> > there's a much bigger problem with this approach: we've just spent a
> > lot of work making hgrc files get read before we actually open a
> > repository. This lets us localize extensions to particular
> > repositories, etc.
>
> I see. Too bad, unless you would find the following algorithm acceptable
> (patch on request):
>
> 1. If no *@* sections, exit.
>
> 2. If .hg/identity exists, try to read it and if matches a *@* section,
> apply. Whether it matches or not, exit. If read fails, continue silently.
>
> 3. Open changelog index, read 0-rev hash, close. If any I/O error, warn
> and exit.
>
> 4. If matches a *@* section, apply.
>
> 5. Try to write .hg/identity~ and rename to .hg/identity (i.e. atomic
> operation). If I/O error, ignore silently.
>
> I don't think any extensions would have anything to influence in step
> #3, nothing would happen unless you actually used clone defaults, and
> the cost of the extra open would happen only once per clone unless it is
> not writable. That cost on my laptop is around 30 msec on a "cold"
> repository down to as little as 3 msec on a "warm" repository, for
>
>   hex(changelog.changelog(self.sopener).node(0))
>
> (It would of course be much less if you waited until self.changelog was
> loaded anyway, but that would be too late to load extensions, and might
> be too late for some other configuration to take effect.)
>
> > The .hgrc in parent directories thing was much more elegant
>
> You think so? I find it more natural to configure the behavior of clones
> wherever they may be located. But I would not be opposed to a simple
> include mechanism either.
>
> > I wasn't particularly convinced by the arguments against it.
>
> I had suggested previously that includes could be skipped if they were
> tracked by an enclosing repo, but on reflection this is no good
> (requires you to actually load metadata from that repo), so a modified
> proposal which avoids clashes with existing .hgrc and hgrc config files
> while avoiding security hazards might be (patch on request):
>
> "Read hgrcinclude files from ancestor directories of the repository if
> they are readable and owned by a trusted user and not themselves inside
> any repository, or .hg/hgrcinclude files from ancestor directories if
> readable and trustable."
>
> (I don't like the name 'hginclude' since it sounds too much like it
> would be the opposite of '.hgignore'.)
>
> You could put an hgrcinclude file in a dir containing a bunch of repos,
> or in the .hg dir of the root repo of a forest. Since it is not a dot
> file, it would always be apparent it was there (relevant to Unix only).
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>