Summary:
Move the strip extension to core. Rename the command to `hg debugstrip` as it
is not intended for use by users. Users should use `hg hide` instead.
Reviewed By: quark-zju
Differential Revision: D14185822
fbshipit-source-id: ef096488cb94b72a7bb79f5bf153c064e0555b34
Summary:
Our codebase is already unfriendly to 3rd-party extensions and we will likely
break the compatibility as part of revisising / replacing components in Rust
anyway. So just stop supporting `--config extensions.3rdpartyfoo=`.
Note `--config extensions.3rdpartyfoo=foo.py` still works.
This also makes `ImportError` more meaningful. Previously, when `hgext.foo`
imports `bar` which does not exist, the error is "cannot import foo", while
it should really be "cannot import bar". That is because extensions.py falls
back to import `hgext3rd.foo`, and `foo`. Now extensions.py only tries
`hgext.foo` and will suface the right error.
Reviewed By: DurhamG
Differential Revision: D13440400
fbshipit-source-id: c659f6d05abbc0d09f2811f36c0dc31e49491f19
Summary: Mostly empty lines removed and added. A few bugfixes on excessive line splitting.
Reviewed By: quark-zju
Differential Revision: D8199128
fbshipit-source-id: 90c1616061bfd7cfbba0b75f03f89683340374d5
We replace 'experimental.stabilization=all' by 'experimental.evolution=true'
as we will extract individual config in their own config in later patches.
Differential Revision: https://phab.mercurial-scm.org/D1148
Now that we have all tracking in place, the data in `tr.changes['phases']`
dictionary should be correct and we should test it.
It is a bit late in the cycle to discuss to add any public API (eg: hooks)
that expose the data to the user, so we just add a small test extension
displaying the data. It is enabled for the phases tests.
New output have been manually checked for consistency.
Add a 'predecessors' template that returns the list of all closest known
predecessors for a changectx. The elements of the list are row changectx node id
formatted by default as short nodes.
The "closest predecessors" are the first locally known revisions encountered
while, walking predecessors markers. For example:
1) If a (A, (B)) markers exists and both A and B are locally known A is a
closest predecessors of B.
2) If a (A, (B)) and (B, (C)) markers exists and only A and C are known
locally, A will be the closest precursors of C.
This logic respect repository filtering. So hidden revision will be skipped by
this logic unless --hidden is specified. Since we only display the visible
predecessors, this template will not display anything in most case. It makes a
good candidate for inclusion in the default log output.
I added a new test-file for testing the precursors in various scenarios. This
test file will also be used for the successors template.
A new "obsutil" module has been added to start gathering utility function
outside of the large obsolete.py module.
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.
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'"
Mercurial checks for the introduction of new heads on push. Evolution comes
into play to detect if existing branches on the server are being replaced by
some of the new one we push.
The current code for this logic is very basic (eg: issue4354) and was poorly
tested. We have a better implementation coming in the evolve extension fixing
these issues and with more serious tests coverage. In the process of upstreaming
this improved logic, we start with adding the test case that are already passing
with the current implementation. Once they are all in, we'll upstream the better
implementation and the extra test case.
This changeset introduce the common setup script used by these 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
