x64 hg.exe

Mads Kiilerich mads at kiilerich.com
Fri Jun 22 07:35:48 CDT 2012


On 22/06/12 14:19, Adrian Buehlmann wrote:
> It's not like the testsuite wouldn't pass with the hg left in place
> there though (at least that's what I think).

IIRC it failed in some places, but all the issues I saw got resolved 
with some compromise that worked in both cases.

The biggest annoyance right now is that in a pure 'hackable' environment 
without python in path then 'hg' from a bash prompt will fail to resolve 
the '#!' in 'hg'.

> But it's probably not what we want any more: We most likely don't want
> to have the hg called for most of the test calls (happens via sh and
> env), if we put a hg.exe there.
>
> If we have both a hg.exe and hg there, then most of the test calls
> happen to call the hg (via env) - not the hg.exe. Only a very small
> number of test calls (e.g. commandserver) are really picking up the
> hg.exe and thus absolutely depend on it.
>
> If we remove the hg file (which was placed there by checking out a
> revision of mercurial), we totally force depending on the hg.exe. For
> everything.
>
> And obviously, if I want to know whether the hg.exe I built works for
> all hg calls in all tests, I want it to be used by all calls. And I can
> currently only achieve that by removing the hg file. Because if there is
> a hg file, it will be given preference over the hg.exe.
>
> I hope I described and understood that now correctly and completely.

Yes, agreed, that is a good description of the reasons for having and 
using hg.exe.

A couple of quick random additional comments in this area:

There could be some reasons to prefer to not use hg.exe - for example if 
it turns out to be slow ... or if the serve -d issue can't be solved.

It is also quite annoying that 'up -C' will restore 'hg' so it has to be 
removed again. Removing it is not an elegant solution.

Shipping exemaker source with Mercurial and building it as we build 
extensions would mitigate many of the problems it has now.

Other issues could be solved by using a custom 'bin' folder in 
run-tests, similar to how '-l' does.

/Mads


More information about the Mercurial-devel mailing list