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.
Because hgweb doesn't support client certificates, I just patched it to
require client certificates that are signed and verified by the server
certificate. This won't be ideal for production servers, but should be okay
for the test.
The encrypted key file will be used by future patches. I couldn't figure out
a way to redirect a password prompt provided by OpenSSL, so it isn't tested
for now.
The next patch will enable verification by using the system's CA store if
possible, which means we would have to distinguish None (=use default) from
'' (=--insecure). This smells bug-prone and provides no way to override
web.cacerts to forcibly use the system's store by --config argument.
This patch changes the meaning of web.cacerts as follows:
value behavior
------- ---------------------------------------
None/'' use default
'!' never use CA certs (set by --insecure)
<path> verify by the specified CA certificates
Values other than <path> are for internal use and therefore undocumented.
Typical use case of 'unix' mode is a background hg daemon.
$ hg serve --cmdserver unix --cwd / -a /tmp/hg-`id -u`.sock
Unlike 'pipe' mode in which parent process keeps stdio channel, 'unix' server
can be detached. So clients can freely connect and disconnect from server,
saving Python start-up time.
It might be better to write "--cmdserver socket -a unix:/sockpath" instead
of "--cmdserver unix -a /sockpath" in case hgweb gets the ability to listen
on unix domain socket.
This will give PKI-secure behaviour out of the box, without any configuration.
Setting web.cacerts to any value or empty will disable this trick.
This dummy cert trick only works on OS X 10.6+, but 10.5 had Python 2.5 which
didn't have certificate validation at all.
This extension has always had correctness issues and has been
unmaintained for years. It is now removed in favor of the third-party
hgwatchman which is maintained and appears to be correct.
Users with inotify enabled in their config files will fall back to
standard status performance.
As mentioned on http://bz.selenic.com/show_bug.cgi?id=2739#c17 , babf177f9036
left test-http.t failing on Python < 2.4.3. That has not been noticed because
most 2.4 testing has been done with a patched 2.4.2.
This makes sure that the tests only are run for Python >= 2.4.3. That makes it
possible to verify that everything else works with Python 2.4.
This adds a new root hghave to test against. Almost all of these are a
subset of unix-permissions, but that is also used for checking exec
bit handling.
This patch adds "py3k" feature to check whether test runs with Python
3.x.
This check is needed for portability of test code: for example, in the
default, modules are imported relatively first with python 2.x, but
imported absolutely with Python 3.x.
This patch adds "absimport" feature to check whether "absolute_import"
exists in __future__, which means supporting module loading by
absolute name.
This check is needed for portability of test code using
"absolute_import", because Python earlier than 2.5 doesn't support it.
test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on
any date prior to 1970. AIX mktime() gives an error on such dates, so the
problem is deeper than touch and attempts to work around touch in Python
failed.
Give up. Add an AIX test to hghave and skip the absurd date test on AIX.
