test: update output to 02fdb8c018aa Now that we have directaccess in core, we get a new warning message when updating to a hidden changeset. Update the tests. CORE-TEST-OUTPUT-UPDATE: 02fdb8c018aa

test: update output to 9b3f95d9783d The unstable graph nodes are now shown with the character "*", update the test outputs. CORE-TEST-OUTPUT-UPDATE: 9b3f95d9783d

stablesort: use parent filtering in a place we forgot to Freak merge striked again.

obshashrange: add a progressbar to upgrade This section is the slowest, have some progress idea would be useful.

stablerange: add an sql index on subranges id too This should speed up query that find super ranges.

obshashrange: less brutal reset when receiving markers on existing node We now target the affected ranges only. The implementation is still slow but that should be better than what we had before.

obshashrange: update the cache updating logic Use the more modern option when available. (Same as the other caches).

stablerange: cleanup the update logic

stablesort: cleanup the update logic

firstmergecache: cleanup the update logic

depthcache: cleanup the update logic

changelog: add an entry about the obshashrange changes

stablerange: be more cautious when deleting the sql connection This triggered some crash in further development. This also match what is done elsewhere with this attribute.

stablerange: clarify sql transaction logic This should help concurrent access.

stablerange: use mergepoint based algorithm for the official stable range Changing the official stable range will impact all users of the infrastructure. We update version number of the cache file and discovery methods to clarify this. We do no keep compatibility with the old method over the wire. The new algorithm is much better and keeping compat is more work than we have time for right now.

stablerange: explicitly create a stablerange entry for branchpoint method We are about to change the default.

stablerange: have a mergepoint based sql backed class Everything is so generic that getting a class is 3 line of codes.

stablerange: introduce a sql backed version of the generic on disk cache This is getting use close to actually using the new sorting and algorithm for real.

stablerange: add a base class for on disk stored stablerange class

stablesort: use on disk cache for test

caches: factorise the cache warming check The old conditional was duplicated and hard to read. We factorise everything into the `utility` module.

stablerange: use repo-carried stablesortcache That one is common to all and disk persisted

stablesort: expose the cache through the repository Let have a unique instance, keep it warm and accessible.

stablesort: implement an ondisk cache Persisting the cache on disk will be important for large repositories.

stablesort: realign a misaligned continue We should make a better use of the jump cache now.

stablesort: remove some dead code This closure is no longer in use.

stablesort: abstract all cache access This prepare an on disk version of the cache

stablerange: use first merge cache to skip over linear section If we are to skip over a large section of the range, skipping everything until the first merge seems like a good idea.

stablerange: add a new 'firstmerge' cache This cache store the first merge ancestors of a changesets. This is useful to avoid iteration over the changelog when building stablerange.

stablerange: drop unused `until` utility We no longer needs this function.

stablerange: use cached size data instead of walking the graph Less iteration is better.

stablesort: record previous segment size in the jump That was, we can skip over a full jump without walking it. We'll make use of this in the next changeset.

stablesort: move jump recording inside the exclusive function This will allow use to record to cache size of segment in a later changeset. If the exclusive set is empty, we need to record it outside that function.

stablerange: compute jump size after jump retrieval only This prepares the caching of jump sizes.

stablesort: warm jump cache more efficiently We no longer for a full depth iteration for all request: - we exit early for non-merge, - for merge, we only iterate over the exclusive area.

stablesort: use a regular dict for jumps This will help knowing what revision we have already queried or not.

stablerange: use the jump information for faster iteration Instead of doing a full iteration over the exclusive set, we compare the jump information instead. This perform the same kind of logic than before but will allow for much faster iteration once all the caches are in place.

stablesort: expose the jumps sequence to other code The stable range needs it to build exclusive subrange efficiently.

stablesort: use 'depth' in mergepoint tie breaker The parents with the most depth will is considered lower. It has a couple of advantages. 1) the more shallow parent probably have less exclusive revision, 2) it makes Oedipus merge behave like close to the linear case,

stablesort: rework jump gathering The old code was buggy in some case, the new code give the same result as the 'headstart' version.

stablesort: stop recording jump type There are no mature user of this "jump type" data and the current implementation is known to be buggy. So we drop the logic for now. This will make on disk storage simpler. The data will be reintroduced later

stablesort: pass a jump recording function instead of a list This seems cleaner to abstract the underlying storage to the lower level. This also makes use more flexible about jump detection.

stablesort: minor indent fix

stablesort: clarify subcall to the exclusive side Before doing deeper rework of this logic, we tackle the simplest parts.

docgraph: update test output with new output

stablesort: record, cache and reuse jump Iterating below a merge means two things: 1) iterate over the part exclusive to the higher parents, 2) iterate from the lower parents. While iterating on the exclusive part, there will be case were we just go the next natural parent, and case were we'll have to "jump" to another revision. If we record all point this "jump" happens and their target, we can easily reproduce the iteration in the future. With that information we can iterate over the exclusive part of the merge without having to compute it entirely. In addition we store the reason of the jump. This will help the stable range processing later.

stablesort: fix head start computation The recursion was wrong and provided wrong result. As a side effect, this seems to hint that `stablesort_mergepoint_bounded` is not giving the right result for complex set.

stablesort: avoid attempting to sort a tuple This seems silly.

stablerange: use the filterparents utility

stablesort: use the filtered parents utility

depthcache: use parents filter in depth cache

parents: add a utility to filter parents There is various strange case of merge out there that needs to be handled. We add an utility function to handle them all.

stablerange: abstract the bit able to store cache into sql The part about actually storing the range is independent of the algorithm, so we should extract this before using it for the next iteration.

stablerange: split pure algorithm part from the on disk cache The stable cache file is getting long, we split the logic about keeping data on disk into a dedicated file.

stablerange: add an assert to detect buggy range Nothing can be negative in there, we add an assert to make sure it is so.

stablerange: warn cache for all relevant ancestors range Warming cache in the right order will prevent recursion to happens and unlock usage on large repository.

stablesort: move parent range computation into its own method Now that we have running code, we'll need to avoid too deep recursion. We extract the piece dealing with the parent range before we write more code to warm it.

stablerange: drop the basic inheritance from the 'mergepoint' version All necessary bits are implemented now (except for warmup which we explicitly bypass for now).

stablerange: cache known subrange at the stablerangecached level That way, the 'stablerange_mergepoint' class also benefit from it.

stablerange: use sort cache to build 'mergepoint' information Using the walk cache gives use a better complexity we need to scale. There are further improvement we could make, but this is a good first step.

stablesort: make the iteration from head available to all This will be useful for the stablerange code to work properly.

depth: fix compare mode for `debugdepth` The compare mode was broken for silly reasons.

memfilectx: changectx argument is not mandatory As changectx argument is now mandatory for memfilectx, add a compatibility layer to pass it when necessary. The commit that made the parament mandatory in core is 8a0cac20a1ad

branching: merge stable into default

amend: fix a typo in amend help text related to the extract option s/extra/extract/

topic: fix compatibility with 4.3 A compatibility fixes ended up being overlooked, we are bringing it back into the main branch.

branching: merge stable back into default New version has been released, hooray.

packaging: mark stable change as bugfix dev version This help reduce confusion when installing non-tagged changeset.

Added tag 7.1.0 for changeset 06a3cb594956

packaging: prepare release 7.1.0

branching: revert "stable" change into default The expected output for "default" is still the same.

test-compat: merge mercurial-4.2 into mercurial-4.1

test-compat: merge mercurial-4.3 into mercurial-4.2

test-compat: merge stable into mercurial-4.3

test: backed out test change from changeset a18ca224e812 The related mercurial changeset, ad5f2b923b0d, is not in the stable branch yet.

test: backed out output change from 85ab7d2d9fd6 Mercurial core default branch does not have the related changeset yet (a7e49a5b3e6f).

branching: merge with stable

obsnote: warn if user try to store a note in obsmarker on an older hg Support to store a note in obsmarker is from hg>=4.4. We have added notes support to all the evolve commands but we do support versions which don't support storing note in obsmarker. Warn if user tries to store a note in older hg.

topic: use 'hookargs' over 'tr.changes' for flow control The 'tr.changes' attribute do not exists until 4.2.

topic: move function wrapping from reposetup to uisetup Having the function un reposetup means they get wrapped over and over again for long lived process.

test: publish the root of the repo in flow reject-untopiced The lack of default branch confuses older version

genericcaches: handle the lack of util.timer in 4.1 We do the same trick as usual.

topics: fix `hg stack` in case of split This patch fixes the behaviour of hg stack which throws an error in some cases when there are multiple successors. The case of divergence is not handled yet.

tests: add a test showing traceback on `hg stack` in case of split The traceback will be fixed in the next patch.

branching: merge stable into default

test-compat: merge mercurial-4.2 into mercurial-4.1

test-compat: merge mercurial-4.3 into mercurial-4.2

test-compat: merge stable into mercurial-4.3

changelog: add an entry for the split+branch fix The world needs to know.

branching: merge with stable

split: force the branch to fix the split bug Also restore it after the split

split: add a test demonstrating that split doesn't take the right branch Also add a test to check that the dirstate is in the right state in case the user abort the split.

stablerange: compute the subrange closure on an unfiltered repository This avoid various overhead from filtering.

stablesort: write a flat version of the algorithm This new version never needs to iterate over the full repository even when merge are encountered. Having the algorithm flat also prepare caching works since the iteration sequence can we expressed with a couple of flat loop.

stablesort: simplify processing of non-merge changesets As long as a changeset as only one parent, the next element in the sort (starting from the head) has to be that parent. We detect and take advantage of that shortcut in the non-merge case.

stablesort: extract a '_revsfrom' method Walking from the revision is usually simple unless the revision is a merge. Having this walking logic isolated will help us refine it.