[PATCH STABLE] test-bookmarks: factor hooks out to a shell script for Windows

[Gregory Szorc]

On Thu, Apr 27, 2017 at 5:55 PM, Augie Fackler <raf at durin42.com> wrote:

>
> > On Apr 27, 2017, at 20:55, Sean Farley <sean at farley.io> wrote:
> >
> > Matt Harbison <mharbison72 at gmail.com> writes:
> >
> >> On Thu, 27 Apr 2017 10:47:14 -0400, Augie Fackler <raf at durin42.com>
> wrote:
> >>
> >>> On Tue, Apr 25, 2017 at 10:34:00PM -0400, Matt Harbison wrote:
> >>>> # HG changeset patch
> >>>> # User Matt Harbison <matt_harbison at yahoo.com>
> >>>> # Date 1493172626 14400
> >>>> #      Tue Apr 25 22:10:26 2017 -0400
> >>>> # Branch stable
> >>>> # Node ID 493b1e7c6299055e7240e704548677797de35be7
> >>>> # Parent  dc1d4df47b5ba0f908f91cf6a4b7e7cf73f40884
> >>>> test-bookmarks: factor hooks out to a shell script for Windows
> >>>
> >>> Queued, thanks. How are tests on windows doing these days? Using msys,
> >>> or something else?
> >>
> >> Tantalizingly close to green, and that's with a local hghaveaddon.py
> that
> >> enables #serve on Windows.  Only 81 tests are skipped.
> >>
> >> https://www.mercurial-scm.org/pipermail/mercurial-devel/
> 2017-April/096987.html
> >>
> >> Of that list, the bookmarks-pushpull.t test is fixed here.  http-proxy.t
> >> is the one nobody has chimed in on yet, but I can't imagine that it's
> >> critical.  hghave.t and logtoprocess.t are not important.
> >>
> >> I'm on Windows 7, with MinGW that I installed ~5 years ago.  I'm
> hesitant
> >> to upgrade, because it works.  Kostia told me offline that he thinks
> >> there's ~90 tests failing, but he's on Windows 10, and doing some custom
> >> build stuff.
> >
> > What are the chances of being able to use WSL for running tests?
>
> Not great. WSL has some of the same weirdness as cygwin, and you really
> want to stay either all-WSL or all-Windows, and avoid crossing the streams.
>

Not as much weirdness. With the Windows 10 Creators Update, WSL is
surprisingly similar to a native Linux install. It's freaky.

Also with the Windows 10 Creators Update, WSL can run Win32 processes. If
you type foo.exe in your bash shell running from an ELF executable, it just
works. But there is weirdness with paths. Win32 processes have c:\ etc and
ELF processes have /mnt/c etc. All the WSL paths are backed by NTFS, which
is a bit wonky. But it works. And it is transparent from WSL. Speaking of
transparency, pretty much everything under WSL thinks it is running native
Linux. You have to teach software to recognize it is running under WSL.

>From the perspective of testing Mercurial, WSL has to be thought of as a
distinct platform. It isn't Windows because it is executing ELF and making
POSIX system calls "natively." But it isn't (yet) Linux either because
there are subtle differences with the Linux "emulation" in WSL. This means
that testing on WSL is *not* a substitute for testing on native Windows. It
does mean we should consider running CI fo WSL.

The differences between WSL and Linux are marginal. Using WSL from the
Windows 10 Creators Update, Mercurial's test suite with revision
6e0368b6e0bb passes with the exception of test-http-bad-server.t (possibly
faulty test), test-http-proxy.t (something wonky at the network layer),
test-paths.t (zeroconf is broken?), and some test-http-* tests are
slow/unresponsive. The only skipped tests are the usual suspect under Linux
(test-convert-* missing executables, case insensitive filesystem, etc). So
for the most part, Mercurial under WSL "just works."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170428/595c3266/attachment.html>