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.