[PATCH] run-tests: alias hg to hg.exe for Windows

[Mads Kiilerich]

Adrian wrote:
> diff --git a/tests/run-tests.py b/tests/run-tests.py
> --- a/tests/run-tests.py
> +++ b/tests/run-tests.py
> @@ -617,6 +617,7 @@
>           script.append('set -x\n')
>       if os.getenv('MSYSTEM'):
>           script.append('alias pwd="pwd -W"\n')
> +        script.append('alias hg=hg.exe\n')
>       for n, l in enumerate(t):
>           if not l.endswith('\n'):
>               l += '\n'

Oh yes, of course. That is an elegant solution to the problem that msys 
bash will prefer 'hg' over 'hg.exe' while we would prefer the opposite.

+1

> With regards to this patch here, like I already said, we can put the
> alias into
>
>    C:\MinGW\msys\1.0\etc\profile

-1

It is one thing to do hacks in run-tests or in the tests ... or to 
require that run-tests is invoked in a special environment with 
environment variables set correctly and the right tools installed.

But requiring special hacks in 'globally' installed tools is IMO too 
invasive.

> [without 'hg' in path] the following tests currently fail here:
>    Failed test-log.t: output changed
>    Failed test-revset.t: output changed

Could use
   $ . setup.sh
instead of launching a new sh.

>    Failed test-acl.t: output changed
>    Failed test-mq-subrepo.t: output changed
>    Failed test-mv-cp-st-diff.t: output changed

??? I haven't tried but I don't spot any problems.

>    Failed test-bisect.t: output changed
>    Failed test-pending.t: output changed

Could use $PYTHON "$BINDIR"/hg . We have to use that hack in other 
places, so why not use it consistently and be explicit in what we are doing.

We could also let run-tests set something like HGCOMMAND to point to 
either 'hg' or 'hg.exe'.

In general I consider it important that we are testing something 'real'. 
It is a bit backwards that we started testing Mercurial on Windows 
without shipping a decent 'hg' command for Mercurial. Both hg.cmd and a 
py2exe hg.exe has its disadvantages (but also some advantages). It is 
great if the new exe wrapper can be included in Mercurial and build by a 
'make local' or similar. _That_ hg.exe is what we would like to test in 
the test suite and that is what we will do with your nice alias.

But I don't think it is a problem that we in a few places invoke 
Mercurial differently and let bash find 'hg' and read the '!#' line and 
find a python to invoke 'hg' with.

We could recommend msys users to add the alias to their 'local' bash 
configuration if they want to hit 'hg.exe' from the bash command line too.

Matt wrote:
> Right, this is exactly my point. The test suite mostly works today
> without hg.exe (as you've observed).

The only documented way to run it is by using something hackable-ish 
which have a hg.exe. And it do require installation of the right MSYS 
tools and slightly tricky compilation of the extensions. It is not 
something that works out of the box. Yet.

A test suite that mostly works is useless. But the test suite run as 
documented on the wiki do in general run cleanly - as shown by the 
buildbot. That is IMO the invariant we should maintain.

> Given that, the correct _order_ to do things is:
>
> a) include hg.exe
> b) alias hg to hg.exe in the test suite
>
> If you do it the other way, much of the test suite is needlessly broken
> between steps. There's nothing to be confused about here, this is just a
> trivial and pedantic application of our long-standing process rule:
> don't break things between patches.

Yes, it would be nice to do it in that order.

But adding the alias first will (AFAIK) not cause regressions for the 
"supported" ways of running the test suite. It will be a step in the 
right direction and help getting hg.exe right and help getting the tests 
right for having a hg.exe. I would be fine with pushing the alias first. Ok?

/Mads