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

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

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

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