test-flagprocessor: add tests about bundlerepo
This shows flag processor is broken with a bundle repo.
The test creates non-liner history to exercise code path where the
deltaparent cannot be reused.
test-flagprocessor: use changegroup3 in bundle2
This will force "hg bundle" to use changegroup3 in the test. It is
important since only changegroup3 preserves revlog flags.
bundle: allow bundle command to use changegroup3 in tests
Since bundle2 writes changegroup version, we can just reuse the bundle2
format for changegroup3.
This won't enable the bundle command to write changegroup3 in the wild,
since exchange.parsebundlespec only returns changegroup2. It unlocks tests
to override exchange.parsebundlespec and get "hg bundle" write changegroup3.
run-tests: support per-line conditional output in tests
Duplicating entire tests just because the output is different is both error
prone and can make the tests harder to read. This harnesses the existing '(?)'
infrastructure, both to improve readability, and because it seemed like the path
of least resistance.
The form is:
$ test_cmd
output (hghave-feature !) # required if hghave.has_feature(), else optional
out2 (no-hghave-feature2 !) # req if not hghave.has_feature2(), else optional
I originally extended the '(?)' syntax. For example, this:
2 r4/.hg/cache/checkisexec (execbit ?)
pretty naturally reads as "checkisexec, if execbit". In some ways though, this
inverts the meaning of '?'. For '(?)', the line is purely optional. In the
example, it is mandatory iff execbit. Otherwise, it is carried forward as
optional, to preserve the test output. I tried it the other way, (listing
'no-exec' in the example), but that is too confusing to read. Kostia suggested
using '!', and that seems fine.
test-run-tests: pad the failure test to preserve the run order
Test size seems to dictate the order in which the tests are run, and the next
patch will add to test-success.t. Similar to
c0cecc153d25.