largefiles: port revset registration to exthelper
This tests the merge code that wasn't tested in the previous patch.
exthelper: reintroduce the ability to register revsets
I think this is what Yuya and Boris agreed on.[1] This happens *after* the
extsetup phase now (and after the _aftercallback notifications). But this is
trivial, mergeable between exthelper instances, and doesn't need to have the
extension name supplied when registering.
The test needed updating so that extsetup() takes a `ui` argument, as exthelper
isn't trying to be backward compatible with 1.3.1.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-December/125888.html
largefiles: drop the uisetup module
This is small enough to live in the __init__ module.
branches: add -r option to show branch name(s) of a given rev (
issue5948)
Differential Revision: https://phab.mercurial-scm.org/D5486
progress: avoid ui.configbool() lookup when progress bar is active
Profiling revealed that the ui.configbool('progress', 'debug') during
progress bar updates was consuming a significant amount of overhead.
This commit adds an attribute on progress bar instances that caches
this config option.
The impact on `hg perfprogress` with default options is significant:
before: ! wall 4.641942 comb 4.580000 user 4.210000 sys 0.370000 (best of 3)
after: ! wall 1.948626 comb 1.950000 user 1.950000 sys 0.000000 (best of 5)
After this change, profiling reveals that progress.progbar.progress()
is now consuming ~73% of time.
This change does not improve the execution time if the progress bar
is disabled. We may want a more comprehensive solution for that case,
as the progress bar won't be enabled in a number of scenarios (e.g.
servers and processes not attached to an interactive TTY).
I also think that overhead of ~2.0s for 1M updates is a bit high.
I suspect further refactoring of the progress bar can significantly
reduce overhead. I don't have plans to do this, however.
Differential Revision: https://phab.mercurial-scm.org/D5408
largefiles: port wrapped functions to exthelper
Things get interesting in the commit. I hadn't seen
issue6033 on Windows, and
yet it is now reproducible 100% of the time on Windows 10 with this commit. I
didn't test Linux. (For comparison, after seeing this issue, I tested on the
parent with --loop, and it failed 5 times out of over 1300 tests.)
The strange thing is that largefiles has nothing to do with that test (it's not
even mentioned there). It isn't autoloading run amuck- it occurs even if
largefiles is explicitly disabled, and also if the entry in afterhgrcload() is
commented out. It's also not the import of lfutil- I disabled that by copying
the function into lfs and removing the import, and the problem still occurs.
Experimenting further, it seems that the problem is isolated to 3 entries:
exchange.pushoperation, hg.clone, and cmdutil.revert. If those decorators are
all commented out, the test passes when run in a loop for awhile. (Obviously,
some largefiles tests will fail.) But if any one is commented back in, the test
fails immediately.
I left one method related to wrapping the wire protocol, because it seemed more
natural with the TODO. Also, exthelper doesn't support wrapping functions from
another extension, only commands in another extension. I didn't try to figure
out why rebase is both command wrapped and function wrapped.
largefiles: port commands to exthelper
One subtle change here is that the purge, rebase and transplant extensions are
wrapped in extsetup() instead of uisetup().
exthelper: support the option argument when registering a command
Largefiles uses this 5th argument with push and pull, so this will be tested in
the next commit. I assume the reason for unrolling and reforming the tuple in
each finalxxxsetup() is to validate that something proper was passed in when
registering. But it's better to explode when decorating than during the delayed
actual registration.
largefiles: port configitems to exthelper
It looks like dynamicdefault was referenced in a non-standard way.
exthelper: drop a compatibility shim with '^command' syntax
This syntax was dropped in
fa88170c10bb.
wireproto: in batch queries, support queries with immediate responses
listkeys and pushkey return without querying the remote when the
remote doesn't support such queries. Before this change, the batching
code didn't handle this convention, resulting in this kind of error:
$ hg pull ssh://user@dummy/repo1 -r tip -B a
pulling from ssh://user@dummy/repo1
remote: ** Unknown exception encountered with possibly-broken third-party extension disable-lookup
remote: ** which supports versions unknown of Mercurial.
remote: ** Please disable disable-lookup and try your action again.
remote: ** If that fixes the bug please report it to the extension author.
remote: ** Python 2.7.15+ (default, Oct 2 2018, 22:12:08) [GCC 8.2.0]
remote: ** Mercurial Distributed SCM (version 4.8.1+586-
ef54bd33b476+
20181224)
remote: ** Extensions loaded: disable-lookup
remote: Traceback (most recent call last):
remote: File "/tmp/hgtests.i66Npc/install/bin/hg", line 43, in <module>
remote: dispatch.run()
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 99, in run
remote: status = dispatch(req)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 225, in dispatch
remote: ret = _runcatch(req) or 0
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 376, in _runcatch
remote: return _callcatch(ui, _runcatchfunc)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 384, in _callcatch
remote: return scmutil.callcatch(ui, func)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/scmutil.py", line 166, in callcatch
remote: return func()
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 367, in _runcatchfunc
remote: return _dispatch(req)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 1021, in _dispatch
remote: cmdpats, cmdoptions)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 756, in runcommand
remote: ret = _runcommand(ui, options, cmd, d)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 1030, in _runcommand
remote: return cmdfunc()
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/dispatch.py", line 1018, in <lambda>
remote: d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/util.py", line 1670, in check
remote: return func(*args, **kwargs)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/commands.py", line 5257, in serve
remote: s.serve_forever()
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/wireprotoserver.py", line 797, in serve_forever
remote: self.serveuntil(threading.Event())
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/wireprotoserver.py", line 804, in serveuntil
remote: _runsshserver(self._ui, self._repo, self._fin, self._fout, ev)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/wireprotoserver.py", line 656, in _runsshserver
remote: rsp = wireprotov1server.dispatch(repo, proto, request)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/wireprotov1server.py", line 74, in dispatch
remote: return func(repo, proto, *args)
remote: File "/tmp/hgtests.i66Npc/install/lib/python/mercurial/wireprotov1server.py", line 195, in batch
remote: data[k] = vals[k]
remote: KeyError: 'namespace'
abort: unexpected response: empty string
[255]
Differential Revision: https://phab.mercurial-scm.org/D5482
rust: core implementation for lazyancestors
Once exposed through appropriate bindings, this
should be able to replace ancestor.lazyancestors
entirely.
Differential Revision: https://phab.mercurial-scm.org/D5440