Thu, 19 Mar 2015 23:57:34 -0700 adjustlinkrev: handle 'None' value as source stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 19 Mar 2015 23:57:34 -0700] rev 24411
adjustlinkrev: handle 'None' value as source When the source rev value is 'None', the ctx is a working context. We cannot compute the ancestors from there so we directly skip to its parents. This will be necessary to allow 'None' value for '_descendantrev' itself necessary to make all contexts used in 'mergecopies' reuse the same '_ancestrycontext'.
Thu, 19 Mar 2015 23:52:26 -0700 adjustlinkrev: prepare source revs for ancestry only once stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 19 Mar 2015 23:52:26 -0700] rev 24410
adjustlinkrev: prepare source revs for ancestry only once We'll need some more complex initialisation to handle workingfilectx case. We do this small change in a different patch for clarity.
Wed, 18 Mar 2015 22:56:41 -0400 subrepo: add the parent context to hgsubrepo
Matt Harbison <matt_harbison@yahoo.com> [Wed, 18 Mar 2015 22:56:41 -0400] rev 24409
subrepo: add the parent context to hgsubrepo This brings parity with gitsubrepo and svnsubrepo (which already reference their parent), and will be used in an upcoming patch. I'm a bit concerned that the parent context could get stale (consider what happens when the parent repo is reverted for example). I tried adding the parent context to the substate tuple so that the parent is available everywhere a state change is possible, but that made submerge() unhappy. Even with removing the parent context inside submerge(), I wasn't able to get all of the test diffs fixed. But since the other subrepos reference their parent too, if there is a problem, it is a preexisting one (that nobody seems to be running into). It can be fixed if/when it pops up.
Thu, 19 Mar 2015 21:26:18 -0700 fileset: add a fileset for portable filenames
Siddharth Agarwal <sid0@fb.com> [Thu, 19 Mar 2015 21:26:18 -0700] rev 24408
fileset: add a fileset for portable filenames This has mostly the same semantics as the files that the 'ui.portablefilenames' config option would warn or abort about. The only difference is filenames that case-fold to the same string -- given a set of filenames we've already checked we can check whether a new one collides with them, but we don't have a way to tell which filename it collided with.
Thu, 19 Mar 2015 19:52:23 -0700 annotate: reuse ancestry context when adjusting linkrev (issue4532) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 19 Mar 2015 19:52:23 -0700] rev 24407
annotate: reuse ancestry context when adjusting linkrev (issue4532) The linkrev adjustment will likely do the same ancestry walking multiple time so we already have an optional mechanism to take advantage of this. Since 2896f53509a7, linkrev adjustment was done lazily to prevent too bad performance impact on rename computation. However, this laziness created a quadratic situation in 'annotate'. Mercurial repo: hg annotate mercurial/commands.py before: 8.090 after: 36.300 Mozilla repo: hg annotate layout/generic/nsTextFrame.cpp before: 1.190 after: 290.230 So we setup sharing of the ancestry context in the annotate case too. Linkrev adjustment still have an impact but it a much more sensible one. Mercurial repo: hg annotate mercurial/commands.py before: 36.300 after: 10.230 Mozilla repo: hg annotate layout/generic/nsTextFrame.cpp before: 290.230 after: 5.560
Mon, 16 Mar 2015 16:01:16 -0700 treemanifest: make hasdir() faster
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Mar 2015 16:01:16 -0700] rev 24406
treemanifest: make hasdir() faster Same rationale as the previous change.
Tue, 03 Mar 2015 13:50:06 -0800 treemanifest: make filesnotin() faster
Martin von Zweigbergk <martinvonz@google.com> [Tue, 03 Mar 2015 13:50:06 -0800] rev 24405
treemanifest: make filesnotin() faster Same rationale as the previous change.
Thu, 19 Feb 2015 17:13:35 -0800 treemanifest: make diff() faster
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Feb 2015 17:13:35 -0800] rev 24404
treemanifest: make diff() faster Containment checking is slower in treemanifest than it is in manifestdict, making the current diff algorithm O(n log n). By traversing both treemanifests in parallel, we can make it O(n). More importantly, once we start lazily loading submanifests, we will be able to easily skip entire submanifest if they have the same nodeid.
Mon, 23 Feb 2015 10:57:57 -0800 treemanifest: store directory path in treemanifest nodes
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Feb 2015 10:57:57 -0800] rev 24403
treemanifest: store directory path in treemanifest nodes This leads to less concatenation while iterating, and it's useful for debugging.
Thu, 19 Mar 2015 11:07:57 -0700 treemanifest: add configuration for using treemanifest type
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Mar 2015 11:07:57 -0700] rev 24402
treemanifest: add configuration for using treemanifest type This change adds boolean configuration option experimental.treemanifest. When the option is enabled, manifests are parsed into the new treemanifest type. Tests can be now run using treemanifest by switching the config option default in localrepo._applyrequirements(). Tests pass even when made to randomly choose between manifestdict and treemanifest, suggesting that the two types produce identical manifests (so e.g. a manifest revlog entry written from a treemanifest can be parsed by the manifestdict code).
Thu, 19 Mar 2015 11:08:42 -0700 treemanifest: create treemanifest class
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Mar 2015 11:08:42 -0700] rev 24401
treemanifest: create treemanifest class There are a number of problems with large and flat manifests. Copying from http://mercurial.selenic.com/wiki/ManifestShardingPlan: * manifest too large for RAM * manifest resolution too much CPU (long delta chains) * committing is slow because entire manifest has to be hashed * impossible for narrow clone to leave out part of manifest as all is needed to calculate new hash * diffing two revisions involves traversing entire subdirectories even if identical This is a first step in a series introducing a manifest revlog per directory. This change adds a new manifest class: treemanifest, which is a tree where each node has a dict of files (nodeids), a dict of flags, and a dict of subdirectories (treemanifests). So far, it behaves just like manifestdict, but it will later help us write one manifest revlog per directory. The new class is still unused; it will be used after the next change. The code is not yet optimized. Running with it (see below) makes most or all operations slower. Once we start storing manifest revlogs for every directory, it should be possible to make many of these operations much faster. The fastdelta() optimization has been intentionally not implemented for the treemanifests. We can implement it later if necessary. All tests pass when run with the following patch (and without, of couse): --- a/mercurial/manifest.py Thu Mar 19 11:08:42 2015 -0700 +++ b/mercurial/manifest.py Thu Mar 19 11:15:50 2015 -0700 @@ -596,7 +596,7 @@ class manifest(revlog.revlog): return None, None def add(self, m, transaction, link, p1, p2, added, removed): - if p1 in self._mancache: + if False and p1 in self._mancache: # If our first parent is in the manifest cache, we can # compute a delta here using properties we know about the # manifest up-front, which may save time later for the @@ -626,3 +626,5 @@ class manifest(revlog.revlog): self._mancache[n] = (m, arraytext) return n + +manifestdict = treemanifest
Thu, 19 Mar 2015 23:36:06 +0900 bookmarks: rewrite comparing bookmarks in commands.summary() by compare()
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 Mar 2015 23:36:06 +0900] rev 24400
bookmarks: rewrite comparing bookmarks in commands.summary() by compare() This patch adds utility function "summary()", to replace comparing bookmarks in "commands.summary()". This replacement finishes centralizing the logic to compare bookmarks into "bookmarks.compare()". This patch also adds test to check summary output with incoming/outgoing bookmarks, because "hg summary --remote" is not tested yet on the repository with incoming/outgoing bookmarks. This test uses "(glob)" to ignore summary about incoming/outgoing changesets.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip