Thu, 27 Dec 2018 21:27:43 -0500 largefiles: port revset registration to exthelper
Matt Harbison <matt_harbison@yahoo.com> [Thu, 27 Dec 2018 21:27:43 -0500] rev 41067
largefiles: port revset registration to exthelper This tests the merge code that wasn't tested in the previous patch.
Thu, 27 Dec 2018 21:26:17 -0500 exthelper: reintroduce the ability to register revsets
Matt Harbison <matt_harbison@yahoo.com> [Thu, 27 Dec 2018 21:26:17 -0500] rev 41066
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
Sun, 23 Dec 2018 23:01:51 -0500 largefiles: drop the uisetup module
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Dec 2018 23:01:51 -0500] rev 41065
largefiles: drop the uisetup module This is small enough to live in the __init__ module.
Mon, 24 Dec 2018 17:04:37 +0530 branches: add -r option to show branch name(s) of a given rev (issue5948)
Navaneeth Suresh <navaneeths1998@gmail.com> [Mon, 24 Dec 2018 17:04:37 +0530] rev 41064
branches: add -r option to show branch name(s) of a given rev (issue5948) Differential Revision: https://phab.mercurial-scm.org/D5486
Mon, 10 Dec 2018 20:06:58 +0000 progress: avoid ui.configbool() lookup when progress bar is active
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 10 Dec 2018 20:06:58 +0000] rev 41063
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
Sun, 23 Dec 2018 22:57:03 -0500 largefiles: port wrapped functions to exthelper
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Dec 2018 22:57:03 -0500] rev 41062
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.
Sun, 23 Dec 2018 17:26:25 -0500 largefiles: port commands to exthelper
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Dec 2018 17:26:25 -0500] rev 41061
largefiles: port commands to exthelper One subtle change here is that the purge, rebase and transplant extensions are wrapped in extsetup() instead of uisetup().
Sun, 23 Dec 2018 21:54:56 -0500 exthelper: support the option argument when registering a command
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Dec 2018 21:54:56 -0500] rev 41060
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.
Sun, 23 Dec 2018 16:16:13 -0500 largefiles: port configitems to exthelper
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Dec 2018 16:16:13 -0500] rev 41059
largefiles: port configitems to exthelper It looks like dynamicdefault was referenced in a non-standard way.
Sun, 23 Dec 2018 15:18:38 -0500 remotefilelog: use repo.local() instead of isinstance()
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Dec 2018 15:18:38 -0500] rev 41058
remotefilelog: use repo.local() instead of isinstance()
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip