Proposal: project hooks and policies

Jonathan S. Shapiro shap at
Wed Mar 5 09:34:51 CST 2008

I would like reaction to this before I go try to build this. There has
been a lot of discussion on this topic, but I'm not aware of any

Problem: you have a project. You want to ensure that some project-wide
policy (enforced by hooks) is maintained, and you want to ensure that
certain extensions are present (perhaps your scripts rely on them).

It is straightforward to build a repository containing all of your
necessary hooks and extensions and ask people to clone that when they
start working on your project. You could even stick a PROJECT.HGRC file
of some sort in there that would load the needed extensions and hooks.

There are three remaining problems:

  1. There is no current mechanism to import PROJECT.HGRC from
  2. The down-stream user's local path to the policy workspace may not
     match yours.
  3. Because hooks can run arbitrary code, it is not safe to clone the
     portion of a .hgrc that loads them.
  4. The "hg clone" command does not preserve the entries you need
     to have in the down-stream .hgrc.

The first part is pretty easy to solve.

I suggest that the second and third parts can be solved together, and
that resolving [2] provides the answer to [3].

Here is how: 

  1. Ensure that PROJECT.HGRC has a unique URI (in the same sense that a
     W3C standard has a unique URI). One good choice is the URL of the
     master policy distribution repo for the project. For example:


     is the HG policy repo for the coyotos project.

  2. Add a new section [importrc] to hgrc, with the syntax:


     where the xx must be unique but has no other significance.

     This section is cloned whenever a workspace is cloned.

  3. Have the user specify where to locate that UNIQUE URI on their own
     system. This is done by adding an hgrc section [rcpaths] to a
     trusted hgrc file (typically ~/.hgrc) whose entries are *pairs* of
     lines of the form:


     where LOCAL-PATH is a path to the local clone of PROJECT.HGRC.

     An [rcpaths] section in a non-trusted hgrc files is ignored.

     An [rcpaths] section is NEVER cloned.

     A file that is named by an xx.local entry is presumed
     to be a trusted HGRC file, and is permitted to load hooks and
     extensions using relative paths (which are relative to LOCAL-PATH).

  4. When HG processes WS/.hg/hgrc and encounters an entry in an
     [importrc] section, it imports the corresponding hgrc if and only
     if the [rcpaths] section of some trusted hgrc file (typically
     ~/.hgrc) specifies a local mapping for the unique URI.

Security is provided by the fact that the user can delete or comment out
(or simply never add) the rcpath entry, in which case the imported HGRC
will not be loaded and none of its directives will have any effect.



More information about the Mercurial-devel mailing list