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.

stablerange: use the new cache object in the 'mergepoint' version Every improvement to the cache should reflect on the stable range from there. Since we no longer use the basic sort function, we can simplify the inheritance by dropping one layer.

stablesort: introduce a cache object The object is not caching anything yet, but the API are getting into place.

stablesort: start implementing more advanced version of headstart sorting Now that we can validate the sort with a basic implementation, we can start implementing a version that will support caching and other goodies.

stablerange: make use of the limit argument in 'mergepoint' This will eventually avoid doing full iteration on ancestors of the head when retrieving the range content.

stablerange: introduce a smarte version of stablerange for 'mergepoint' This implementation will using caching and smarter algorithm based on these cache. For now it inherit most of it code from the dummy version for convenience. The inheritance to the dummy version should be dropped eventually.

stablerange: introduce an intermediary abstract class for caching The 'branchpoint' and 'mergepoint' based stablerange class will need similar cache, we introduce an abstract class to take care of that first.

stablerange: introduce a basic-mergepoint method This method use the new 'mergepoint' based stable sorting. It is expected to be eventually better than branch point to stable range: more stable, easier to cache, etc. Having a basic implementation will allow use to validate more advanced implementation.

stablesort: add a new test to check for fully independant branches Apparently, this was not covered.

stablesort: add a --limit argument This will be useful when using stable sort within stable range.

stablesort: introduce a mergepoint based method focused on head The things we needs for stable range is head centric. So we simplify the issue by focussing on head.

stablesort: introduce a "mergepoint" method The mergepoint method decide order from merge. This allow to directly reuse a the full sort of one of the parent, and should simplify caching.

stablerange: fallback to a more naive approach to find subrange As suspected, using "bheads" was bit good enough in some case and we have to fall back to the approach used in "basic". On the evolve repo (about 3K changeset) this approach is about 60% slower than the previous (wrong) code.

stablebranch: avoid overlap between subrange Subrange overlap make things more complicated and less efficient. We fix the computation done in the "cached" version of the stablerange cache. This bring things in line with the result produced by the basic version. Since we already bumped the format version since the last release, I don't things we need to do anything else.

stablerange: introduce an 'basicstablerange' This class hold all the basic of stable range but the part specific to the sorting. This allow to clearly express what is expected from each method and to generate tests output to be validated against the more complex implementation. While writing this, we spotted a bug in the current stable range implementation. Fix coming.

stablerange: extract the core API into a 'stablerangecore' class To clarify what the code is doing without all the caching and algorithmic improvement, we extract a core class that highlight the basic API expected from the class.

stable-branch: setup tests to use a specific method by default This will make future test simpler.

stablerange: rework the debug command to allow for multiple method Similar to what we did for the other debug command related to sorting, we prepare for the arrival of multiple method to produce the result (including simple implementation that are easy to read but do not scale).

deptcache: make sure we warm the dept cache before warming the obsdiscovery The depthcache need to a warmed a bit more agressively

stablesort: add a 'method' argument to the debugstablesort command Let start experimenting with other way to do stable sorting.

stablesort: rename function to stablesort_branchpoint We are about to test different approach to stable sorting. We clarify that the existing method is sorting from branch points.

stablerange: update the filename to avoid cache confusion The schema validation seems to not work as well as intended, we update the file name to make sure there will be no confusion.

stablesort: extract in its own module We are going to introduce variants, cache and more complex logic, we move that in its own repository beforehand.

compat: in depth cache, only use cachevfs when available We support older version without the new vfs.

depthcache: issue a progress bar when loading the depth cache The operation can be in the minute order of magnitude of some larger repository. We better keep the user entertain when he wait.

depthcache: move to a dedicated object and storage The SQL cache was overkill and fragile. We move to a dedicated storage using the new generic class.

cache: adds debug details about what the content of the update Having more data in debug is good, we add a small method to help providing them. This code was headed for core during the 4.3 cycle but never made it there. So we starts with a copy in the evolve repository.

cache: introduce a changelogsourcebase class This abstract class will help code that need a cache tracking the changelog content (eg: the branchmap cache). The cache key used is the same as what the branchmap uses. This code was headed for core during the 4.3 cycle but never made it there. So we starts with a copy in the evolve repository.

cache: introduce an abstract class for cache we can upgrade incrementally Right now each class implements their own mechanism for validation, and update. We start introducing abstract class to ultimately allow more unification of the cache code. The end goal of this series is to introduce a cache for some obsolescence property, not to actually implement the cache. However, taking advantage of adding a new cache to introduce the abstract class seems like a win. This code was headed for core during the 4.3 cycle but never made it there. So we starts with a copy in the evolve repository.

depth: basic debugdepth implementation and test This will come very handy to validate more advanced implementation later.

topics: add a config to reject draft changeset without topic on a server This patch adds a new config option experimental.topic-mode.server which if sets to True, the server won't accept any draft changeset without topic on it. In case both `experimental.topic-mode.server` and `experimental.topic.publish-bare-branch` are set to True, the enforce-topic one is respected. Tests are added for it. The CHANGELOG file is also updated mentioning about the config option.

test: update output to ad5f2b923b0d A new bundle2 capabilities have been added (related to bookmark). So we have to update the test output. CORE-TEST-OUTPUT-UPDATE: ad5f2b923b0d

touch: shorten touch's docstring to make it fit into a one line This make it show completely (untruncated) in `hg help -e evolve`. This follows up on fed946edc293 where the docstring got unwrap for that purpose and thus made the line length exceed 80 columns.

branching: merge with stable

help: promote "amend" to important command Recent change to what command we advertise as "basic". It turn out "amend" was not part of one of them. Since "amend" is one of the core command of a rewriting workflow, we promote it to "basic command".

help: fix output for `hg help -e evolve` wrt 'touch' command Currently, when running `hg help -e evolve`, the output looks like this on my screen: touch create successors that are identical to their predecessors except With this change, it looks like this: touch create successors that are identical to their predecessors except for the changeset ID

help: remove a few commands from `hg` (no args) command list According to `hg help -e evolve`, the following commands come from the evolve extension: amend evolve fold metaedit next obslog pdiff previous prune pstatus split touch uncommit If one runs `hg` without arguments, commands that are prefixed with a ^ character are shown. From the previous list, this includes: evolve fold metaedit next previous prune split touch uncommit It feels several of these commands are not "basic commands" that someone who has never used hg before might care about. They probably also do not come close to passing the "toothbrush test": things that users are likely to use every day. This commit removes these items from the list: metaedit, touch, uncommit This means the following are kept: evolve fold next previous prune split

typos: fix typos in several locations A user at Google attempted to fix our local copy because they had noticed a typo (accross instead of across), but this will just get overwritten on our next import. This commit fixes that case and a few others that my editor found. Most of the typos were in comments, but user-visible output is changed in a few cases: - accross -> across - splitted -> split - ambigious -> ambiguous - evolvestte -> evolvestate (this is in a ui.debug, so not often seen) There is another typo that I wanted to fix, but didn't: 'supercede' is spelled 'superseed' in a few locations. I believe this is only internal to the extension, instead of being user-visible, so while it could probably be fixed easily, I wasn't 100% sure it didn't end up in a file on disk or something and might cause problems, so I left it alone.

topic: use more protective code to access current topic There are some code path where the operation is not properly initialized and lack the new attributes. While the lack of initialization, is suspicious and I've not be able to pin point case where this happens. Currently the code crash when it encounter this situation. So we make the code more resistant to this case to prevent bad user experience.

topic: use more protective code to access publishing code There are some code path where the operation is not properly initialized and lack the new attributes. While the lack of initialization, is suspicious and I've not be able to pin point case where this happens. Currently the code crash when it encounter this situation. So we make the code more resistant to this case to prevent bad user experience.

typos: fix typos in several locations A user at Google attempted to fix our local copy because they had noticed a typo (accross instead of across), but this will just get overwritten on our next import. This commit fixes that case and a few others that my editor found. Most of the typos were in comments, but user-visible output is changed in a few cases: - accross -> across - splitted -> split - ambigious -> ambiguous - evolvestte -> evolvestate (this is in a ui.debug, so not often seen) There is another typo that I wanted to fix, but didn't: 'supercede' is spelled 'superseed' in a few locations. I believe this is only internal to the extension, instead of being user-visible, so while it could probably be fixed easily, I wasn't 100% sure it didn't end up in a file on disk or something and might cause problems, so I left it alone.

tests: add a test for newline in obsnote

obsnote: don't add '' to note while showing it in obslog

obsnote: add an entry in CHANGELOG about it

amend: add support for storing a note in obsmarker

uncommit: add support for storing a note in obsmarker

fold: add support for storing a note in obsmarker

metaedit: add support for storing a note in obsmarker

prune: add support for storing a note in obsmarker