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.
Thu, 19 Mar 2015 23:36:05 +0900 bookmarks: remove useless diff()
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 Mar 2015 23:36:05 +0900] rev 24399
bookmarks: remove useless diff() Previous patches removed code paths referring it.
Thu, 19 Mar 2015 23:36:05 +0900 bookmarks: add outgoing() to replace diff() for outgoing bookmarks
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 Mar 2015 23:36:05 +0900] rev 24398
bookmarks: add outgoing() to replace diff() for outgoing bookmarks This replacement makes enhancement of "show outgoing bookmarks" easy, because "compare()" can detect more detailed difference of bookmarks between two repositories.
Thu, 19 Mar 2015 23:36:05 +0900 bookmarks: add incoming() to replace diff() for incoming bookmarks
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 Mar 2015 23:36:05 +0900] rev 24397
bookmarks: add incoming() to replace diff() for incoming bookmarks This replacement makes enhancement of "show incoming bookmarks" easy, because "compare()" can detect more detailed difference of bookmarks between two repositories.
Wed, 18 Mar 2015 15:59:45 -0700 manifest: avoid intersectfiles for matches > 100 files
Durham Goode <durham@fb.com> [Wed, 18 Mar 2015 15:59:45 -0700] rev 24396
manifest: avoid intersectfiles for matches > 100 files Previously we tried to avoid manifest.intersectfiles for exact matches with less than 100 files. However, when the left side of the "or" is false, the right side gets evaluated, of course, and the evaluation of "util.all(fn in self for fn in files)" is both costly in itself, and likely to be true, causing intersectfiles() to be called after all. Fix this by moving the check for less than 100 files outside of the "or" expression, thereby also making it apply for a non-exact matcher, should one be passed in.
Thu, 19 Mar 2015 17:40:19 +0100 convert: optimize convert of files that are unmodified from p2 in merges
Mads Kiilerich <madski@unity3d.com> [Thu, 19 Mar 2015 17:40:19 +0100] rev 24395
convert: optimize convert of files that are unmodified from p2 in merges Conversion of a merge starts with p1 and re-adds the files that were changed in the merge or came unmodified from p2. Files that are unmodified from p1 will thus not be touched and take no time. Files that are unmodified from p2 would be retrieved and rehashed. They would end up getting the same hash as in p2 and end up reusing the filelog entry and look like the p1 case ... but it was slow. Instead, make getchanges also return 'files that are unmodified from p2' so the sink can reuse the existing p2 entry instead of calling getfile. Reuse of filelog entries can make a big difference when files are big and with long revlong chains so they take time to retrieve and hash, or when using an expensive custom getfile function (think http://mercurial.selenic.com/wiki/ConvertExtension#Customization with a code reformatter). This in combination with changes to reuse filectx entries in localrepo._filecommit make 'unchanged from p2' almost as fast as 'unchanged from p1'. This is so far only implemented for the combination of hg source and hg sink. This is a refactoring/optimization. It is covered by existing tests and show no changes - which is a good thing.
Thu, 19 Mar 2015 17:36:17 +0100 localrepo: reuse commit of parent filectx entries without rehashing
Mads Kiilerich <madski@unity3d.com> [Thu, 19 Mar 2015 17:36:17 +0100] rev 24394
localrepo: reuse commit of parent filectx entries without rehashing It is currently only amend and debugbuilddag that will pass a filectx to localrepo._filecommit. Amend will usually not hit the case where a the filectx is a parent that just can be reused. Future convert changes will use it more.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip