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