tests: conditionalize test output for simple store Differential Revision: https://phab.mercurial-scm.org/D3061

tests: disallow using simple store repo with bundlerepo bundlerepo is... going to be difficult to port to an alternate store because it assumes revlogs for storage and essentially overlays the contents of a bundle onto a fake revlog-like primitive. It will be a good test case for our eventual new storage interface. Refactoring bundlerepo to make it work with non-revlog storage is going to be a bit of work. So for now, let's refuse to use the simple store repo when a bundlerepo is in play. A new test requirement advertising support for treating bundle files as repo instances has been added. Some tests have been made conditional on this feature. Additional tests will be annotated in subsequent commits. Having positive opt-in to repo features will be simpler in the long run because it will allow multiple storage backends to declare feature support and we won't have to annotate each test with the set of repo backends that are supported. Again, we'll probably want better integration between repo features and tests. But this is the easiest we can do at the moment. Differential Revision: https://phab.mercurial-scm.org/D3060

tests: disable test-revlog-v2 when using simple store Because the simple store has nothing to do with revlogs. Differential Revision: https://phab.mercurial-scm.org/D3056

tests: skip filelog damage tests when not using revlogs Differential Revision: https://phab.mercurial-scm.org/D3042

tests: skip some tests when using simple store generaldelta is a revlog implementation detail. We don't need to test it with the simple store. union repos are heavily revlog based. It should be possible to run them with alternate stores. But it's not worth the trouble at this juncture. Differential Revision: https://phab.mercurial-scm.org/D3040

tests: conditionalize tests based on presence of custom extensions The test harness supports injecting extensions via --extra-config-opt. However, if you do this, various tests that print state about loaded extensions fail. This commit teaches the test harness to recognize when custom extensions are loaded so that tests can use feature sniffing to conditionalize tests based on that. Differential Revision: https://phab.mercurial-scm.org/D3039

simplestorerepo: avoid shadowing dict in list comprehension over dict Caught by pyflakes. Differential Revision: https://phab.mercurial-scm.org/D3077

narrow: pass node into revlog.revision() This is one of the few (possibly only) places where we pass an int in for filelogs. Other revlogs (notably changelog) are very heavy on int usage. But filelogs are surprisingly node centric. I'd like to formalize the interface around the use of nodes (at least for filelogs). So let's switch to a node. We can't inline revlog.node() because of a check-code rule. I think that rule is suspect. But it may be for performance reasons with changelog code. I'd rather not touch it at this time. Differential Revision: https://phab.mercurial-scm.org/D3043

changegroup: remove "revlog" from error message The previous message leaked an implementation detail. Differential Revision: https://phab.mercurial-scm.org/D3041

tests: conditionalize tests based on presence of revlogs for files ~85 tests don't like our non-revlog file store for various reasons. This commit introduces hghave functionality for declaring and querying repository features. By default, we assume repositories have revlog-based file storage. But if the HGREPOFEATURES environment variable is set, we can override the default set of repository features. If you run the test harness with our simplestorerepo extension and an environment variable set to the proper value, you can override the hghave defaults to agree with simplestorerepo's version of reality. Various tests have been modified so behavior dependent on revlog-based file storage is marked as such. This fixes a handful of test failures with our custom file storage extension. But dozens remain. The point of this commit is to demonstrate how tests will need to be modified to account for custom storage implementations. TBH, I'm not convinced hghave is the proper layer for repository feature detection. I /think/ we'll eventually want something in run-tests.py itself. But that would require inventing a new primitive in the test harness. This is all very alpha at the moment. So I think hghave is an acceptable place to hang this feature detection. I think the right time to be thinking about integrating this into run-tests.py is *after* we have a stable alternate storage implementation in core. For now, let's try to make progress towards the idea of an alternate storage backend. Differential Revision: https://phab.mercurial-scm.org/D3030