Thu, 06 Apr 2017 17:01:58 -0700 bundle: allow bundle command to use changegroup3 in tests
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.
Wed, 05 Apr 2017 23:44:22 -0400 tests: add per-line output conditionals for Windows
Matt Harbison <matt_harbison@yahoo.com> [Wed, 05 Apr 2017 23:44:22 -0400] rev 31830
tests: add per-line output conditionals for Windows
Wed, 05 Apr 2017 23:17:27 -0400 run-tests: support per-line conditional output in tests
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip