Commit Graph

3 Commits

Author SHA1 Message Date
Boris Feld
b989852f8f debugobsolete: also report the number of obsoleted changesets
This seems useful to have the number of obsoleted changesets when calling
debugobsolete.
2017-07-16 02:33:14 +02:00
Pierre-Yves David
5e97e55c0f obsolete: reports the number of local changeset obsoleted when unbundling
This is a first basic visible usage of the changes tracking in the transaction.
We adds a new function computing the pre-existing changesets obsoleted by a
transaction and a transaction call back displaying this information.

Example output:

  added 1 changesets with 1 changes to 1 files (+1 heads)
  3 new obsolescence markers
  obsoleted 1 changesets

The goal is to evolve the transaction summary into something bigger, gathering
existing output there and adding new useful one. This patch is a good first step
on this road. The new output is basic but give a user to the content of
tr.changes['obsmarkers'] and give an idea of the new options we haves. I expect
to revisit the message soon.

The caller recording the transaction summary should also be moved into a more
generic location but further refactoring is needed before it can happen.
2017-06-28 03:54:19 +02:00
Pierre-Yves David
08992fef29 obsolescence: add test case A-6 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 A6:

  new markers between changesets already known on both side

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:44:19 +02:00