Summary: The test shouldn't run if the dependency (lz4) cannot be imported.
Test Plan:
Run the test on a machine that does not have Python lz4 module installed and
make sure the test gets skipped.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: durham
Differential Revision: https://phabricator.intern.facebook.com/D6678494
Signature: 6678494:1515454247:245401173d9e1ef16ab865c210b1f5412039c1e1
fsmonitor can significantly speed up operations on large working
directories. But fsmonitor isn't enabled by default, so naive users
may not realize there is a potential to make Mercurial faster.
This commit introduces a warning to working directory updates when
fsmonitor could be used.
The following conditions must be met:
* Working directory is previously empty
* New working directory adds >= N files (currently 50,000)
* Running on Linux or MacOS
* fsmonitor not enabled
* Warning not disabled via config override
Because of the empty working directory restriction, most users will
only see this warning during `hg clone` (assuming very few users
actually do an `hg up null`).
The addition of a warning may be considered a BC change. However, clone
has printed warnings before. Until recently, Mercurial printed a warning
with the server's certificate fingerprint when it wasn't explicitly
trusted for example. The warning goes to stderr. So it shouldn't
interfere with scripts parsing meaningful output.
The OS restriction was on the advice of Facebook engineers, who only
feel confident with watchman's stability on the supported platforms.
.. feature::
Print warning when fsmonitor isn't being used on a large repository
Differential Revision: https://phab.mercurial-scm.org/D894
Chg disables demandimport on purpose for performance wins and
therefore, it probably makes sense to indicate that demandimport is disabled
when chg is running.
Test Plan:
Ran all the tests.
Differential Revision: https://phab.mercurial-scm.org/D1161
Even on CentOS 7, git is at version 1.8. It seems git 1.9 is when
ext::sh was introduced so we a check for that. The way these functions
are written follows the same style and format for the way we check svn
and bzr versions.
I've been using a local hghaveaddon.py to enable this for a couple of months
with reasonable success, and 'killdaemons' is already enabled on Windows.
There's one failure[1] in test-http-proxy.t that this adds, which I can't figure
out.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html
We add a minimal check using pylint for one case we knows we care about:
"mutable default" argument.
We'll likely extend this over time to cover other useful checks but this is a
good starting point.
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
"""
