Commit Graph

3 Commits

Author SHA1 Message Date
Pierre-Yves David
8d733e89bc strip: strip obsmarkers exclusive to the stripped changeset
This is it, `hg strip --rev X` will now also remove obsolescence markers
exclusive to X. Since a previous changeset, the obsmarkers has been backed up
in the strip backup bundle, so it is possible to restore them.

Note: stripping obsmarkers means the precursors of the stripped changeset might no
longer be obsolete after the strip.

Stripping changeset without obsmarkers can be useful when building test case. So
It is possible to disable the stripping of obsmarkers using the
'devel.strip-obsmarkers' config option.

Test change have been carefully validated.
2017-05-20 16:19:59 +02:00
Matt Harbison
dd6ac04d2c testlib: move the prune alias into a shell script for Windows
Cramming all of this directly into an alias doesn't play nicely on Windows.
Various test-exchange-obsmarkers-case-XX.t were failing with:

    abort: cannot select revision when creating marker

It turned out that inside debugcommands.debugobsolete(), the following differed
from Linux (where they were empty, at least in the case I debugged):

    'rev': ['.`;'],
    'template': "'{node}\\n'"
2017-04-16 00:29:38 -04:00
Pierre-Yves David
d2cfbf8afa 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
2017-04-10 16:40:40 +02:00