obshashrange: "update" the cache on each transaction close Right now the "update" does not really file the cache, but it will detect invalid situation and clean them.

obshashrange: properly invalidate the cache on destroyed Copy paste is the scurge of code source.

obshashrange: properly drop the current connection on clear

obshashrange: exit early if nothing to write

obshashrange: use the dualsourcecache as a base for the cache This will easily open the way to incrementally updated obshashrange cache. Small update are needed to the data base schema so be bump the version Currently the update function is not warming the cache (but details case where it is invalidated).

obscache: makes dualsourcecache compatible with obshashrange cache needs The goal of the abstract method is to be reusable. So we make sure it is reusable.

readme: add a changelog entry about the more efficient obscache

obscache: extract a data agnostic class We now have an independent class that we can reuse for other purpose (eg: obshashrange cache)

obscache: extract the actual data update in a dedicated function This will help extract a data agnostic class.

obscache: move an assert to a lower level

obscache: use 'nullid' as the hash of an empty obsstore This align this result with what we use for 'emptykey'

obcache: move empty on the class We'll extract a smaller data agnostic class but we need to gather all method on it first.

obcache: move _checkkey on the class We'll extract a smaller data agnostic class but we need to gather all method on it first.

obcache: move updateneeded on the class We'll extract a smaller data agnostic class but we need to gather all method on it first.

obshistory: only display each revision once in debugobshistory When using a revision range, the same precursor could have been displayed more than once. Use a cache to display each revision only once. It's a fix until we found the nicest way to display obs history.

obshistory: display a message when one marker node has no change ctx When exchanging obs markers, there is some change contexts referencing change contexts that are not available locally. As we cannot display informations about them, instead print a message saying so.

ui: hg topic now display if current revision is in bad state (issue5533) Previously, hg topic didn't showed the state of the current revision. Now if show both informations.

obsstore: also guard agains changing object in '_checkkey' The 'upgradeneeded' function needs to be able to pass the object it fetched once.

obscache: guard from changing changelog or obsstore object We access these object once to make sure they will never change through the function (and their content will be fixed).

obscache: return the new data along-side the upgrade needs (and cache key) Having one function returning consistent data will help prevent race.

obscache: use the smaller scope function This make the function simpler and allow larger update on the 'upgradeneeded' one.

obscache: extract the cache key validation in its own function This help keep the "up to date logic" simpler and prepare a more complex version of the "upgradeneeded" logic that would return the full data needed for the upgrade.

obshistory: use formatter instead of ui.write in the debugobshistory command Replace ui.write with a formater to have template support and json output. Update tests to assert json outputs.

ui: Fix hg stack json output Previously 'hg stack -Tjson' generated invalid output like: [ { "isentry": true, "topic.stack.desc": "...", "topic.stack.index": 1, "topic.stack.state": "current", "topic.stack.state.symbol": "@" } ] , { "isentry": true, "topic.stack.desc": "...", "topic.stack.index": 1, "topic.stack.state": "current", "topic.stack.state.symbol": "@" }, { "isentry": false, "topic.stack.desc": "...", "topic.stack.state": "base", "topic.stack.state.symbol": "^" } ] I de-indented the fmt.end() to generate this output: [ { "isentry": true, "topic.stack.desc": "...", "topic.stack.index": 1, "topic.stack.state": "current", "topic.stack.state.symbol": "@" }, { "isentry": false, "topic.stack.desc": "...", "topic.stack.state": "base", "topic.stack.state.symbol": "^" } ] I've also added a test case.

topic: configure some default color for topic This makes thg usable

topic: automatically configure thg to display topic If no other config is set, we configure Tortoise-hg to display topic. This should helps usability.

readme: update readme to mention 'debugobshistory'

obshistory: add some color

obshistory: add a debugobshistory command to show obs history of a revs Add the debugobshistory command that accept a revision range and display the obsolescence containing each revision in the range. For the moment, it only displays the predecessors.

tests: add the commit style checker from Mercurial

obscache: update the cache key in place Instead of computing the key in place, we update the existing one using the data used for the incremental update of the content. This will help reaching purely incremental cache eventually. The 'getcachekey' function is dropped as it is no longer used.

obscache: distinct 'clear' and 'reset' We make a difference between basic invalidatiton (or lack of loading) and 'reset' (current cache data are invalid). We can now ensure a non-None key when we start the update. This will allow us to "update" the existing key instead of recomputing one from scratch. This is more efficient and less racy.

merge with stable

serveronly: also enable the obscache for server only setting The obscache is useful and speeds things up. So we also enable for server only setting.

obscache: document a possible way forward to skipping obsstore parsing We document a possibly viable idea for updating the cache on new revs without having to fully parse the obsstore.

obscache: update some documentation Update some data and do some proof reading.

obscache: Only access the new obsmarkers for marker update Since we know what what is the part of the file with "new" markers we can just access these. If the cache was up to date before the transaction, we'll re-parse data we just wrote. See the inline comment for details. This is good enough for now.

obscache: extract _updatemarkers code into its own function This split the update logic from the bit retrieving markers. That cannot be bad.

obscache: extract code to update from new revision Code cleanup and prepare upstreaming. The make the code more likely to work with the key validation returning an iterator of revs to update the cache with.

obscache: move assert earlier in the code If we are to crash, let us crash earlier.

merge back with stable

Added tag 6.1.0 for changeset 8510d3fd7c3b

packaging: prepare version 6.1.0

meta: update tested version to 4.1.2 We tested against the latest 4.1 too.

merge with future 6.1.0 No extra adjustment needed from hg-3.9 result

merge with future 6.1.0 No extra adjustment needed from hg-4.0 result

merge with future 6.1.0 In addition to the output reverted for 4.1, we also drop the "troubles:" entry from the standard log.

merge with future 6.1.0 test pass fine except for the removal of the extra data when accessing hidden revision. The better message are 4.2+ only.

compat: drop the context manager used to write the cache file Mercurial 3.8 does not supports context manager on atomic temporary file.

compat: make obscache code compatible with Mercurial version prior to 4.2 the phasecache.getrevset method is new in 4.2.

evolve: record testing with 4.2 4.2 is now a things and tests pass fine.

merge with default for 6.1.0

packaging first step toward 6.1.0

auto-push: move config help in the extension help That is a better spot than the extension itself.

opening mercurial 4.1 compat branch This branch will receive test update implied by the 4.2 → 4.1 changes.

obscache: skip writing to disk if the data did not changed This will avoid rewriting the cache for every single transaction.

obscache: skip writing if the cache is empty if the cache is empty, we can just skip writing to disk.

obscache: set a valid "empty" cache key if the cache is missing This avoid detecting bad cache when it just happens to be no cache.

obscache: have the obsstore fix empty file cachekey Before this change, the missing file and empty file returned different value.

obscache: log case where the cache is not up to date This will help track performance issue

obscache: still update and use the cache during transaction Other code might access the obsolete set in the middle of a transaction. It is better to use the case in that case since the update will eventually be written when the transaction is committed.

obscache: warm the cache in all cases There are case when the obsstore have been invalidated, but we still need to update the cache.

obscache: update the format to allow negative tiprev If the changelog is empty (but the obsstore is not) the 'tiprev' will be -1.

obscache: load the disk data before checking is the cache is up to date This is actually required since non-loaded cache will never be up to date...

obscache: skip the cache entirely if not up to date The current update code has some race condition windows around updating. But we also ensure the cache are up to date with every transaction. So outdated cache mean another client have been mudding the repository but things will get back in place at the next transaction. So we just skip using the cache when not up to date. This is not the best we could do. But this is good enough for now.

readme: mention that some improvement are enabled for 4.2 only

perf: use the cache to compute the obsolete set. The official "obsolete" computation is switch to using the cache. This provide noticable speed for operation that does not need to actually access the obs markers. The part relating to obsolete changeset computation disappear from the execution profile when it is used.

perf: warm the cache after all transactions This is the simplest way to ensure the data are up to date.

perf: adds a cache to know if obsmarkers might affect a revision Phase information still needs to be thrown in the mix to compute the final information, but skipping reading the obsstore for most operation is a large win. Usage of this cache arrives in the next changeset.

perf: adds cachekey utility to validate changelog+obsstore content We adds more helper about cache key to prepare the arrival of a cache that can be updated iteratively (similar to branchmap cache)

perf: adds some cache key helper on the obsstore class This will be useful to allow validating cache depending on obsstore without parsing the whole obsstore.

compat: only install the better filtered message for mercurial 4.2 and above The helper function does not exist in earlier version.

evolve: update extension help I'm pretty sure there are some missing bits, but this cannot be worse than before.

merge with stable

ui: change the hidden revision error message It now display the same details than the warning when the working directory parent become obsolete like: $ hg update 0 abort: hidden revision '0' (successor: f301a99bd857)! $ hg up 1 abort: hidden revision '1' (pruned)! $ hg update 0 abort: hidden revision '0' (successors: 91311af6da10, 70653776ec4c)!

ui: add better messages when the working copy become obsolete.

topic: directly use "super" call That is how one is supposed to do it.

repo: properly progate "destroyed" call to super class The propagation of the 'destroyed' call was dropped. I'm not certain of the consequences of having a partially broken "destroyed" call, but this can't be good.

safeguard: add an option to disable automatic publishing Pushing to publishing server by mistake is a bit too common in the current state of evolve. Especially when the lack of good feature branch story make the use of -f a bit too common. So we add a very simple experimental option to allow warning (or abort) when changeset are pushed to a publishing server. This is unlikely to survive as is, but this is useful now.

merge back with stable

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.