pullbundle: improve slicing of the lower part of range The previous method could get confuse by merge and overslice. The new method is better at using sticking on power of two boundaries.

stablerange: fix slicing of arbitrary ranges Pull bundle trigger slicing from range with arbitrary initial skip. We have to adjust the current slicing to take this into account.

pullbundle: attempt to save stablerange cache after each computation Since we do not serve the full repository, we use more stablerange starting from a random point. These are probably not loaded yet and should be cached. This is best effort caching, if we can't save them we won't.

pullbundle: add basic extension metadata

pullbundle: add a config option for the cache directory

pullbundle: add an output about the time spent slicing the set This will be useful to monitor overall performance.

pullbundle: add extension documentation

pullbundle: add an extra test showing how cache are reusable We issue a single final pull, most of its item are reusable.

pullbundle: add caching logic We now only generate a bundle once (and store it to disk). If we need it again, we use it directly from disk.

pullbundle: slice pull into multiple ranges We subdivide the set of missing revisions into multiple "range" using the "stable range" data structure. This slicing aims at maximizing the capability of the resulting ranges.

pullbundle: initial commit Right now, we do not do any slicing, but we install the wrapping and the tests.

test: update output to make streamv2 capabilities CORE-TEST-OUTPUT-UPDATE: 4bd6e444c76f

branching: merge with stable

topic: respect preexisting 'topic' value on workingcommitctx Mercurial's core changeset: 6c8ceebce309 revealed an issue. If the creator of a workingcommitctx explicitly assigned a 'topic', it was silently overridden by the current active on. This break import of patch with topic information. We now respect preexisting topic information.

topic: add a compatibility to access transaction's names The attribute was made private in 4024c363cd33.

topic: add a compatibility to access transaction's validator The attribute was made private in ebbba3ba3f66.

evovle: remove redundancy in evolve output Copying the discription of this redundancy issue given by Pierre Yves David: When running `hg evolve` to stabilize orphan changeset output about the currently stabilized changeset is issued. For example: $ hg evolve move:[3] a3 atop:[4] a2 working directory is now at 7c5649f73d11 This output can become quite repetitive when orphan are stabilized atop each other. For example: $ hg evolve --all move:[8] dansk 2! atop:[10] dansk! merging main-file-1 move:[9] dansk 3! atop:[11] dansk 2! In this case it would be smoother to issue: $ hg evolve --all move:[8] dansk 2! atop:[10] dansk! merging main-file-1 move:[9] dansk 3! Since we are moving "dansk 3!" atop the changeset we just stabilized. When adding this be careful that we still want to issue the "atop" message in various cases: 1. first changesets in a stack 2. when the orphan is not stabilized atop previous one 3. when using hg evolve --continue to resume an evolution So, I have made the changes which also respect above listed three points. And changes in tests/test-evovle*.t reflecting the changed behavior.

amend: handle crash before transaction initialization with --patch The `tr` object can be None.

branching: merge with stable

obsdiscovery: adopt to calling convention change Upstream commits 71d83b315778 and abce899c985f changed the calling convention of setdiscovery._takefullsample(). We inspect the signature of the function before calling it so we can pass the proper arguments.

branching: merge stable into default

packaging: mark as development version This avoid confusion when people install version from source.

Added tag 8.2.1 for changeset c6362c4abd69

packagin: prepare release 8.2.1

test-compat: merge mercurial-4.4 into mercurial-4.3

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge stable into mercurial-4.6

branching: merge stable into default

caches: issue both debug and blackbox log message This increase the odd someone looking for issue will find them.

cmdrewrite: rename variable and move it closer to where it is used Renaming to satisfy pep8-naming linter plugin, which complained on this variable because all-uppercase names are reserved for constants, and constants need to be module-level. This variable is not a good choice for moving up to the module level because it's used only in one place. Additionally, let's have it closer to the place it's actually used to potentially avoid an extra call to _() function (however cheap it may be).

changelog: mention the cache improvements

obshashrangecache: be more paranoid in the errors we catch It seems like there error were already covered. Better safe than sorry.

stablerangecache: be more paranoid in the errors we catch It seems like there error were already covered. Better safe than sorry.

stablesortcache: update the variable tracking on-disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

stablesortcache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during cache update should not block Mercurial operations.

firstmergecache: update the variable tracking on-disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

firstmergecache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during cache update should not block Mercurial operations.

depthcache: update the variable tracking on disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

depthcache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during Cache update should not block Mercurial operations.

obscache: update the variable tracking on disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.

obscache: ignore permission and OS errors when writing In practice we always update this cache along side a new transaction, with lock taken so permission issues should not happens. However, staying on the safe side is better. Errors during Cache update should not block Mercurial operations.

obshashrange: force reset if many changes If there is many new markers (or the markers affect many changesets) resetting affected changeset can get slow. A common case for that is then changeset and markers are added in different transaction, (eg: when using clone bundle). When we detect such case, we reset the obshashrange cache, rewarming it should be faster. Here many is arbitrarily set to 10 000. The number might get adjusted.

topic: refactor revset.py slightly Checking both kind == 'literal' and topic.startswith('literal:') seems to be redundant, because of how stringutil.stringmatcher() works.

test: update output to match new `hg verify` reports CORE-TEST-OUTPUT-UPDATE: f1186c292d03

test: update output to match new "pull" phase report CORE-TEST-OUTPUT-UPDATE: 89630d0b3e23

test: adapt to change in revert messages order CORE-TEST-OUTPUT-UPDATE: cb70501d8b71

rewind: fix help text (mostly grammar, but also s/precursor/predecessor)