evolve: adding longer aliases for olog Novice users will likely find the longer versions more obvious to understand what they're doing (olog only makes sense once you already know what it does). Especially on the help page, "obslog" will be easier to find and make sense of.

debugobsstorestat: add markers size information We adds some extra information about markers size in all known format.

packaging: bump version to 6.3.0.dev

merge back with stable (post-release)

packaging: bump version to 6.2.1.dev

Added tag 6.2.0 for changeset d4ee0274a8ef

merge back with stable

merge with future 6.2.0 No extra change were needed compared to 3.9.

merge with future 6.2.0 The new 'olog' command is not working with 3.9 so we skill all mentions of it in the tests. This also apply to the topic extensions.

merge with future 6.2.0 Minor unrelated output adjustements were needed.

merge with future 6.2.0 There are been (multiple) minor output changes.

packaging: prepare release 6.2

debian: fix email

topic: update 'tested with' and readme We are compatible with Mercurial 4.0 and above

readme: rearrange readme before release There won't be a bugfix release (and other cleanup)

test: reduce output size to fight unstability Until `hg touch` can be more stable, we have to do this :-/

tests: disable blackbox for 'getid' This will significantly simplify the blackbox log.

compat: handle lack of 'util.timer' for pre 4.2 version We keep compatibility with previous Mercurial version by redefining the timer when needed.

test: enforce color to be enabled 4.2 enable color by default and start to get used in test. So we add this to the test for previous version.

merge with default

tests: add a test about strip with obshashrange enable I've seen some traceback but I cannot reproduce them. This tests seems useful anyway.

obshistory: add a json test with cycles

tests: glob an absolute path The ssh command path was in full and pointing the mercurial checkout of the last one who touched the test.

olog: document the default value We actually display the log for '.' which is useful.

readme: rearrange changelog content blackbox is more important than the various caches changes.

obshistory: rename the command to "olog" The command start to look good enough to be handed out to user. We replace the old and useless "olog" alias in favor of the new command.

obshistory: move the command into the obshistory module The root module is far too large already.

obshistory: add docstring to cmddebugobshistory Add debugobshistory command documentation based on the log command documentation.

obshashrangecache: make sure we re-warm the cache after a reset This will "mitigate" the effect of dropping existing entries when new markers affect existing range.

obshashrangecache: precisely track affected revs when adding new markers This will be useful when we start doing finer grained invalidation (instead of dropping all data).

debugobshistory: handle multiple cycles We previously handled up to one cycle only. This is now fixed.

test: clean the debugobshistory cycle test Use 'desc(...)' instead of revision numbers. Also blank lines between commands in the same test

obsdiscovery: add more debug output we add a summary debug output to help gathering data.

discovery: log information about obshashrange We augment the blackbox output to help with data gathering.

obshistory: add a graph option on the debugobshistory command Add a graph option (--graph) to the debugobshistory. The output is like the 'hg log -G' output. The option is activated by default but can be deactivated with '--no-graph' option. There are various issue with the current implementation (multiple cycles handling, N² complexity) but this can be fixed later.

obshistory: import 'node' as 'nodemod' This simplify the next changeset.

label: add a label for the node in the "wc now at" message MOAR COLOR FOR THE COLOR GOAD!

label: rename 'evolve.short_node' to 'evolve.node' A wider labelk will helps compatibility.

obshistory: refactor debugobshistory Rename the function and extract the heavy work of the command in a separate module named obshistory.py

test: adapt to change in cache warming in core Core Mercurial has a more rational cache warming strategy now. 24f55686a63d stopped warming of the cache after every changegroup application (in favor of end of transaction warming). This reflect in the blackbox test output.

test: adapt to change in cache warming in core Core Mercurial has a more rational cache warming strategy now. 2b6692df1bdf stopped warming of the cache after every commit (in favor of end of transaction warming). This reflect in the blackbox test output.

stablerangecache: avoid crash when 'cache/' directory is missing If the directory is missing, we create it.

obshashrange: avoid crash when 'cache/' directory is missing If the directory is missing, we create it.

tests: apply output changes from core fix Mercurial core fixed a bug were the obsolete set (and all depending data) stayed invalid after markers were merged. Fixing this bug is fixing some bad output on the evolve side so we apply the output change.

packaging: mention 'dev' status in the version number

color: update the shorttemplate to use colors

merge with stable

obshashrange: cleanup 'valid' life cycle - reset is only called when we detect a strip, the on disk data are invalid, - after a reset, we should not keep using the data base connection, - after a write, the on disk data are valid.

obsrangecache: raise programming error when using an unwarmed cache This will provide a better experience for developer using this the cache.

obshashrange: stop marking on-disk data as invalid on clear This was abusing and prevent proper use of the on disk cache.

obshashcache: purge the meta line before writing a new one Otherwise we get multiple lines and this gets messy.

obshashrange: drop spurious whitespace

obshashcache: invalidate affected cache entries on side Calling reset during upgrade is screwing up the cache key update.

obshashcache: properly break out of all loops

dualsourcecache: simplify cachekey.clear We do not needs the super call anymore and we can make the reset case more explicit. So we do.

tests: small test update This is a bit clearer.

dualsourcecache: fix obskey return by _checkkey The function was returning the old key instead of the new one. This is now fixed.

test: update test-obsolete.t to use common.sh The definition of getid() in the test file was wrong, use the one from common.sh instead

obshashrange: log reset from new markers This will help tracking performance impact from current limitation.

dualsourcecache: log cache reset

stablerange: log time spent updating the stable range

cache: track time spend updating various cache This produce more useful blackbox log.

obshashrange: adds blackbox usage in tests This will help track the validation of the cache.

obshashrange: test behavior in case of rollback The cache should be properly invalidated.

obshashrange: extend tests We test more situations.

dualsourcecache: add a cache name This will be used to automatically log message for blackbox

obscache: stop definition of the empty key

obshashrange: keep value fetched from sql in memory This will reduce the number of roundtrip to the data base we need.

obshashrange: stop inheriting from 'dict' A simple dictionary attribute seems more simpler.

merge with stable

obshashrange: to not overwrite the list with the set We reusing the list variable lower in the code.

obshashrange: properly break out of the two loops Otherwise we would continue to iterate even after we reseted the cache.

obshashrange: fix reset conditional If the revision is in "revs" we should not reset the cache. The old code was wrong (Thanks goes to new tests for catching this).

cache: ensure we warm stablerange cache before the obshashrange cache I've been seeing traceback that seems to be happening because of issues in this area.

evolve: fixing obscache invalidation This was missing a call to the parent's destroyed(), such that any transaction after stripping some nodes would result in a crash (by attempting to read nodes which were stripped).

obshashrange: warm the cache at the end of each transaction This will help having warmed cache for read only client. The warming is still imperfect in case of markers that trigger a reset, but we are in a better place than what we used to be.

obshashrange: warm cache outside of loops The performance impact will be lower

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