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.

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

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

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

README: timeless typo fixes This applies some feedback timeless provided me from IRC.

cleanup: drop an empty section header

compat: drop some <hg-3.4 compatibility code The `hg commit` commands has a -i flag for ages now.

README: more update to prepare for pypi upload * mention the evolve.serveronly extension, * remove help related to topic into a different README file.

evolve: update the capabilities and commands name for obshashrange We makes is clear that these version are useful for earlier testing but they are not ready for any kind of real usage yet.

README: more change to have a pretty rendering on pypi We moves section around and fixes some markup.

MANIFEST.in: fix various mismatch check-manifest is no longer complaining

README: rework install instruction For both evolve and topic. The topic introduction is updated too.

README: rework the intro Less scary wording (similar to the wiki changes) and point to the user mailing list.

rangeobshash: minor cleanup of the obshash code We achieved minor speedup by delaying the hashing until we know it is needed.

stablerange: remove call to 'repo.revs' It turned out that the percentage of time spend parsing the revset string was two digits, so we compute de heads inline.

stablerange: reuse node calculation as much as possible We have a property cache with that value, so we just reuse it.

stablerange: adds some caching of the subranges The goal of subranges is to be as reusable as possible, so we cache the subrange relationship to take advantage of this.

stablerange: operate on an unfiltered repository We only do operation on ancestors so using unfiltered is fine.

depth: use lower lever function to compute missing The time spend parsing the revset is noticeable.

depth: update depth to code to reuse ancestors depth Computing the depth of all N revs is no longer 'O(N**2)'

obsdiscovery: extract a smarted depth in utility The function is reusing previous depth for ancestors unless this is a merge.

obsdiscovery: simply some of the missing computation

discovery: implement some range based discovery This use the previously implemented methods to implement some discovery and fetch method using ranges. There is currently major performance issue and some aspect of the protocol will changes.

discovery: introduce a official 'obshash associated to a range The hash in a combination of the hash a its subrange. If the range is a leaf, we have the obsmarker relevant to the node in that leaf range.

discovery: introduce "stable slicing" methods We introduce new code that leverage the stable sorting to slices a graph in a way "stable" accross repository. This should allow us to use theses slices for obsolescence markers discovery.

discovery: adds a function doing revnum independant sorting The function is doing a topological sort without depending on revision number. This make the sort independent of the repository and suitable for discovery.