Summary:
Remove the test for the `search` attribute on the passed-in regexp in
`hghave.matchoutput`. It's not necessary, and causes new check-code errors.
Reviewed By: quark-zju
Differential Revision: D7098248
fbshipit-source-id: b5f18c0db3cfbb37c9f7e23e2cdfdef9cedd3f49
Summary:
Some of our internal hg builds include the Eden extension now. This was
causing the test-help.t test to fail since it included help output for the Eden
extension, but the test code did not expect this.
We unfortunately cannot update the test output to always expect help output for
Eden since the Eden extension is only included in buck-based builds.
Reviewed By: quark-zju, farnz
Differential Revision: D7063937
fbshipit-source-id: e503ddc6889e546b5333a8d9e3555097d689e24c
Summary:
Within buck test envirionment there is no guarnatee that `pyflakes` binary is
in `PATH`. This patch builds pyflakes as a test dependency so buck test will
run `test-check-pyflakes.t` instead of skipping it.
Reviewed By: markbt
Differential Revision: D7008100
fbshipit-source-id: eca6f0174dbc9c12d45eca2f17f70a9805f13094
Summary:
When running with a Python runtime with a slightly different zlib module,
some `zlib.compress` outputs are different. Some tests are testing the
length, or the content of `zlib.compress` output, directly or indirectly.
That's causing issues.
This patch adds a `common-zlib` hghave test so it can be used to gate tests
checking zlib output. Some lengths are also changed to glob patterns to be
compatible.
Reviewed By: ryanmce
Differential Revision: D6937735
fbshipit-source-id: 2328a39d7f2022f16d51f61b6178568b26dfe2fb
Summary:
With `buck build`, the single hg binary won't be guarnateed to have
access to i18n messages because directories like `mercurial/locale`
do not exist on filesystem. It could also mess up with `PYTHONPATH`
somehow because the python binary wrapper sometimes ignores
`PYTHONPATH`.
So let's add a hghave feature for it. And gate troublesome tests
with `#if normal-layout`.
Reviewed By: DurhamG, phillco
Differential Revision: D6879876
fbshipit-source-id: 3d63605b55c8f7096093b89be824add2ec491f81
Summary:
`lz4.block` needs to be imported explicitly before being able to
use `lz4.block.compress`.
We didn't notice this because we're using an old version of
`python-lz4`.
Reviewed By: DurhamG
Differential Revision: D6879877
fbshipit-source-id: 37e8fdc00386bef3733753f925ad308f42e5a740
Summary:
Enables running `check-*` tests from fbsource. This used to check for the existence of a `.hg` folder to detect a repo (so
it can run `hg files`). Internally, we'll always have a repo, and externally we'll likely use git to publish so we'll need another
solution there anyway.
(Note: this ignores all push blocking failures!)
Reviewed By: DurhamG
Differential Revision: D6792787
fbshipit-source-id: 342e29d3a99e82ccd24effb8df02ac6309e80909
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
