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.