Mon, 29 May 2017 05:57:03 -0700 copies: add dstctx parameter
Stanislau Hlebik <stash@fb.com> [Mon, 29 May 2017 05:57:03 -0700] rev 32562
copies: add dstctx parameter Add parameter with destination context
Mon, 29 May 2017 05:56:17 -0700 copies: rename ctx to srcctx
Stanislau Hlebik <stash@fb.com> [Mon, 29 May 2017 05:56:17 -0700] rev 32561
copies: rename ctx to srcctx In the next diff we'll pass new dstctx parameter. Let's rename ctx to srcctx in this patch.
Mon, 29 May 2017 05:52:15 -0700 copies: rename m2 to mdst
Stanislau Hlebik <stash@fb.com> [Mon, 29 May 2017 05:52:15 -0700] rev 32560
copies: rename m2 to mdst Small refactoring to rename m2 to more clearer mdst.
Mon, 29 May 2017 05:52:15 -0700 copies: rename m1 to msrc
Stanislau Hlebik <stash@fb.com> [Mon, 29 May 2017 05:52:15 -0700] rev 32559
copies: rename m1 to msrc Small refactoring that renames `m1` parameter name to a more clearer name `msrc`.
Fri, 26 May 2017 13:27:21 -0700 transaction: delete callbacks after use
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 26 May 2017 13:27:21 -0700] rev 32558
transaction: delete callbacks after use Before this change, localrepository instances that performed multiple transactions would leak transaction objects. This could occur when running `hg convert`. When running `hg convert`, the leak would be ~90 MB per 10,000 changesets as measured with the Mercurial repo itself. The leak I tracked down involved the "validate" closure from localrepository.transaction(). It appeared to be keeping a reference to the original transaction via __closure__. __del__ semantics and a circular reference involving the repo object may have also come into play. Attempting to refactor the "validate" closure proved to be difficult because the "tr" reference in that closure may reference an object that isn't created until transaction.__init__ is called. And the "validate" closure is passed as an argument to transaction.__init__. Plus there is a giant warning comment in "validate" about how hacky it is. I did not want to venture into the dragon den. Anyway, we've had problems with transactions causing leaks before. The solution then (14e683d6b273) is the same as the solution in this patch: drop references to callbacks after they are called. This not only breaks cycles in core Mercurial but can help break cycles in extensions that accidentally introduce them. While I only tracked down a leak due to self.validator, since this is the 2nd time I've tracked down leaks due to transaction callbacks I figure enough is enough and we should prevent the class of leak from occurring regardless of the variable. That's why all callback variables are now nuked.
Fri, 19 May 2017 13:16:15 -0700 match: remove special-casing of always-matching patterns in patternmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 13:16:15 -0700] rev 32557
match: remove special-casing of always-matching patterns in patternmatcher This moves the optimization for patterns that match everything to the caller, so we can remove it from patternmatcher. Note that we need to teach alwaysmatcher to use relative paths now in cases like "hg files .." from inside mercurial/, because while it still matches everything, paths should be printed relative to the working directory.
Fri, 19 May 2017 12:47:45 -0700 match: move normalize() call out of matcher constructors
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 12:47:45 -0700] rev 32556
match: move normalize() call out of matcher constructors By passing in the result of the normalize() call, we prepare for moving the special handling of patterns that always match out of the patternmatcher. It also lets us remove many of the arguments from the matcher, because they were passed only the the normalize function (we could have removed the arguments by binding them to the function instead of moving the normalize() call out).
Fri, 19 May 2017 11:58:16 -0700 match: drop support for empty pattern list in patternmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 11:58:16 -0700] rev 32555
match: drop support for empty pattern list in patternmatcher Since the caller now deals with empty pattern lists, we can drop that support in the patternmatcher. It now gets the more logical behavior of matching nothing when no patterns are given (although there is no in-core caller that will pass no patterns).
Sat, 20 May 2017 23:49:14 -0700 match: optimize visitdir() for when no explicit files are listed
Martin von Zweigbergk <martinvonz@google.com> [Sat, 20 May 2017 23:49:14 -0700] rev 32554
match: optimize visitdir() for when no explicit files are listed In patternmatcher, we used to say that all directories should be visited if no explicit files were listed, because the case of empty _files usually implied that no patterns were given (which in turns meant that everything should match). However, this made e.g. "hg files -r . rootfilesin:." slower than necessary, because that also ended up with an empty list in _files. Now that patternmatcher does not handle includes, the only remaining case where its _files/_fileset fields will be empty is when it's matching everything. We can therefore treat the always-case specially and stop treating the empty _files case specially. This makes the case mentioned above faster on treemanifest repos.
Fri, 19 May 2017 11:50:01 -0700 match: handle everything-matching using new alwaysmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 11:50:01 -0700] rev 32553
match: handle everything-matching using new alwaysmatcher Having a special matcher that always matches seems to make more sense than making one of the other matchers handle the case. For now, we just use this new matcher when no patterns were provided.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip