Running tests on windows
Angel Ezquerra Moreu
I'm looking into running the test suite on windows. I got two
different sets of instructions from:
1.- http://mercurial.selenic.com/wiki/WindowsTestingPlan
and
2.- http://mercurial.selenic.com/wiki/HackableMercurial
The pysh repository metioned on #1 has gotten no commits in 13 months.
Am I correct in assuming that the current way to run the tests on
windows is to do as suggested in #2? If so, should I change #1 to
point to #2?
Angel
_______________________________________________
Mercurial-devel mailing list
Mercuri...@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel
Mads Kiilerich
> Hi,
>
> I'm looking into running the test suite on windows. I got two
> different sets of instructions from:
>
> 1.- http://mercurial.selenic.com/wiki/WindowsTestingPlan
>
> and
>
> 2.- http://mercurial.selenic.com/wiki/HackableMercurial
>
> The pysh repository metioned on #1 has gotten no commits in 13 months.
> Am I correct in assuming that the current way to run the tests on
> windows is to do as suggested in #2? If so, should I change #1 to
> point to #2?
It is different and unrelated approaches, and WindowsTestingPlan
predates HackableMercurial.
I documented how to run tests with MSYS in a "hackable" environment and
added the necessary test suite support, workarounds, bug fixes and
blacklists to get a clean run of the test suite (with half the tests
skipped for various reasons).
Unfortunately it seems like nobody uses it, and I assume it now suffers
from bit rot.
That proves to me that the lack of test suite wasn't the reason windows
users don't contribute much. It seems like windows users simply don't
care if Mercurial is stable on their platform and they don't want to
contribute.
I hope this trolling will provoke someone to prove me wrong ;-)
/Mads
Angel Ezquerra Moreu
> On 03/21/2012 08:51 AM, Angel Ezquerra Moreu wrote:
>>
>> Hi,
>>
>> I'm looking into running the test suite on windows. I got two
>> different sets of instructions from:
>>
>> 1.- http://mercurial.selenic.com/wiki/WindowsTestingPlan
>>
>> and
>>
>> 2.- http://mercurial.selenic.com/wiki/HackableMercurial
>>
>> The pysh repository metioned on #1 has gotten no commits in 13 months.
>> Am I correct in assuming that the current way to run the tests on
>> windows is to do as suggested in #2? If so, should I change #1 to
>> point to #2?
>
>
> It is different and unrelated approaches, and WindowsTestingPlan predates
> HackableMercurial.
>
> I documented how to run tests with MSYS in a "hackable" environment and
> added the necessary test suite support, workarounds, bug fixes and
> blacklists to get a clean run of the test suite (with half the tests skipped
> for various reasons).
>
> Unfortunately it seems like nobody uses it, and I assume it now suffers from
> bit rot.
>
> That proves to me that the lack of test suite wasn't the reason windows
> users don't contribute much. It seems like windows users simply don't care
> if Mercurial is stable on their platform and they don't want to contribute.
>
> I hope this trolling will provoke someone to prove me wrong ;-)
:-)
I think the problem may be that windows users are more "GUI oriented".
Perhaps they are simply more likely to contribute to TortoiseHg and
similar GUI tools for example. I know that was originally my case. I
look around me and I see that most windows users I know are not heavy
command line users. There are exceptions of course but it seems to be
a common trend.
I think that hackable mercurial was a very big step forward to make it
easier for us windows users to start to contribute. The fact that the
test suite cannot be run as-is is yet another obstacle that I wish was
not there. Even though thanks to your efforts it is now possible to
run part of the test suite on windows, it is not quite as easy as
running it on Linux yet.
In my opinion there are two things that could make it easier for
windows users to contribute to mercurial:
1. Let the test suite run on cygwin, with as little workarounds and
custom setup steps as possible.
2. Make it possible to run TortoiseHg from sources on top of hackable mercurial.
I think #2 would be quite important. It would give a natural path for
the windows TortoiseHg contributors to contribute to mercurial itself.
Angel
Mads Kiilerich
> I think that hackable mercurial was a very big step forward to make it
> easier for us windows users to start to contribute. The fact that the
> test suite cannot be run as-is is yet another obstacle that I wish was
> not there. Even though thanks to your efforts it is now possible to
> run part of the test suite on windows, it is not quite as easy as
> running it on Linux yet.
Really?
The test suite _do_ run as-is when you have MSYS. But granted, it
requires a posix environment with sh and other tools, something that
"all" unix systems have preinstalled.
Many Unix users have had problems running from source (and thus running
the test suite) because they didn't have a Python development setup and
thus couldn't build Mercurial from scratch.
I don't see much of a difference.
The necessary MSYS packages are easy to install, but they could probably
all be bundled in a 'Hackable2' zip. Hint hint ;-)
> In my opinion there are two things that could make it easier for
> windows users to contribute to mercurial:
>
> 1. Let the test suite run on cygwin, with as little workarounds and
> custom setup steps as possible.
Why is cygwin better? Is it just because you happen to like it and
already have it installed?
Cygwin is however a different environment that neither is windows nor
posix. It might be usable for some purposes, but a test run under cygwin
doesn't prove anything regarding running under "pure" windows.
> 2. Make it possible to run TortoiseHg from sources on top of hackable mercurial.
>
> I think #2 would be quite important. It would give a natural path for
> the windows TortoiseHg contributors to contribute to mercurial itself.
I am sure that already is possible. The main issue will be to decide if
you want to use the Python bundled with 'hackable' or some other Python
that is installed on the system.
What might be missing is a 'Hackable TortoiseHg' that also includes all
the python modules TortoiseHg requires and the tortoisehg source.
/Mads
Angel Ezquerra Moreu
> On 03/21/2012 04:09 PM, Angel Ezquerra Moreu wrote:
>>
>> I think that hackable mercurial was a very big step forward to make it
>> easier for us windows users to start to contribute. The fact that the
>> test suite cannot be run as-is is yet another obstacle that I wish was
>> not there. Even though thanks to your efforts it is now possible to
>> run part of the test suite on windows, it is not quite as easy as
>> running it on Linux yet.
>
>
> Really?
>
> The test suite _do_ run as-is when you have MSYS. But granted, it requires a
> posix environment with sh and other tools, something that "all" unix systems
> have preinstalled.
That is exactly what I meant, plus the fact that apparently not all
tests run on windows, even on MSYS.
> Many Unix users have had problems running from source (and thus running the
> test suite) because they didn't have a Python development setup and thus
> couldn't build Mercurial from scratch.
>
> I don't see much of a difference.
Well, on Windows you need Python _plus_ a posix environment.
> The necessary MSYS packages are easy to install, but they could probably all
> be bundled in a 'Hackable2' zip. Hint hint ;-)
:-) Let's see if I get it to work first!
Does the MinGW license allow that kind of repackaging?
>> In my opinion there are two things that could make it easier for
>> windows users to contribute to mercurial:
>>
>> 1. Let the test suite run on cygwin, with as little workarounds and
>> custom setup steps as possible.
>
> Why is cygwin better? Is it just because you happen to like it and already
> have it installed?
You are partly right. It would be more convenient for me since I
already use Cygwin. It is also my experience that Cygwin has a greater
user base, so it could be argued that potential Windows hackers are
more likely to have it installed and/or know about it. Sure, this is a
weak reason, since people can install MinGW, but it is yet another
little inconvenience.
> Cygwin is however a different environment that neither is windows nor posix.
> It might be usable for some purposes, but a test run under cygwin doesn't
> prove anything regarding running under "pure" windows.
According to the "MinGW - Cygwin comparison" on Wikipedia
(http://en.wikipedia.org/wiki/MinGW#Comparison_with_Cygwin), Cygwin is
more POSIX compatible than MinGW. In particular:
"Because MinGW is dependent upon Win32 API calls, it cannot provide a
full POSIX API; it is unable to compile some Unix applications that
can be compiled with Cygwin. Specifically, this applies to
applications that require POSIX functionality like fork(), mmap() or
ioctl()[15] and those that expect to be run in a POSIX environment."
>> 2. Make it possible to run TortoiseHg from sources on top of hackable
>> mercurial.
>>
>> I think #2 would be quite important. It would give a natural path for
>> the windows TortoiseHg contributors to contribute to mercurial itself.
>
>
> I am sure that already is possible. The main issue will be to decide if you
> want to use the Python bundled with 'hackable' or some other Python that is
> installed on the system.
It may be possible, but it is not easy. Yet another barrier :-(
> What might be missing is a 'Hackable TortoiseHg' that also includes all the
> python modules TortoiseHg requires and the tortoisehg source.
That would be great!
Anyway, I'm not saying that it is impossible to hack on mercurial from
windows, but it is definitely harder than using Linux.
For example, I just followed the instruction on the HackableMercurial
wiki page and I managed to be able to run the tests. That is great,
but then I tried to run the patchbomb test, to verify a change that I
just did to the patchbomb extension and unfortunatelly that particular
set of tests does not work. That would not have happened if I was
using Linux. That may partly explain why there are less Windows
mercurial hackers.
Cheers,
Angel
Matt Mackall
Umm, no. Indeed, more people may have a Cygwin install than a MinGW
install, but that's not what we care about at all. We primarily care
about testing the _normal Windows API/environment/libraries/filesystem_
and we don't care about supporting Cygwin's emulation weirdness much at
all because their are vastly more generic Windows users. Thus using
MinGW's bash to run shell scripts in an otherwise Windows-like
environment is much more useful.
> For example, I just followed the instruction on the HackableMercurial
> wiki page and I managed to be able to run the tests. That is great,
> but then I tried to run the patchbomb test, to verify a change that I
> just did to the patchbomb extension and unfortunatelly that particular
> set of tests does not work. That would not have happened if I was
> using Linux. That may partly explain why there are less Windows
> mercurial hackers.
Really, I think it's cultural. Our user base looks like this:
Windows >> Mac >> Linux
And our developer base looks like this:
Linux >> Mac >> Windows
And that situation has persisted for ages. If the potential Windows
contributor/user ratio was even a tenth of what it is on Linux, this
list would be dominated by Windows hackers and we would have blown past
all these obstacles years ago. But instead it took six years before a
frustrated project leader who doesn't even have a copy of Windows
finally got around to building HackableMercurial using Linux + Wine.
And on Mac, there aren't really any excuses. Mercurial installs are
"hackable" out of the box, the test suite runs, and there's a standard,
free compiler. There should be enough Mac developers out there that I
never have to lift a finger to fix Mac bugs and yet we manage to make
releases like 2.1.1 where no one notices it doesn't compile until after
it ships.
--
Mathematics is the supreme nostalgia of our time.
Brendan Cully
> And on Mac, there aren't really any excuses. Mercurial installs are
> "hackable" out of the box, the test suite runs, and there's a standard,
> free compiler. There should be enough Mac developers out there that I
> never have to lift a finger to fix Mac bugs and yet we manage to make
> releases like 2.1.1 where no one notices it doesn't compile until after
> it ships.
Ideally yes. On the other hand, there is a buildbot and you do have an
OS X shell, so it wouldn't have taken much more than a lifted finger
to prevent that one. That build-breaking patch was only applied a few
days before release.
Speaking of mac bugs identified by the buildbot,
hg bisect -c "./run-tests.py test-casefolding.t test-casecollision-merge.t"
says
The first bad revision is:
changeset: 16093:7e30f5f2285f
user: Matt Mackall <m...@selenic.com>
date: Thu Feb 09 16:50:19 2012 -0600
summary: merge: refactor unknown file conflict checking