This patch also makes some expected output lines in tests glob-ed for
persistence of them.
BTW, files below aren't yet changed in 2017, but this patch also
updates copyright of them, because:
- mercurial/help/hg.1.txt
almost all of "man hg" output comes from online help of hg
command, and is already changed in 2017
- mercurial/help/hgignore.5.txt
- mercurial/help/hgrc.5
"copyright 2005-201X Matt Mackall" in them mentions about
copyright of Mercurial itself
This patch also adds new check-code.py pattern to detect invalid usage
of "mercurial@selenic.com".
Change for test-convert-tla.t is tested, but similar change for almost
same test-convert-baz.t isn't yet tested actually, because I couldn't
find out the way to get "GNU Arch baz client".
AFAIK, buildbot skips test-convert-baz.t, too. Does anybody have
appropriate environment for testing?
I've updated the script to reflect changes in Mercurial and to include a much
more through installation guide with configuration examples and details on how
to configure IIS. I've used the script to set up a working server from scratch.
This addition to the inno installer script means that the windows uninstaller
registry key “DisplayVersion" is set to the application version number and
will show in Add/Remove Programs.
When "hg.bat" is invoked via interactive shell "cmd.exe" on Windows,
it can store own exit code into ERRORLEVEL correctly, regardless of
explicit "exit" statement in it: "cmd.exe" seems to hold ERRORLEVEL
updated by the last command in the batch file (= "python hg", in
"hg.bat" case).
On the other hand, "hg.bat" is invoked indirectly via
"subprocess.Popen" (e.g. shell alias, hooks, hgclient and so on), the
parent process always receives exit code 0 from spawned "hg.bat":
batch files on Windows seem not to be really spawned like as shell
scripts on UNIX, but to be executed in the "cmd.exe" process.
This patch returns exit code explicitly for indirect invocation.
"/b" should be specified for "exit" to prevent "cmd.exe" from being
terminated when "hg.bat" is invoked interactively from it.
The merge tool configuration is an essential part of a good initial user
experience. 'make osx' installers and direct 'make' installation did not have
merge tool configuration. Now they have.
Note: The installer fixes for windows have been done blindly and might require
additional changes.
Before this patch, "hg.bat" for Windows environment always uses
"%~dp0..\python" as explicit path to "python.exe".
This path may not be valid in some cases.
For example, on the environment using "virtualenv" python package,
both "python.exe" and "hg.bat" are placed in the same directory. In
this case, "python.exe" should be found on PATH, because virtualenv
activation script puts "python.exe" on the PATH.
This patch uses explicit path to "python.exe" only if it exists, and
expects that "python.exe" can be found on PATH otherwise.
I sometimes look at a piece of software and if the man page says
"Copyright 2004", then I'm inclined to think that the project is stale
or that the authors are lazy. Neither is good publicity for us :-)
As stated in http://msdn.microsoft.com/en-us/library/cc664727.aspx, when you
compile an application with MSVC 2008 SP1 it is bound by default to the
original CRT version (9.0.21022.8). This is the case for Python 2.6 up to 3.1.
If the wrong CRT version is embedded in the Inno Setup installer, with a PC
that does not have the MSVC 2008 redistributable package installed, hg will
refuse to launch with an error: "the system cannot execute the specified
program".
