Added tag 6.0.1 for changeset 5ef112a6eb87

pkg: prepare release 6.0.1

debian: finalize 6.0.0 entry

readme: fix 6.0.0 release date It was March, not February.

merge with future 6.0.1 Nothing special to report

merge with future 6.0.1 Nothing special to report

merge with future 6.0.1 Nothing special to report

checkheads: update tests to match the one in core These test now exists in core, so we update the evolve version.

serveronly: fix reposetup The local 'reposetup' function was shadowing the extension helper one. We add a test for obshashrange using 'serveronly' since this is the item that made use discover the issue.

extension: simplify the extensions helper hierarchy If one mode depends on the other, its extensions helper is merged.

checkheads: do not overwrite code for Mercurial 4.2 and above The fix has been ported to Mercurial core as c6cb21ddf74a.

legacy: fix debugrecordpruneparents to call obsstore.create() with keywords It appears the API was changed twice in Mercurial at - 570f87422f54 "obsstore: add an explicit `date` argument to obsstore.create" - adb3798dce49 "obsstore: add a `parents` argument to obsstore.create" and metadata would be changed to a list of (key, value) pairs. Convert it back to a dict as expected by create().

template: adapt to new showlist() API introduced by hg e5eab0fe69ee

template: pass all mapping data to showlist() Otherwise a keyword depending on repo or ctx couldn't be rendered.

make: merge recipes for help

make: fix indent of ifeq-endif ifeq() can't be a recipe.

tests: update test to match upstreamable version Name have been clarified, documentation has been updated and some test-case have been updated to match the intended test.

tests: fix directory names in exchange-D4 test The test is based on another one and the directory name had not been updated.

tests: fix directory names in exchange-D3 test The test is based on another one and the directory name had not been updated.

merge back with default

Added tag 6.0.0 for changeset 165ad227993d

packaging: prepare version 6.0.0

merged with future 6.0 No output changed.

test-compat-hg-3.9: merge with future 6.0

merge with future 6.0.0

merge with default We are getting close to cutting a 6.0.0

readme: mention the fix for issue4354

checkheads: add a small debug message in case were we give up fast When node is unknown we assume it will stay. Yet, we might have markers to it that are going to be pushed. However, we do not have branch (ancestors) information unless we are very lucky an all of them are pruned. So for now we do not do anything assuming this will be rare. We still add a small debug message to help detecting such situation in the future.

checkheahds: switch algorithm to use pushed markers instead We now checks if markers involved in the push are relevant to nodes in the branch we try to replace. The approach is simpler and more robust. A test showing the limitation of the previous approach is added.

checkheads: add test where the rewrite of the other branch is not direct This will help testing that our logic is properly transitive.

check-heads: add tests about old heads indirectly pruned

checkheads: add more complexe case where a branch is split on multiple ones We extend case A-6 and A-7 with partial counterpart. These case are interesting because some of the partial pushing will (rightfully) works and some other won't.

checkheads: add a test of partially pushing a branch spread on multiple other If a branch is fully obsolete but is result are spread on multiple branch, pushing only one of them should detect we create new branches.

checkheads-tests: add missing parents recording for prune markers It is a bit too easy to forget about theses :/ If they are missing, the markers are not going to be exchanged on push.

checkheads: add some extra tests about "partial push" This adds a couple of test that checks that the head replacement code is properly ignored replacement not relevant to the push.

checkheads: handle partial obsolescence We now properly detects situations were only parts of the remote branch is obsoleted. To do so, we process children in the branch recursively to see if they will be obsolete. The current code has some trouble when the remote branch in unknown locally, or when the prune happened on a successors that is not relevant to the push. These case will be handled later. The processing code is becoming more and more complex, a lighter approach would be to check for the obsolescence markers that are relevant to the pushed set, but I prefer to stick with the current approach until more test cases are written.

test: force a push in inhibit's test Our checkheads detection code is becoming better and will prevent that push. As we do not care about this for inhibit, we simply force the push.

checkheads: basic handling of pruned heads (and associated tests) We now detect that heads was pruned and stop warning about it. Note that this has the same shortcoming as the existing code and only looks at the heads.

checkheads: give up on processing locally unknown changeset There are too many issue with locally unknown changesets, we ignore them for now while we get the core feature of the detection working.

checkheads: import our own copy of the checkheads code I expect enough change and experimental will be made that is it worthwhile having them done in evolution close to the rest of the exchange tests make sense.

compat: work around some filecache bug in 3.8 We are still compatible with this version.

obshashrange: have an half descent wireprotocol command The previous implementation was extremely hacky. The new version is based on the other discovery function and work!

obshashrange: improve message issued during discovery This is a minor new message that help to understand what is going on.

obshashrange: introduce basic sqlite caching Same as for stablerange, this is far from perfect but already a win. The cache is currently extremely volatile, but that will still be a win when doing multiple consecutive request during discovery. Better cache invalidation will happens "in the future".

stablerange: warm cache before using it server side We make sure the cache is fully up to date before starting to use it. Updating all value is more efficient and this give us a single point where we update and write on disk. Hopefully the cache have been kept up to date as we go anyway.

stablerange: warm cache before using it in findrangemissing We make sure the cache is fully up to date before starting to use it. Updating all value is more efficient and this give us a single point where we update and write on disk. Hopefully the cache have been kept up to date as we go anyway.

stablerange: warm cache on transaction (if obshashrange is enabled) If we plan to use it (obshashrange is enabled) we better keep it up to date. If a transaction adds node, we update the cache (this should also update the on disk version).

stablerange: introduce ondisk caching through sqlite There is many short cut and limitation with this first version of a cache but this allow use to envision some actual usage of the stablerange thingy so let us got for it.

stablerange: drop the cache on 'destroyed' if the repository have been strip, the cache is not usable as is. We could be smarter in the invalidation but that is a prototype anyway. G: changed hgext3rd/evolve/stablerange.py

stablerange: support loading the cache iteratively We record how far we loaded so that we can resume from this point.

stablerange: add some basic documentation about the cache

stablerange: warmup all upto a revision Let us start doing more systemic warming of the cache before we start writing things out. This prepare on disk caching.

debugstablerange: add a --verify flag to the command This should help us finding bugs.

stablerange: add a proper debugstablerange commands This commands allows to inspect the standard stable range of a range. That should come handy.

debugobshashrange: add a --subranges option We stop displaying -everything- by default, since is is usually very large. This will help getting better timing when measuring cache effect too, since we won't need to dig out deep cache value that real life usage would not touch.

debug: rename 'debugstablerange' to 'debugobshashrange' The command is more about the 'obshashrange' computation.

debugstablerange: improve output spacing On repo with a descent amount of changeset the number where overflowing in all directions. We give use more room now.

subranges: add a utility function to set the cache This is preparing on disk persistence for the value in this cache.

subranges: add a utility function to access the cache This is preparing on disk persistence for the value in this cache.

depth: add a utility function to set the cache This is preparing on disk persistence for the value in this cache.

depth: add a utility function to access the cache This is preparing on disk persistence for the value in this cache.

stablerange: add warming of the subrange Note that this means we build standard stable subrange for all changesets in the repository this is significantly more than what we were computing before and result is significantly more ranges being computed.

stablerange: fix merge slicing when range has multiple roots The first element in the bottom set is not necessarly the one with the lowest revision. We now properly compute and use the minimum value.

stablerange: small style fix