Mon, 10 Jul 2017 21:43:19 -0700 sparse: clean up updateconfig()
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 10 Jul 2017 21:43:19 -0700] rev 33375
sparse: clean up updateconfig() * Use context manager for wlock * Rename oldsparsematch to oldmatcher * Always call parseconfig() because parsing an empty string yields the same result as the old code
Mon, 10 Jul 2017 21:39:49 -0700 sparse: move config updating function into core
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 10 Jul 2017 21:39:49 -0700] rev 33374
sparse: move config updating function into core As part of the move, the ui argument was dropped. Additional fixups will be made in a follow-up commit.
Sat, 08 Jul 2017 16:18:04 -0700 dirstate: expose a sparse matcher on dirstate (API)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Jul 2017 16:18:04 -0700] rev 33373
dirstate: expose a sparse matcher on dirstate (API) The sparse extension performs a lot of monkeypatching of dirstate to make it sparse aware. Essentially, various operations need to take the active sparse config into account. They do this by obtaining a matcher representing the sparse config and filtering paths through it. The monkeypatching is done by stuffing a reference to a repo on dirstate and calling sparse.matcher() (which takes a repo instance) during each function call. The reason this function takes a repo instance is because resolving the sparse config may require resolving file contents from filelogs, and that requires a repo. (If the current sparse config references "profile" files, the contents of those files from the dirstate's parent revisions is resolved.) I seem to recall people having strong opinions that the dirstate object not have a reference to a repo. So copying what the sparse extension does probably won't fly in core. Plus, the dirstate modifications shouldn't require a full repo: they only need a matcher. So there's no good reason to stuff a reference to the repo in dirstate. This commit exposes a sparse matcher to dirstate via a property that when looked up will call a function that eventually calls sparse.matcher(). The repo instance is bound in a closure, so it isn't exposed to dirstate. This approach is functionally similar to what the sparse extension does today, except it hides the repo instance from dirstate. The approach is not optimal because we have to call a proxy function and sparse.matcher() on every property lookup. There is room to cache the matcher instance in dirstate. After all, the matcher only changes if the dirstate's parents change or if the sparse config changes. It feels like we should be able to detect both events and update the matcher when this occurs. But for now we preserve the existing semantics so we can move the dirstate sparseness bits into core. Once in core, refactoring becomes a bit easier since it will be clearer how all these components interact. The sparse extension has been updated to use the new property. Because all references to the repo on dirstate have been removed, the code for setting it has been removed.
Sat, 08 Jul 2017 15:42:11 -0700 sparse: use self instead of repo.dirstate
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Jul 2017 15:42:11 -0700] rev 33372
sparse: use self instead of repo.dirstate "self" here is the dirstate instance. I'm pretty confident that self and repo.dirstate will be the exact same object. So remove a dependency on repo by just looking at self.
Sat, 08 Jul 2017 14:15:07 -0700 sparse: move code for importing rules from files into core
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Jul 2017 14:15:07 -0700] rev 33371
sparse: move code for importing rules from files into core This is a pretty straightforward port. Some code cleanup was performed. But no major changes to the logic were made. I'm not a huge fan of this function because it does multiple things. I'd like to get things into core first to facilitate refactoring later. Please also note the added inline comment about the oddities of writeconfig() and the try..except to undo it. This is because of the hackiness in which the sparse matcher is obtained by various consumers, notably dirstate. We'll need a massive refactor to address this. That refactor is effectively blocked on having the sparse dirstate hacks live in core.
Sat, 08 Jul 2017 14:01:32 -0700 sparse: refactor activeprofiles into a generic function (API)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Jul 2017 14:01:32 -0700] rev 33370
sparse: refactor activeprofiles into a generic function (API) activeprofiles() is a special case of a more generic function. Furthermore, that generic function is essentially already implemented inline in the sparse extension. So, refactor activeprofiles() to a generic activeconfig(). Change the only consumer of activeprofiles() to use it. And have the inline implementation in the sparse extension use it.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip