Summary:
Similar to chg. Add flags to run tests with watchman. This is mostly moving
features from `fsmonitor-run-tests.py`. The blacklist is converted to
`#require no-fsmonitor`.
Reviewed By: phillco
Differential Revision: D8434518
fbshipit-source-id: a8512cd71c1171e9037f36dbef195f1e6210f27e
Summary:
`lfs` is the better large file solution. `largefiles` is rarely used, and
its implementation is less clean. So let's remove it.
Test Plan:
Ran all tests. A subrepo test was removed instead of cleaned up since the
longer term plan is to also drop subrepo support.
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6740361
Signature: 6740361:1516225594:555e3803571ad05e0434021897a2823ac99347ae
IMHO, these tests were listed up in blacklist at f82d98daa0de, because
fsmonitor extension wasn't correctly installed before actual testing
at that revision (this issue was fixed by 5b36c6365794).
This script does a bunch of non-trivial configuration work: in particular, it
sets up an isolated instance of Watchman which isn't affected by global state
and can be torn down on completion.
This script also sets the HGFSMONITOR_TESTS environment variable, which hghave
will use in the next patch to allow gating on whether fsmonitor is enabled.
With fsmonitor enabled, there appear to be a number of failures in the test
suite. It's not yet clear to me why they're happening, but if someone would
like to jump in and fix some of them I hope this will be helpful for that.
Extension to plug into a Watchman daemon, speeding up hg status calls by
relying on OS events to tell us what files have changed.
Originally developed at https://bitbucket.org/facebook/hgwatchman
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.
Following discussions with Gilles Morris [1], it seems that it is preferable to
use several blacklist files in a blacklists/ directory. It is easier to add an
unversioned file for experiments than modifying a tracked file.
Also fall back to a simpler syntax, giving up ConfigParser, now that section
names are not needed anymore.
And allow --blacklist parameter to be a complete path, instead of only one
of the filenames contained in tests/blacklists/
[1] http://www.selenic.com/pipermail/mercurial-devel/2009-December/017317.html