Porting test-tag.t

Mads Kiilerich mads at kiilerich.com
Fri Jun 1 13:43:11 CDT 2012


On 01/06/12 20:06, Adrian Buehlmann wrote:
> On 2012-06-01 19:38, Mads Kiilerich wrote:
>> On 01/06/12 18:59, Adrian Buehlmann wrote:
>>> I've been trying to port test-tag.t for testing with MSYS on Windows, but failed so far.
>>>
>>> The closest thing I got half-way working for now is:
>>>
>>> diff --git a/tests/test-tag.t b/tests/test-tag.t
>>> --- a/tests/test-tag.t
>>> +++ b/tests/test-tag.t
>>> @@ -1,5 +1,3 @@
>>> -  $ "$TESTDIR/hghave" system-sh || exit 80
>>> -
>>>      $ hg init test
>>>      $ cd test
>>>
>>> @@ -219,8 +217,7 @@
>>>      >   echo "custom tag message">   "$1"
>>>      >   echo "second line">>   "$1"
>>>      >   __EOF__
>>> -  $ chmod +x editor
>>> -  $ HGEDITOR="'`pwd`'"/editor hg tag custom-tag -e
>>> +  $ HGEDITOR="sh editor" hg tag custom-tag -e
>> (For stability we might want to preserve the path to 'editor' so it can
>> be used from any working directory. The editor pattern shows up in
>> several places, so it would perhaps be simpler to include a shared
>> support tool in the test suite - just like printenv.)
> Everything I tried using bare pwd failed so far.
>
> FWIW, pwd returns pretty strange strings:
>
>    $ pwd
>    /C/users/adi/hgrepos/hg-main/tests
>
> which I think might confuse code that (a) believes it runs on Windows, but
> (b) gets absolute paths that don't conform to Windows path rules.
>
> (but I guess I'm just wildly guessing here.)

The (almost) single part of magic msys bash do is that it will convert 
all arguments and environment variables that are absolute unix paths to 
absolute windows paths.

Running
   bash$ foo.exe /C/users/adi/hgrepos/hg-main/tests
will thus launch foo.exe 'exactly' as if launched as
   C:\> foo.exe C:\users\adi\hgrepos\hg-main\tests

That magic cause failure in a few places, for example where we pass url 
paths as command arguments. They are guarded with no-msys (or can be 
written as //foo, IIRC). Otherwise the conversion works fine. The sh 
script runs in a 95% posix environment and hg runs in a 100%(?) native 
environment.

But hmm ... I guess it incorrectly will consider 
HGEDITOR="/C/users/adi/hgrepos/hg-main/tests editor" as one filename ... 
which however will be converted in a way that will work when interpreted 
as a command with one parameter. Adding additional quoting as 
HGEDITOR='"/C/users/adi/hgrepos/hg main/tests" editor' might however 
break. Hmm ...

>
>>>      $ hg log -l1 --template "{desc}\n"
>>>      custom tag message
>>>      second line
>>> @@ -305,7 +302,7 @@
>>>
>>>      $ hg init repo-tag
>>>      $ hg init repo-tag-target
>>> -  $ hg -R repo-tag --config hooks.commit="hg push \"`pwd`/repo-tag-target\"" tag tag
>>> +  $ hg -R repo-tag --config hooks.commit="hg push \"$TESTTMP/repo-tag-target\"" tag tag
>> (That change is not directly related and not necessary. `pwd` is aliased
>> to do what we want it to do. Variable expansion is however faster, so it
>> is not a bad idea.)
> Using pwd it fails with

Yes, using `pwd` is neither the cause nor the cure, AFAICS.

> Using the python trick you mentioned (but using "hg" instead of "hg.py")

You don't rename hg to hg.py as the wiki recommends? That will 
apparently work on some windows versions, but on other windows versions 
(or machines where python is installed globally?) bash and/or cmd will 
prefer 'hg' over 'hg.exe' and thus launch hg incorrectly somehow. I 
recommend doing the move to avoid that source of error while 
investigating other problems.

/Mads


More information about the Mercurial-devel mailing list