Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 21:27:02 -0700] rev 37438
commands: don't violate storage abstractions in `manifest --all`
Previously, we asked the store to emit its data files. For modern
repos, this would use fncache to resolve the set of files then would
stat() each file. For my copy of the mozilla-unified repository, this
took 3.3-10s depending on the state of my filesystem cache to render
449,790 items.
The previous behavior was a massive layering violation because it
assumed tracked files would have specific filenames in specific
directories. Alternate storage backends would violate this assumption.
The new behavior scans the changelog entries for the set of files
changed by each commit. It aggregates them into a set and then
sorts and prints the result. This reliably takes ~16.3s on my
machine. ~80% of the time is spent in zlib decompression.
The performance regression is unfortunate. If we want to claw it
back, we can create a proper storage API to query for the set of
tracked files. I'm not opposed to doing that. But I'm in no hurry
because I suspect ~0 people care about the performance of
`hg manifest --all`.
.. perf::
`hg manifest --all` is likely slower due to changing its
implementation to respect storage interface boundaries. If you
are impacted by this regression in a meaningful way, please make
noise on the development mailing list and it can be dealt with.
Differential Revision: https://phab.mercurial-scm.org/D3119
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 21:09:47 -0700] rev 37437
commands: document the layering violation in `manifest --all`
This commit fixes the last test failures when using the simple
store extension!
It turns out that `hg manifest --all` locks the repo and scans for
revlogs. This feature was added by 71938479eff9 in 2011. I am
debating changing the behavior. But that can occur in another
commit.
As part of debugging this, I realized that test-manifest.t is the
only meaningful tester of `hg manifest --all` and that test was
improperly disabled when bundlerepos aren't supported. The test is
testing manifest behavior, not whether you can `hg pull` from a
bundle. So I changed the test to `hg unbundle` instead.
FWIW, I wasted a non-trivial amount of time tracking down this
failure. I thought the issue involved Git, which is why I refactored
the test to be more deterministic. Never in my mind would I have
guessed that code in `hg manifest` would scan revlogs. I should have
looked there to begin with. Doh.
Differential Revision: https://phab.mercurial-scm.org/D3118
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 19:17:22 -0700] rev 37436
simplestore: correctly implement flag processors
There were a couple of bugs around the implementation of
flags processing with the simple store. After these changes,
test-flagprocessor.t now passes!
test-flagprocessor.t was also updated to include explicit test
coverage that pushed data is as expected on the server.
The test extension used by test-flagprocessor.t has been updated
so it monkeypatches the object returned from repo.file() instead
of monkeypatching filelog.filelog. This allows it to work with
extensions that return custom types from repo.file().
The monkeypatching is rather hacky and probably is performance
prohibitive for real repos. We should probably come up with a
better mechanism for registering flag processors so monkeypatching
isn't needed.
Differential Revision: https://phab.mercurial-scm.org/D3116
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 17:40:09 -0700] rev 37435
tests: `hg init` after resetting HGRCPATH
Otherwise extensions loaded via --extra-config-opt could prevent
access to the repo by introducing requirements file. This does mean
that custom extensions loaded in this way won't impact this test.
I'm fine with that.
Differential Revision: https://phab.mercurial-scm.org/D3115
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 17:33:59 -0700] rev 37434
tests: work around potential repo incompatibility
test-run-tests.t invokes run-tests.py. But custom extensions providing
new repo requirements may be in play and may not get inherited by the
new run-tests.py. We ensure our repo is created with a vanilla config
to mitigate extension-caused badness.
Differential Revision: https://phab.mercurial-scm.org/D3114
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 17:29:02 -0700] rev 37433
tests: disable test-keyword.t with simple store
The keyword extension is hooking into repo.file() and defining its
own filelog class. It will likely require a more formal storage
interface before keywords are usable with alternate storage backends.
Differential Revision: https://phab.mercurial-scm.org/D3113
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Apr 2018 17:12:00 -0700] rev 37432
tests: conditionalize test-treemanifest.t
Parts of the test were assuming the use of revlogs with fnstore
path encoding.
Other parts of the test assumed we could create repos with different
store encodings and that stream clone bundles worked.
Make all of this conditional on running a revlog repo.
Differential Revision: https://phab.mercurial-scm.org/D3112