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)

evolve: fix use of "'%d' % ctx" ctx has not been convertible to int since Mercurial commit 38f480502043 (context: remove basectx.__int__ (API), 2018-02-24). I decided to use "%s" instead to match other similar messages in evolvecmd.py. I also added a space to match the other messages.

stablerange: only issue the message once There is a flag to prevent issuing the long load message multiple time. However, it was never set. This is now fixed

changelog: fix version number

branching: merge back with stable

packaing: mark as development version This help avoid confusion when installing in progress work.

Added tag 8.2.0 for changeset 8d8f08245f97

branching: merge back with stable

packaging: prepare new release

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

topic: rework topic templatekw declaration to be 4.5 compatible again Mercurial prior to 4.5 does not have a requires keyword, so we need a compatibility layer.

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 the two stable heads

test-output: backout test output update in 8fcee1e65e29

test-output: backout test output update in 503ae2689df8

topic: update the changelog with the 's#' alias change

topic: update other occurrence of 't0' is 's0' in the code

topic: mention t0 in topic documentation

stack: display 's#' instead of 't#' and 'b#' If we want people to use it, we should display it.

stack: clarify s# error message in case of branch A branch might have a lots of changeset, with all of them public.

alias: allow reference through 's#' We keep the 't#' option, but we hope to be able to deprecate it at some point. We move to 's#' because it refers to `stack` a more generic concept. than topic. In addition, this allows to phase out 'b#' that collide with normal hex-node.

topic-revset: get the list of revset through the official localrepo API This is simpler and faster. In addition we tighter the logic to be used in case of empty topic. We do not need to fall back to revision search.

topic-revset: strictly read string Making a clear distinction between string and symbol passed to topic is important when it comes to empty topic. Filtering an empty topic name is harmless. Searching a non existent revision is not.

test: search for empty topic as a string The reduce the ambiguity in the test to help with the next change.

topic: handle ambiguous arguments to topic() revset These arguments can be interpreted as either string or a revset. The decision is made based on existence of topic with such a name. This matches the behavior of branch() revset. The code needs to know all topics that ever existed in the repo, because some commands report "disappearance" of topics after certain operations, using this revset (e.g. via stack.stack or repo.revs).

topic: handle revsets passed to topic() revset This handles cases when the argument can't be interpreted as a string at all.

topic: handle string argument to topic() revset earlier