This allows us to write doctests depending on a ui object, but not on global
configs.
ui.load() is a class method so we can do wsgiui.load(). All ui() calls but
for doctests are replaced with ui.load(). Some of them could be changed to
not load configs later.
test-convert-darcs.t suddenly started failing on my Debian sid machine. The
reason was Darcs was upgraded from 2.12.0 to 2.12.4 so the original pattern
got to match the last two digits. Fix the pattern to match 2.2+.
On some platforms, cwd can't be removed. In which case, util.unlinkpath()
continues with no error since the failure of directory removal isn't critical.
So it doesn't make sense to run the test added by 6395630fdfdc on those
platforms. OTOH, we need to run the test in test-rebase-scenario-global.t
since the repository is referenced after that.
My bzr does not have bzrlib.revisionspec.RevisionSpec,
and thus tests were failing because convert refused to believe in bzr,
but hghave without this change thought it was available.
The Python ssl module conditionally sets the TLS 1.1 and TLS 1.2
constants depending on whether HAVE_TLSv1_2 is defined. Yes, these
are both tied to the same constant (I would think there would be
separate constants for each version). Perhaps support for TLS 1.1
and 1.2 were added at the same time and the assumption is that
OpenSSL either has neither or both. I don't know.
As part of developing this patch, it was discovered that Apple's
/usr/bin/python2.7 does not support TLS 1.1 and 1.2 (only TLS 1.0)!
On OS X 10.11, Apple Python has the modern ssl module including
SSLContext, but it doesn't appear to negotiate TLS 1.1+ nor does
it expose the constants related to TLS 1.1+. Since this code is
doing more robust feature detection (and not assuming modern ssl
implies TLS 1.1+ support), we now get TLS 1.0 warnings when running
on Apple Python. Hence the test changes.
I'm not super thrilled about shipping a Mercurial that always
whines about TLS 1.0 on OS X. We may want a follow-up patch to
suppress this warning.
Tests were failing on systems like RHEL 7 where loading the system
certificates results in CA certs being reported to Python. We add
a feature that detects when we're able to load *and detect* the
loading of system certificates. We update the tests to cover the
3 scenarios:
1) system CAs are loadable and detected
2) system CAs are loadable but not detected
3) system CAs aren't loadable
Before, the return of _defaultcacerts() was 1 of 3 types. This was
difficult to read. Make it return a path or None.
We had to update hghave.py in the same patch because it was also
looking at this internal function. I wasted dozens of minutes
trying to figure out why tests were failing until I found the
code in hghave.py...
Several tests fail with chg for several reasons such as loaded chgserver
extension, running uisetup() per server instead of per runcommand, etc.
Since these tests can't/shouldn't be changed to be chg friendly, we need
a flag to skip them.
This patch explicitly drops CHGHG environment if chg isn't involved. This
way, hghave can just check if CHGHG exists.
cvsnt is a maintained commercial fork of cvs
https://en.wikipedia.org/wiki/CVSNT
It is possible to build a version of it from sources (github),
it requires libpcre and libltdl (libtool).
We already have a test that relates to cvsnt:
test-convert-cvsnt-mergepoints.t
cvsnt installs: cvs, cvslockd, cvsnt, cvsscript
I think we should definitely have a check for cvsnt because it makes
the version checks for cvs make a lot more sense.
When I use the version I built, cvs --version says:
"""
Concurrent Versions System (CVSNT) 2.5.05 (Gan) Build 3744 (Suite) (client/server)
CVSNT 2.5.05 (Apr 4 2016) Copyright (c) 2008 March Hare Software Ltd.
see http://www.march-hare.com/cvspro
CVS Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn,
Jeff Polk, and other authors
CVSNT Copyright (c) 1999-2008 Tony Hoyle and others
see http://www.cvsnt.org
Commercial support and training provided by March Hare Software Ltd.
see http://www.march-hare.com/cvspro
CVSNT may be copied only under the terms of the GNU General Public License v2,
a copy of which can be found with the CVS distribution.
The CVSNT Application API is licensed under the terms of the
GNU Library (or Lesser) General Public License.
Specify the --help option for further information about CVS
"""
hg output varies by version, this helps the hgbook
hg 0.6 did not have a version command, so special case it...
hg 0.7-0.8 had a version command which returned unknown...
hg 0.8 added a --date flag to annotate
hg 0.9 had a working version command!
Classic cvs stopped at 1.11.
There was a beta version 1.12 that never had a final release.
CVS NT is a fork which starts with versions numbered 2.0+.
We should have an hg have cvsnt, but to test that requires getting
cvsnt, and it's commercial / its older source versions are
hard to find.
Previously, the "ssl" check effectively looked for PyOpenSSL
or Python 2.7.9. After this patch, we simply look for just the
"ssl" module.
After b93c7184b1ea, there have been no references to PyOpenSSL in
the tree (the previous usage of PyOpenSSL was to implement ssl
support on old, no longer supported Python versions that didn't
have an ssl module (e.g. Python 2.4). So, the check for PyOpenSSL
served no purpose.
Pythons we support ship with the ssl module. Although it may not be
available in all installations. So, we still need the check for
whether the ssl module imports, hence the hghave check.
The main side-effect of this change is that we now run test-https.t
(the only test requiring the "ssl" hghave feature) on Python <2.7.9
when PyOpenSSL is not installed (which is probably most installations)
and the ssl module is available. Before, we wouldn't run this test
on these older Python versions.
I confirmed that test-https.t passes with Python 2.6.9 and 2.7.8 on
OS X 10.11.
Currently, very few parts of Mercurial run under Python 3, notably the
test harness.
We want to write tests that run Python 3. For example, we want to
extend test-check-py3-compat.t to parse and load Python files.
However, we have a problem: finding appropriate files requires
running `hg files` and this requires Python 2 until `hg` works
with Python 3.
As a temporary workaround, we add --with-python3 to the test harness
to allow us to define the path to a Python 3 interpreter. This
interpreter is made available to the test environment via $PYTHON3 so
tests can run things with Python 3 while the test harness and `hg`
invocations continue to run from Python 2. To round out the feature,
a "py3exe" hghave check has been added.
Hypothesis a library for adding fuzzing over a range of structure
data to your test suite: http://hypothesis.readthedocs.org/en/latest/
This adds the ability to build tests using Hypothesis within the Mercurial test
suite. New tests and fixes using this helpers comes in later changesets.
This currently refuses to operate if on a non-Linux host. I suspect
that Docker running on FreeBSD 11 or on an Illumos derivative would
work fine, but I don't have ready access to such a system.
On OS X using boot2docker (I used a hacky xhyve-based one for
testing), it won't work because $TESTTEMP doesn't end up inside the
set of directories that get forwarded to the boot2docker VM, so you
can't actually drop debs in the $TESTTEMP at all. It would be possible
(probably even trivial) to hack around this by using a randomly-named
temporary directory inside the working directory, but that seems
unlikely to be useful enough to justify the ugliness.
I want to add tests for our packaging rules, but those necessarily run
a whole build, or possibly two if both native packaging and docker are
available. This lets us flag such tests with a `#require slow` so that
they don't unnecessarily slow down normal test runs.
Upcoming patches will kill hghave (the script - not hghave.py) and
will move to a model where requirements checking is performed as
a function call.
Start diminishing the utility of hghave by moving some code to
hghave.py.
Python 2.6 introduced a new octal syntax: "0oXXX", replacing "0XXX". The
old syntax is not recognized in Python 3 and will result in a parse
error.
Mass rewrite all instances of the old octal syntax to the new syntax.
This patch was generated by `2to3 -f numliterals -w -n .` and the diff
was selectively recorded to exclude changes to "<N>l" syntax conversion,
which will be handled separately.
