Thu, 06 Jul 2017 17:41:45 -0700 sparse: move function for resolving sparse matcher into core
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 17:41:45 -0700] rev 33320
sparse: move function for resolving sparse matcher into core As part of the move, the function arguments changed so revs are passed as a list instead of *args. This allows us to use keyword arguments properly. Since the plan is to integrate sparse into core and have it enabled by default, we need to prepare for a sparse matcher to always be obtained and operated on. As part of the move, we inserted code that returns an always matcher if sparse isn't enabled. Some callers in the sparse extension take this into account and conditionally perform matching depending on whether the special always matcher is seen. I /think/ this may have sped up some operations where the extension is installed but no sparse config is activated. One thing I'm ensure of in this code is whether os.path.dirname() is semantically correct. os.posixpath.dirname() (which is exported as pathutil.dirname) might be a better choise because all patterns should be using posix directory separators (/) instead of Windows (\). There's an inline comment that implies Windows was tested. So hopefully it won't be a problem. We can improve this in a follow-up. I've added a TODO to track it.
Thu, 06 Jul 2017 17:39:24 -0700 match: move matchers from sparse into core
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 17:39:24 -0700] rev 33319
match: move matchers from sparse into core The sparse extension contains some matcher types that are generic and can exist in core. As part of the move, the classes now inherit from basematcher. always(), files(), and isexact() have been dropped because they match the default implementations in basematcher.
Thu, 06 Jul 2017 16:01:36 -0700 sparse: clean up config signature code
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 16:01:36 -0700] rev 33318
sparse: clean up config signature code Before, 0 was being used as the default signature value and we cast the int to a string. We also handled I/O exceptions manually. The new code uses cfs.tryread() so we always feed data into the hasher. The empty string does hash and and should be suitable for input into a cache key. The changes made the code simple enough that the separate checksum function could be inlined.
Thu, 06 Jul 2017 16:11:56 -0700 sparse: move config signature logic into core
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 16:11:56 -0700] rev 33317
sparse: move config signature logic into core This is a pretty straightforward port. It will be cleaned up in a subsequent commit.
Thu, 06 Jul 2017 17:31:33 -0700 sparse: remove custom hash matcher
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 17:31:33 -0700] rev 33316
sparse: remove custom hash matcher With the recent change to always use repr(), this function was functionally identical to the version in fsmonitor it was replacing. So remove it.
Thu, 06 Jul 2017 16:37:36 -0700 sparse: override __repr__ in matchers
Martin von Zweigbergk <martinvonz@google.com> [Thu, 06 Jul 2017 16:37:36 -0700] rev 33315
sparse: override __repr__ in matchers sparse.py in FB's hg-experimental repo switched to using __repr__ for non-sparse matchers soon after hg core started overriding __repr__ in the matchers in match.py (because the core matchers also stopped having "includepat" and other attributes that sparse used to depend on). Let's finish that migration by implementing __repr__ in the sparse matchers as well. That also lets us remove the special handling of them in _hashmatcher().
Thu, 06 Jul 2017 14:17:02 -0700 tests: fix reference to undefined variable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 06 Jul 2017 14:17:02 -0700] rev 33314
tests: fix reference to undefined variable The delaypush() function had a reference to "repo" that was clearly supposed to be "pushop.repo". Instead of just fixing that, let's extract "pushop.repo.ui" to a variable, since that's the only piece of the repo that's needed in the function. I have not looked into why I saw a different result in the test to start with, but that's for another patch anyway.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip