Thu, 06 Apr 2017 17:23:20 -0700 test-flagprocessor: use changegroup3 in bundle2
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.
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.
Wed, 05 Apr 2017 22:59:44 -0400 test-run-tests: pad the failure test to preserve the run order
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.
Wed, 05 Apr 2017 22:00:33 -0400 run-tests: prevent a (glob) declaration from reordering (?) lines
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.
Fri, 07 Apr 2017 13:45:33 +0530 py3: use pycompat.byteskwargs() to convert opts to bytes
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip