Tue, 08 Mar 2016 23:04:53 +0900 registrar: introduce new class for registration to replace funcregistrar
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 08 Mar 2016 23:04:53 +0900] rev 28392
registrar: introduce new class for registration to replace funcregistrar _funcregistrarbase differs from funcregistrar in points below: - every code paths should use same class derived from _funcregistrarbase to register functions in a same category funcregistrar expects (3rd party) extensions to use (a class derived from) delayregistrar. - actual extra setup should be executed in another function For example, marking revset predicate as "safe" is executed in a class derived from _funcregistrarbase, but putting name of "safe" predicate into safesymbols is executed in another function for it. funcregistrar expects derived classes to do so. New class is named as module private one, because code paths, which register functions, should use not it directly but one derived from it.
Tue, 08 Mar 2016 23:04:53 +0900 dispatch: make loading extra information from extension extensible
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 08 Mar 2016 23:04:53 +0900] rev 28391
dispatch: make loading extra information from extension extensible This patch makes loading extra information from extension module at dispatching extensible. Factoring 'loadcmdtable()' into commands.py is a part of generalization of loading extra information. This extensibility assumes registration of new function like below, for example: - revset predicate - fileset predicate - template keyword - template filter - template function - internal merge tool - web command This patch requires not loader function itself but container module and the name of it, because listing loader function directly up implies actual loading module of it, even if it isn't used at runtime (for example, extensions don't always define revset predicate)
Thu, 04 Feb 2016 15:38:04 -0800 obsolete: fix n^2 marker computation behavior stable
Durham Goode <durham@fb.com> [Thu, 04 Feb 2016 15:38:04 -0800] rev 28390
obsolete: fix n^2 marker computation behavior Previously, if you ran obsolete.createmarkers with a bunch of markers that did not have successors (like when you do a prune), it encountered a n^2 computation behavior because the loop would read the changelog (to get ctx.parents()), then add a marker, in a loop. Adding a marker invalidated the computehidden cache, and reading the changelog recomputed it. This resulted in pruning 150 commits taking 150+ seconds in a large repo. The fix is to break the reading part of the loop to be separate from the writing part.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip