Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:41:21 +0200] rev 31906
obsolescence: add test case A-1 for obsolescence markers exchange
About 3 years ago, in August 2014, the logic to select what markers to select on
push was ported from the evolve extension to Mercurial core. However, for some
unclear reasons, the tests for that logic were not ported alongside.
I realised it a couple of weeks ago while working on another push related issue.
I've made a clean up pass on the tests and they are now ready to integrate the
core test suite. This series of changesets do not change any logic. I just adds
test for logic that has been around for about 10 versions of Mercurial.
They are a patch for each test case. It makes it easier to review and postpone
one with documentation issues without rejecting the wholes series.
This patch introduce case A-1: pushing a single head
Each test case comes it in own test file. It help parallelism and does not
introduce a significant overhead from having a single unified giant test file.
Here are timing to support this claim.
# Multiple test files version:
# run-tests.py --local -j 1 test-exchange-*.t
53.40s user 6.82s system 85% cpu 1:10.76 total
52.79s user 6.97s system 85% cpu 1:09.97 total
52.94s user 6.82s system 85% cpu 1:09.69 total
# Single test file version:
# run-tests.py --local -j 1 test-exchange-obsmarkers.t
52.97s user 6.85s system 85% cpu 1:10.10 total
52.64s user 6.79s system 85% cpu 1:09.63 total
53.70s user 7.00s system 85% cpu 1:11.17 total
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 16:40:40 +0200] rev 31905
obsolescence: add setup script for obsolescence markers exchange tests
About 3 years ago, in August 2014, the logic to select what markers to select on
push was ported from the evolve extension to Mercurial core. However, for some
unclear reasons, the tests for that logic were not ported alongside.
I realised it a couple of weeks ago while working on another push related issue.
I've made a clean up pass on the tests and they are now ready to integrate the
core test suite. This series of changesets do not change any logic. I just adds
test for logic that has been around for about 10 versions of Mercurial.
They are a patch for each test case. It makes it easier to review and postpone
one with documentation issues without rejecting the wholes series.
This patch introduce the common script that setup the basic environment for the
test cases. Once this script is in. We can accept the other patches in any
order.
Each test case comes it in own test file. It help parallelism and does not
introduce a significant overhead from having a single unified giant test file.
Here are timing to support this claim.
# Multiple test files version:
# run-tests.py --local -j 1 test-exchange-*.t
53.40s user 6.82s system 85% cpu 1:10.76 total
52.79s user 6.97s system 85% cpu 1:09.97 total
52.94s user 6.82s system 85% cpu 1:09.69 total
# Single test file version:
# run-tests.py --local -j 1 test-exchange-obsmarkers.t
52.97s user 6.85s system 85% cpu 1:10.10 total
52.64s user 6.79s system 85% cpu 1:09.63 total
53.70s user 7.00s system 85% cpu 1:11.17 total
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 11 Apr 2017 00:03:11 +0200] rev 31904
upgrade: simplify the "origin" dispatch in dry run
We could compute the final set we need directly.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 23:11:45 +0200] rev 31903
upgrade: use 'improvement' object for action too
This simplify multiple pieces of code. For now we restrict this upgrade to the
top level function to keep this patch simple.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 23:10:03 +0200] rev 31902
upgrade: implement equality for 'improvement' object
Through the code, we use a mix of 'improvement' object and string. Having a
single type would be simpler. For this we need the object to be comparable.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 22:15:17 +0200] rev 31901
upgrade: simplify some of the initial dispatch for dry run
Since we already have the list of deficiencies, we can use it directly.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 07 Apr 2017 18:39:27 +0200] rev 31900
upgrade: simplify 'determineactions'
Since we only takes 'deficiencies', we can simplify the function and clarify its
arguments.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 11 Apr 2017 23:46:16 +0200] rev 31899
upgrade: filter optimizations outside of 'determineactions'
This sounds like higher level logic to process arguments.
Moving it out of 'determineactions' will allow passing only deficiencies to the
function. Then, in a future changeset, we will remove dispatch on "improvement
type" within the function. See next changeset for details.