Mercurial.ini file locations on Windows

Steve Borho steve at borho.org
Sun Jul 26 17:52:03 CDT 2009


I brought this up right after the 1.2 release and after a bit of
discussion I wrote a couple of patches but eventually it was all
forgotten.  I would like to bring it up again because I have some new
information.

Original issue:

On Windows user_rcpath() does not include any Windows friendly
directories.  The search path has:

* os.path.expanduser('~'), which equates to %USERPROFILE%
* on winver <= NT, it uses os.path.dirname(%APPDIR%), which also
should be %USERPROFILE%

%USERPROFILE% is not a directory that is easily "discoverable".  The
last time I brought up this topic we decided to *add* 'My
Documents'\Mercurial\Mercurial.ini to the user_rcpath() so the user
could choose to keep their Mercurial.ini some place convenient.

The new issue I would like to bring up is UAC on Vista, and the way it
conflicts with our system_rcpath().

Our installer places the system (site-wide) Mercurial.ini in the base
of the install directory, aka %ProgramFiles%\Mercurial\Mercurial.ini.
Mercurial will look for the system Mercurial.ini in the same directory
of as its executable by default, then falls back to a system rcpath
registry value.  The problem in this case is that on Vista, if UAC is
enabled, a user cannot modify the site-wide Mercurial.ini file.  Vista
lets them think that they are, then does some face-palmingly stupid
(virtualization) things in the background to hide this from them.  The
short version is their modified file is kept in a local folder and
whenever any application run by that user tries to open the original
file it actually opens their local copy.  Which is all (cough) fine
until you upgrade your Mercurial release and any changes introduced in
the new Mercurial.ini are superceded by the user's modified copy.

TortoiseHg follows the same file placement scheme as Mercurial, so we
run into the same issue:

http://bitbucket.org/tortoisehg/stable/issue/135
http://stackoverflow.com/questions/562337/vista-phantom-directory

The long term fix to this is probably to move the system wide
Mercurial.ini to a place that is user editable (CommonAppData).  What
I've done for THG in the short term is to put a large disclaimer at
the top of the file telling people not to edit it directly, instead
they should put all modifications in their user Mercurial.ini.  I
suppose another option is to not include a system-wide Mercurial.ini
in the installer at all, and maybe just package a sample one instead.

--
Steve Borho


More information about the Mercurial mailing list