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

merge-slicing: introduce and use "inheritance point" for merge The first part of the stable sorted list of revision of a merge will shared with the one of others. This means we can reuse subranges computed from that point to compute some of the subranges from the merge. That point is latest point in the stable sorted list where the depth of the revisions match its index (that means all revision earlier in the stable sorted list are its ancestors, no dangling unrelated branches exists). This is a bit expensive to find since we have to walk all the revision, but being able to reuse subranges in all case (not just regular changesets) provide a massive speedup so the cost is worth it.

stablerange: rearrange the code picking subrange to warm Same logic, as the previous changesets, we prepare the code before adding merge support.

stablerange: rearrange the reusing logic to prepare to merge We'll soon be able to reuse some lower range when dealing with merge too. So we prepare the code for this in advance for clarity.

merge-slicing: explain an alternative implementation in a comments It has a better time complexity so a C implementation would likely out perform the current implementation

merge-slicing: use reachable roots to filter the various branches Reachable roots does what we want and have a quite fast C implementation.

merge-slicing: simplify various aspect of the code Especially the case were the bottom have single heads is not more efficiently handled.

stablerange: soon it will not provide any benefit and it gets in the way This was a bit strange and memory consuming anyway.

revsfromrange: reuse information from the stablesort We collaborate with the stablesort to store the order that led to a merge. That way, when we needs to retrieve revision from that merge we can reuse that order. We might need to filter to only retains ancestors of the merge we care about but skipping the stablesort safe a large amount of time.

stablesort: allow a callback to be triggered on merge Storing some information as we sort is going to be useful to avoid performing multiple sort while computing the stablerange.

minor simplification around rangelength

more explicite name in revsfromrange

stablerange: cache parents We happens to be doing and awful amount of parent call. We cache them locally for efficiency.

merge-slicing: avoid doing the same work twice We have already computed the list of revision in that bottom slice as 'hrevs' so we do not need to compute it a second time.

stablerange: fix a bug when a top slice ended on a merge Our "smart" detection of merge was buggy if the top slice ended on a merge. This is not fixed and tested.

slicesrangeat: stop double setting the revsinranges cache The cache should have already been filled by the logic warming the cache for the parent.

subranges: remove the recursivity of the call to isubranges(parentrange) We add some logic to ensure we'll have hot cache for the parent ranges when that matters, the cache is filled from ancestors to descendant to ensure this. The range are still 'created from descendant to ancestors to fill the revsfromrange cache since it important.

subranges: detach cache logic from computation logic Having both the logic around cache checking and setting makes is a bit harder to follow. In addition, this allow to gather the computation logic next to the other related function.

findmissingrange: properly queue new subrange for slicing The previous code was buggy and used the wrong variable leading to no extra slicing being performed to file the sample at the requested size.

findmissingrange: fix reversed value in debug output "oops"

stablecache: warmup on unfiltered repository We only looks at ancestors revision so filtering will not have any effect. This reduce overhead from the filtering.

stablerange: rename the class This is much more than just a cache now.

stablerange: do not inherit from dict This seems like and old cargo cult that when unnoticed.

stablerange: move a utility function around It make more sense to have this small function earlier in the series

stablerange: remove the now unused individual range class That class is now longer necessary, we dropped its usage for performance reason.

stablerange: directly use tuple to refer to a stable range Now that all advance logic lives in the unified class we no longer needs the individual class. Creating and operating on this cache introduce a significant overhead that we can not stop having. From now on, a range a is pair tuple '(headrev, index)'. Long live the tuple.

obshash: properly cache obshash value The code was buggy and only cached non-nullid/non-inherited value. This was previous hidden because we were using a 'propertycache' to cache the value on the range object. This fixes it and restore a lot of performance.

stablerange: directly use 'self' when possible Code movement introduced multiple silly case were we where accessing 'self' though 'repo.stablerange' for no good reasons.

revsfromrange: set the cache for the multiple bottom ranges in merge slicing We no longer rely on the object magic here.

revsfromrange: set the cache for the single bottom range in merge slicing We no longer rely on the object magic here.

revsfromrange: set the cache for the top range in merge slicing We no longer rely on the object magic here.

revsfromrange: remove reference to '_revs' in merge slicing Given '_revs' is a property from the cache, we use the official method of the object we are on instead. That method should be using the same cache than the property if available.

revsfromcache: update cache for the top slice if possible Same logic, we update the cache if have the data.

revsfromrange: skip setting the cache for length-1 top entry The content of the range is trivial to compute.

revsfromrange: update cache for parentrange directly in the code We update it where it matters if we detect that we have the data.

revsfromramge: hard code the single changeset range case That case is trivial and triggering and full stable sort for it seems a bit silly.

stablerange: introduce caching for the full revision in a set Such cache proved handy in the "per-range" class so we carry it along to the unified class. cf documentation for details.

stablerange: add a cache for stablesort ordering This will be very handy for merge, cf inline documentation for details.

stablerange: move revs computation within the main class We still need to compute the revision withing a range when we slice a merge. This is the last large logic that remains in the individual class and we migrate is on the main class.

stablerange: minor method reorders on the main class We put the public method first for clarify.

stablerange: drop "key" and "id" logic form the class We can restrict to the bare minimun for equality and hashing now.

stablerange: drop length from the class There is not remaining user.

stablerange: drop _depth Nothing uses it anymore.

stablerange: drop __repr__ IT was used for debug and the class is on it way out.

stablerange: drop the subranges method on the small class Nobody use it anymore.

stablerange: use subranges from the main class in subrangesclosure This is the last method used on the class.

stablerange: use subranges from the main class in _obshashrange This is the last method used on the class.

stablerange: use subranges from the main class in findrangemissing This is the last method used on the class.

stablerange: make sure nobody use '.depth' anymore

stablerange: use depthrevs in range slicing We stop using the property from the class to get us closer to tuple.

stablerange: use depthrevs in debugstablerange We stop using the property from the class to get us closer to tuple.

stablerange: use rangelength inside the class itself We stop using the building '__len__' this get use closer to be able to use a tuple.

stablerange: use rangelength in '_slicesatrange' We stop using the building '__len__' this get use closer to be able to use a tuple.

stablerange: use rangelength in '_slicepoint' We stop using the building '__len__' this get use closer to be able to use a tuple.

stablerange: use rangelength in subrangesclosure We stop using the building '__len__' this get use closer to be able to use a tuple.

stablerange: use rangelength in _obshashrange We stop using the building '__len__' this get use closer to be able to use a tuple.

stablerange: use rangelength in debugstablerange We stop using the building '__len__' this get use closer to be able to use a tuple.

stablerange: use rangelength in findmissingrange We stop using the building '__len__' this get use closer to be able to use a tuple.

stablerange: make sure nobody use '.index' anymore We rename the attribute for good measure.

stablerange: stop using '.index' inside the class itself We now access '[1]' as we'll do with the future tuple.

stablerange: stop using '.index' in '_slicesrangeat' We now access '[1]' as we'll do with the future tuple.

stablerange: stop using '.index' in '_slicepoint' We now access '[1]' as we'll do with the future tuple.

stablerange: stop using '.index' in 'rangelength' We now access '[1]' as we'll do with the future tuple.

stablerange: stop using '.index' in '_queryrange' We now access '[1]' as we'll do with the future tuple.

stablerange: stop using '.index' in debugstablerange We now access '[1]' as we'll do with the future tuple.

stablerange: make sure nobody use the 'stablekey' property outside the class

stablerange: make sure nobody use '.head' anymore We rename the attribute for good measure.

stablerange: stop using '.head' inside the class We now access '[0]' as we'll do with the future tuple.

stablerange: stop using '.head' in '_slicesrangeat' We now access '[0]' as we'll do with the future tuple.

stablerange: stop using '.head' in '_slicepoint' We now access '[0]' as we'll do with the future tuple.

stablerange: stop using '.head' in rangelength We now access '[0]' as we'll do with the future tuple.

stablerange: stop using '.head' in debugstablerange We now access '[0]' as we'll do with the future tuple.

stablerange: remove node unused 'node' property Close to killing that object.

stablerange: stop using '.node' in __repr__ This remove the last user to this method.

stablerange: change the key to use the revision number Using node is more stable but for now do not have on disk caching and revision number should be find in memory. This makes the data used for the file cache closer to what it will be when we use tuple. We might reintroduce node in the future but let us keep it simple for now.

stablerange: stop using '.node' in _queryrange We access the range-head revision number by index and convert it on site.

stablerange: stop using '.node' in debugstablerange We access the range-head revision number by index and convert it on site.

stablerange: stop using '.node' in findmissingrange We access the range-head revision number by index and convert it on site.

stablerange: stop using '.node' in obshashrange We access the range-head revision number by index and convert it on site.

stablerange: stop using '.node' in subrangesclosure We access the range-head revision number by index and convert it on site.

stablerange: have the class behave as a tuple If we want people to use a tuple, we should offer them a tuple. This should help update most of the code iteratively.

obshashrange: extract computation back into the discovery module This obshash is related to discovery and it seems more appropriate to have to live there. This remove the last large piece of logic from the class. We'll now be able to slowly turn it into a tuple.

obshashrange: use a small utility function to access the obshash If we want the object to disappear we needs the top level code to stop accessing its attribute.

debugstablerange: minor code reformat The content of that list will become more complex as we drop the object so we make sure to have one value per line for clarity.

stablerange: move the subrangesclosure inside the module This seems more suitable and open the way to simple update of how we build things without too much impact outside the module. The debug command is still in the 'obsdiscovery' module because it also deal to obshash and I'm not sure of were this should live yet.

stablerange: compute subranges from parent when possible Unless we are a merge, we can infer the standard subranges of a range by reusing the subranger of its parent. We update the implementation to do so. We still needs the "old way" for merge. We move that code in a dedicated function for the sake of simplicity.

stablerange: add an official warmup function The function is responsible for making sure we have the necessary data for a sets of heads. For now this only warm the depth cache. More will follow soon. Such explicite warmup will be usefull for on disck caching as an early point of writing will be easier.

stablerange: remove now unnecessary setter The class is handling all computations and cache access by itself now. So we can drop this method.

stablerange: directly perform slicing in the getting method Now that all necessary functions are available, we simply apply the standard slicing on cache miss and proceed.

stablerange: move standard slice point definition in main class More migration of code away from the doomed individual class.

stablerange: move the slicing method on the central class We migrate code away for the individual range class.

stablerange: move the range class in the new module Our ultimate goal is to remove this class for performance reason. however for now, it contains most of the code we care about so we migrate it as a block first.

stablesort: move into the stablerange module The stable range rely on the stable sort so it make senses to move it there. Will need direct access to it in the future.

subranges: migrate handling of single element range This is the simplest case by far, so we start with that one. We still use the rich object as an argument, but we'll do our best to not relying on that. This is important for performance reason.

stablerange: move the subrange cache into our new class This is the first step toward having more logic in that class

depth: extract code dedicated to depth of a merge in its own function The merge case is more complicated than the regular one, we extract is for the sake of clarity.

stablerange: move 'depth' inside a new 'stablerange' module The stablerange used for discovery requires significant amount of code. There is algorithme, cache, cache persistence, etc. So we create a dedicated module for it. The function is directly moved into a rich class handling cache (for now in memory) because we know we will need it.

obsdiscovery: document the status of the module I figured i would be useful to document what we expect from the code in each module.

split: move the debugcommand into a dedicated module The code related to debugobsstorestat is fairly independant, we move it into its own module.

legacy: move 'debugrecordpruneparents' in the extensions The transition is a couple of year old now, repository with the old format must be quite hard to find by now.

checks: correct the shebang line filtering for python files As it is, the only related file is docs/test2rst.py, which was covered by **.py. Not sure if it matters, but most patterns in core tests are for "#!.*?python". (Though there are a couple "#!.*python" tests.)

tests: add glob for Windows

tests: adds simple test case for heads checking This is the start of some systemic testing of the head superceeding detection mechanism.

tests: move exchange utility in testlib We have a testlib directory now lets use it.

exchange: fix some wrong reference to serveronly The function have all moved into 'obsexchange' now, so we do not need (and actually cannot) seek them in 'evolve.serveronly'.

checks: add a test that check MANIFEST.in content This make sure we keep the things updated.

README: add a link to mercurial devel This will help people to find the mailing list details.

README: tries to improve the title about server only This seems a bit better.

README: remove mention of make Using pip in all cases seems a better direction.

version: mark the current source as development version for 6.0.0 This is useful to distinguish the development version from the latest tagged version. In this particular case, this will allow us to publish a pre-version on pypi.

mercurial-3.8: merge with future evolve-6.0.0 We introduces the new code on the compat branch to check the tests.

mercurial-3.9: merge with hg-4.0 branch We merge with the code for the future evolve 6.0.0 code to check for compatibility. Only minor test output change (" -> ') have been noted.

mercurial-4.0: merge with future 6.0.0 A new version will be released soon, we start handling mismatch in test output to make the actual release time smoother.

checks: update pyflakes matching too We make sure to not select removed files.

checks: do not run pyflake on removed file The fileset matches removed files. This confuses pyflakes for good reasons.

compat: closing mercurial-3.7 compatibility branch The "evolve-6.0.0" release drop compatibility with Mercurial 3.7. No new commit are expected on this branch.