test-flagprocessor: remove unnecessary greps The "2>&1 | egrep ..." code is used for removing uninteresting parts from tracebacks. Now the test does not dump tracebacks, they can be removed.

bundlerepo: use raw revision in revdiff() This is similar to "revlog: use raw revisions in revdiff". revdiff() generates raw text used in revlog directly. This makes test-flagprocessor.t happy.

bundlerepo: fix raw handling in revision() Similar to fixes in revlog.py, this patch uses "rawtext" to explicitly label contents expected to be raw, and makes sure content stored in _cache is raw text. Now test-flagprocessor.t points us to another issue.

bundlerepo: build revlog index with flags This fixes bundlerevlog.flags(rev) for any revisions provided by the bundle. Now test-flagprocessor.t points us to another issue.

bundlerepo: make baserevision return raw text "baserevision" returns the text that will be used to apply deltas. Since deltas are against raw texts, "baserevision" should return raw text. Now test-flagprocessor.t points us to a new error.

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.

tests: add per-line output conditionals for Windows

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.

run-tests: prevent a (glob) declaration from reordering (?) lines Previously, if a series of optional output lines marked with '(?)' had a (glob) in one of the first lines, the output would be reordered such that it came last if none of the lines were output. The (re) declaration wasn't affected, which was helpful in figuring this out. There were no tests for '(re) (?)' so add that to make sure everything plays nice.

py3: use pycompat.byteskwargs() to convert opts to bytes We have converted opts to unicodes before passing them.

test-check-code: do not use xargs We have too many files, and passing them via arguments could cause strange errors on some platforms [1]. Since check-code.py can now take "-" and read file names from stdin, use it instead of xargs to avoid the argv size limit. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096346.html