Jun Wu <quark@fb.com> [Thu, 06 Apr 2017 17:24:36 -0700] rev 31833
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.
Jun Wu <quark@fb.com> [Thu, 06 Apr 2017 17:23:20 -0700] rev 31832
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.
Jun Wu <quark@fb.com> [Thu, 06 Apr 2017 17:01:58 -0700] rev 31831
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.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 05 Apr 2017 23:44:22 -0400] rev 31830
tests: add per-line output conditionals for Windows
Matt Harbison <matt_harbison@yahoo.com> [Wed, 05 Apr 2017 23:17:27 -0400] rev 31829
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.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 05 Apr 2017 22:59:44 -0400] rev 31828
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.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 05 Apr 2017 22:00:33 -0400] rev 31827
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.
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 07 Apr 2017 13:45:33 +0530] rev 31826
py3: use pycompat.byteskwargs() to convert opts to bytes
We have converted opts to unicodes before passing them.
Jun Wu <quark@fb.com> [Thu, 06 Apr 2017 22:10:46 -0700] rev 31825
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
Jun Wu <quark@fb.com> [Thu, 06 Apr 2017 22:08:23 -0700] rev 31824
check-code: use "-" to specify a list of files from stdin
This will be used by the next patch.