Thu, 06 Jul 2017 14:53:08 -0700 sparse: move working directory refreshing into core
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 14:53:08 -0700] rev 33324
sparse: move working directory refreshing into core This is a pretty straightforward move of the code. I converted the "force" argument to a keyword argument. Like other recent changes, this code is tightly coupled with working directory update code in merge.py. I suspect the code will become more tightly coupled over time, possibly even moved to merge.py. For now, let's get the code in core.
Thu, 06 Jul 2017 16:29:31 -0700 sparse: refactor update actions filtering and call from core
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 16:29:31 -0700] rev 33323
sparse: refactor update actions filtering and call from core merge.calculateupdates() now filters the update actions through sparse by default. The filtering no-ops if sparse isn't enabled or no sparse config is defined. The function has been refactored to behave more like a filter instead of a wrapper of merge.calculateupdates(). We should arguably take sparse into account earlier in merge.calculateupdates(). This patch preserves the old behavior of applying sparse at the end of update calculation, which is the simplest and safest approach.
Thu, 06 Jul 2017 16:17:35 -0700 sparse: move update action filtering into core
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 16:17:35 -0700] rev 33322
sparse: move update action filtering into core This is a relatively straight port of the function. It is pretty large. So refactoring will be postponed to a subsequent commit.
Thu, 06 Jul 2017 14:33:18 -0700 sparse: move pruning of temporary includes into core
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 14:33:18 -0700] rev 33321
sparse: move pruning of temporary includes into core This was our last method on the custom repo type, meaning we could remove that custom type and inline the 2 lines of code into reposetup(). As part of the move, instead of wrapping merge.update() from the sparse extension, we inline the function call. The ported function now no-ops if sparse isn't enabled, making it safe to always call. The call site in update() may not be the most appropriate. But it matches the previous behavior, which is the safest thing to do. It can be improved later.
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().
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip