templatekw: introduce active subkeyword from bookmarks keyword Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.

bookmarks: name label for active bookmark correctly Retain old label as well for backwards compatibility. Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.

tests: descending empty dirs works in all hgweb styles, test them too The tested feature was added to multiple hgweb styles in c21d236ca897, but only paper was tested. Let's test everything now, including monoblue, which only got the feature some 6 years late in e50d8b21f4f4.

tests: actualize the comment in test-hgweb-descend-empties.t The comment came together with the whole test file and the feature (descend empty dirs in hgweb) in c21d236ca897, but for some reason wasn't exactly accurate. Namely, there isn't e1 directory in the test at all, it obviously should say d1; and b1 didn't terminate at level 3, but does now.

revset: add fast path for _list() of integer revisions This can greatly speed up chained 'or' of integer revisions. 1) reduce nesting of chained 'or' operations 2) optimize to a list 3) fast path for integer revisions (this patch) revset #0: 0 + 1 + 2 + ... + 1000 1) wall 0.483341 comb 0.480000 user 0.480000 sys 0.000000 (best of 20) 2) wall 0.025393 comb 0.020000 user 0.020000 sys 0.000000 (best of 107) 3) wall 0.008371 comb 0.000000 user 0.000000 sys 0.000000 (best of 317) revset #1: sort(0 + 1 + 2 + ... + 1000) 1) wall 0.035240 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) 2) wall 0.026432 comb 0.030000 user 0.030000 sys 0.000000 (best of 102) 3) wall 0.008418 comb 0.000000 user 0.000000 sys 0.000000 (best of 322) revset #2: first(0 + 1 + 2 + ... + 1000) 1) wall 0.028949 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) 2) wall 0.025503 comb 0.030000 user 0.030000 sys 0.000000 (best of 106) 3) wall 0.008423 comb 0.010000 user 0.010000 sys 0.000000 (best of 319) But I admit that it is still slower than the spanset. revset #3: 0:1000 3) wall 0.000132 comb 0.000000 user 0.000000 sys 0.000000 (best of 19010)

revset: optimize 'or' operation of trivial revisions to a list As seen in issue4565 and issue4624, GUI wrappers and automated scripts are likely to generate a long query that just has numeric revisions joined by 'or'. One reason why is that they allows users to choose arbitrary revisions from a list. Because this use case isn't handled well by smartset, let's optimize it to a plain old list. Benchmarks: 1) reduce nesting of chained 'or' operations 2) optimize to a list (this patch) revset #0: 0 + 1 + 2 + ... + 1000 1) wall 0.483341 comb 0.480000 user 0.480000 sys 0.000000 (best of 20) 2) wall 0.025393 comb 0.020000 user 0.020000 sys 0.000000 (best of 107) revset #1: sort(0 + 1 + 2 + ... + 1000) 1) wall 0.035240 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) 2) wall 0.026432 comb 0.030000 user 0.030000 sys 0.000000 (best of 102) revset #2: first(0 + 1 + 2 + ... + 1000) 1) wall 0.028949 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) 2) wall 0.025503 comb 0.030000 user 0.030000 sys 0.000000 (best of 106)

revset: make "null" able to appear in internal _list() expression This is the same workaround introduced at e16456831516. Without this patch, "null or x" can't be optimized to _list(null x). Test case will be added by the next patch.

revset: make internal _list() expression remove duplicated revisions This allows us to optimize chained 'or' operations to _list() expression. Unlike _intlist() or _hexlist(), it's difficult to remove duplicates by the caller of _list() because different symbols can point to the same revision. If the caller knows all symbols are unique, that probably means revisions or nodes are known, therefore, _intlist() or _hexlist() should be used instead. So, it makes sense to check duplicates by _list() function. '%ls' is no longer used in core, this won't cause performance regression.

repair: use _hexlist() to build revset expression from binary nodes _hexlist() should be efficient than _list().

listkey: display the size of the listkey payload in a debug message This is a useful information to have in general and we already have debug output related to listkeys. I'm planning to play around with massive amount of phases roots and bookmarks so having this data in debug will be very useful. This already got me to spot that one of the Logilab's review repo is exchanging 65KB of phases data during each exchanges.

ssh: test some no-op pull through ssh with --debug It appears that we are never running any wireprotocol operation with a --debug flag. So we are adding some basic testing into 'test-ssh.t'

subrepo: detect issue3781 case earlier so it apply to bundle2 We are doing some strange special casing of phase push when: - the source is a subrepo - the destination is publishing - some changeset are still draft on the destination In that case we do not push phases information (to publish the draft changesets) because it could break simple cycle of 'clone/pull/push' of subrepos. We have to detect this case earlier to have bundle2 respecting it. We change the test to check the behavior for both bundle1 and bundle2.

bundle2: hide bundle2 stream debug under a config flag The old output is very verbose and unsuitable for general debug level. It is however very useful for debugging bundle2 generation or consumption issues. All this verbose ouput is hidden under a 'devel.bundle2.debug' flag.

bundle2: add generic debug output regarding processed interruption If we are about to hide the detailed debug output, we need some generic debug message to replace it in a concise way.

bundle2: add generic debug output regarding processed part payload If we are about to hide the detailed debug output, we need some generic debug message to replace it in a concise way.

bundle2: add generic debug output regarding processed part If we are about to hide the detailed debug output, we need some generic debug message to replace it.

bundle2: add generic debug output at the end of bundle processing If we are about to hide the detailed debug output, we need some generic debug message to replace it in a concise way.

bundle2: add generic debug output regarding processed bundle If we are about to hide the detailed debug output, we need some generic debug message to replace it in a concise way.

histedit: fix keep during --continue The --keep option was being serialized to the state file, but it wasn't actually being used when running a histedit --continue. This fixes that.

dispatch: disable demandimport for the --debugger option Something in Python 2.7.9 or so broke the --debugger option with ui.debugger = ipdb. I get the traceback below. There is some apparent confusion with demandimport. This should be disabled anyway for the --debugger option. The debugger must be imported right away, before any other dispatch. There's no benefit in delaying the debugger import. This patch uses the demandimport.deactivated() context manager. Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 121, in _runcatch debugmod = __import__(debugger) File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 115, in _demandimport return _hgextimport(_import, name, globals, locals, fromlist, level) File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/dist-packages/ipdb/__init__.py", line 16, in <module> from ipdb.__main__ import set_trace, post_mortem, pm, run, runcall, runeval, launch_ipdb_on_exception File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 134, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/dist-packages/ipdb/__main__.py", line 29, in <module> if IPython.__version__ > '0.10.2': File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 106, in __getattribute__ self._load() File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 78, in _load mod = _hgextimport(_import, head, globals, locals, None, level) File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/dist-packages/IPython/__init__.py", line 45, in <module> from .config.loader import Config File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 132, in _demandimport return _origimport(name, globals, locals, fromlist, level) File "/usr/lib/python2.7/dist-packages/IPython/config/__init__.py", line 16, in <module> from .application import * File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 115, in _demandimport return _hgextimport(_import, name, globals, locals, fromlist, level) File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/dist-packages/IPython/config/application.py", line 30, in <module> from IPython.external.decorator import decorator File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 134, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/dist-packages/IPython/external/decorator/__init__.py", line 2, in <module> from decorator import * File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 115, in _demandimport return _hgextimport(_import, name, globals, locals, fromlist, level) File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/dist-packages/decorator.py", line 240, in <module> 'ContextManager', (_GeneratorContextManager,), dict(__call__=__call__))

hooks: replace if-try-finally with a "with" statement This seems like a textbook case for the new demandimport.deactivated context manager: check if something must be done, do it, and cleanup at the end regardless of exceptions. The diff isn't as bad as it seems. It's just all the whitespace changes due to needing an extra level of indentation. It looks cleaner with `hg diff -w`.

demandimport: define a `deactivated` context manager This can be useful for use in "with" blocks for temporarily disabling demandimport.

largefiles: drop the unused lfcommands._addchangeset()

largefiles: use the convert extension for 'lfconvert --to-normal' The logic in the convert extension is more advanced, supporting extra features like converting revision IDs in 'extras' (e.g. 'amend_source'), supports updating hashes in commit messages, and outputs an SHA map file. Rather than try to duplicate all of that, just use the existing code. Even though the convert extension supports user supplied options like filemap, etc, those features aren't available on the lfconvert interface. Therefore, it is safe to use the filemap mechanism (in memory) to handle the standin -> file rename. The convert extension handles the destination locking for this path. There was a comment in test-lfconvert.t about the hash on rev 5 being different because it was doing a better job than "hg remove" + "hg merge" + "hg commit". It isn't clear to me what was happening or why, but now the hashes match the original repo exactly after a roundtrip, which seems like a good idea. If there really was something beneficial about the previous behavior, perhaps merge can be changed so that everyone benefits. Converting to a largefiles repo still uses the original (limited) lfconvert logic.