Mercurial.ini file locations on Windows

[Gabor Grothendieck]

This does not solve the problem but the rcpath extension helps a bit
in that the user can employ it to discover the used and potential
paths:

http://mercurial.selenic.com/wiki/RcpathExtension


On Sun, Jul 26, 2009 at 6:52 PM, Steve Borho<steve at borho.org> wrote:
> 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
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>