Wed, 28 Feb 2018 10:32:00 -0800 narrow: reduce depedence on narrowspec.save()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 28 Feb 2018 10:32:00 -0800] rev 36499
narrow: reduce depedence on narrowspec.save() I think narrowspec should be a simple, low-level module and not depend on the hg module. This prepares for moving that dependency out of narrowspec. Differential Revision: https://phab.mercurial-scm.org/D2492
Wed, 28 Feb 2018 12:55:05 -0800 narrow: always wrap repo
Martin von Zweigbergk <martinvonz@google.com> [Wed, 28 Feb 2018 12:55:05 -0800] rev 36498
narrow: always wrap repo It's simpler to always wrap the repo. This prepares for moving narrowrepo.narrowmatch() onto localrepo by showing that it's now safe to always wrap the repo (and thus always define narrowmatch() etc.). Note that since narrowmatch() returns an always-matcher (rather than None) in non-narrow repos, this may mean a performance hit when the narrow extension is enabled because it adds a no-op filtering step in various places against the always-matcher. I'll restore some of that soon. Differential Revision: https://phab.mercurial-scm.org/D2491
Wed, 28 Feb 2018 10:29:04 -0800 narrow: consider both local and remote matchers in narrowchangegroup
Martin von Zweigbergk <martinvonz@google.com> [Wed, 28 Feb 2018 10:29:04 -0800] rev 36497
narrow: consider both local and remote matchers in narrowchangegroup The existing code that picked one or the other seemed very suspicious. This patch makes us intersect the local matcher with the matcher from the remote, which seems better. It fixes one test case and makes another one that used to crash no longer crash, but instead silently succeed with a push that's lossy, so that remains to be fixed. The real reason for doing this now is that I'm going to move narrowrepo.narrowmatch() onto localrepo and then it will always be defined, which would otherwise break this code. Differential Revision: https://phab.mercurial-scm.org/D2490
Wed, 28 Feb 2018 10:22:54 -0800 narrow: move checking for narrow requirement into _narrowmatch()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 28 Feb 2018 10:22:54 -0800] rev 36496
narrow: move checking for narrow requirement into _narrowmatch() We want to move narrowmatch() and others into core, so we need to get rid of the dependence on the "narrow_opts" from the closure in narrowrepo.wraprepo(). We can simply check if the narrow requirement is set. I think that seems like an improvement regardless of moving narrowmatch(). Differential Revision: https://phab.mercurial-scm.org/D2489
Wed, 28 Feb 2018 10:55:21 -0800 narrow: move changegroup.supportedoutgoingversions() override to core
Martin von Zweigbergk <martinvonz@google.com> [Wed, 28 Feb 2018 10:55:21 -0800] rev 36495
narrow: move changegroup.supportedoutgoingversions() override to core Also document why we need cg3 or higher. Differential Revision: https://phab.mercurial-scm.org/D2488
Wed, 28 Feb 2018 10:21:43 -0800 narrow: move requirement constant to core
Martin von Zweigbergk <martinvonz@google.com> [Wed, 28 Feb 2018 10:21:43 -0800] rev 36494
narrow: move requirement constant to core My short-term goal is to move narrowrepo.narrowmatch() onto localrepo and this is a necessary step for that. I put the constant in changegroup.py, unlike REVLOGV2_REQUIREMENT, which is in localrepo.py, since we'll need to access it from the changegroup module eventually. Differential Revision: https://phab.mercurial-scm.org/D2487
Wed, 21 Feb 2018 14:36:42 +0530 remotenames: don't inherit the remotenames class from dict class
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 21 Feb 2018 14:36:42 +0530] rev 36493
remotenames: don't inherit the remotenames class from dict class The remotenames class was moved from hgremotenames extension. The class in hgremotenames extension used to extend dict because updating bookmark was done through a dict-like interface or Sean (smf) wanted it to be that way. But now, we can remove the inheritance from the dict class as updating bookmark is not done using a dict-like interface. Thanks to Martin von Zweigbergk for spotting this. Differential Revision: https://phab.mercurial-scm.org/D2361
Sun, 25 Feb 2018 17:22:25 -0500 run-tests: cache hghave results
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Feb 2018 17:22:25 -0500] rev 36492
run-tests: cache hghave results Spawning a process on Windows is expensive. I've got a version of test-lfs-test-server.t locally which prints the http request/responses that totals 819 lines, with 149 conditional lines, 11 #if tests, and 2 test cases. It takes just under 1 minute with this change to run both cases, vs just over 2 minutes without this change. Worse, when I explored adding ui.debug to the test, it takes 13 minutes due to all of the mismatches and retests, vs less than 1 minute with this change. Overall, the difference when running all tests is negligible- 103 minutes with this change, vs 105 without when using -j9. It also looks like an exit value of 2 from `hghave` is treated specially, but there's nothing preventing 2 missing features from also using this value.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip