Thu, 16 Aug 2018 19:40:46 +0000 dagutil: remove externalize() and externalizeall()
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 19:40:46 +0000] rev 39193
dagutil: remove externalize() and externalizeall() They are unused after the previous commit. .. api:: externalize() and externalizeall() removed from dagutil Use .node() on a storage primitive to perform revision to node conversions. Differential Revision: https://phab.mercurial-scm.org/D4305
Thu, 16 Aug 2018 19:39:47 +0000 setdiscovery: don't use dagutil for rev -> node conversions
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 19:39:47 +0000] rev 39192
setdiscovery: don't use dagutil for rev -> node conversions We don't need to use dagutil to perform a simple rev -> node conversion. I haven't measured, but the new code is likely faster, as we avoid extra function calls and avoid some attribute lookups. Differential Revision: https://phab.mercurial-scm.org/D4304
Thu, 16 Aug 2018 19:23:24 +0000 exchange: don't use dagutil
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 19:23:24 +0000] rev 39191
exchange: don't use dagutil We were only using it for simple node -> rev and parent revision lookups. These are exposed via the storage interface and we don't need to go through dagutil. Differential Revision: https://phab.mercurial-scm.org/D4303
Fri, 20 Jul 2018 13:20:01 +0200 revlog: only consider the span of the delta section
Paul Morelle <paul.morelle@octobus.net> [Fri, 20 Jul 2018 13:20:01 +0200] rev 39190
revlog: only consider the span of the delta section Since the number of snapshots is limited we can exclude them from the logic checking size and number of reads. Limiting the span computation to the delta section will allow for further optimization.
Mon, 23 Jul 2018 16:21:58 +0200 revlog: ensure intermediate snapshot have decreasing size
Boris Feld <boris.feld@octobus.net> [Mon, 23 Jul 2018 16:21:58 +0200] rev 39189
revlog: ensure intermediate snapshot have decreasing size If the intermediate snapshot is bigger than the previous one, there is likely a better snapshot to be made at a different level.
Wed, 07 Mar 2018 12:28:04 +0100 revlog: bound number of snapshots in a chain
Paul Morelle <paul.morelle@octobus.net> [Wed, 07 Mar 2018 12:28:04 +0100] rev 39188
revlog: bound number of snapshots in a chain To limit the number of snapshot chained, we enforce them to be smaller and smaller. This guarantee the number of snapshot in a chain will be bounded to a small number.
Fri, 20 Jul 2018 14:32:56 +0200 revlog: compute snapshot depth on delta info
Boris Feld <boris.feld@octobus.net> [Fri, 20 Jul 2018 14:32:56 +0200] rev 39187
revlog: compute snapshot depth on delta info We need the information to be available when choosing delta.
Wed, 15 Aug 2018 12:30:30 +0200 debugrevlog: display snapshot details per depth
Boris Feld <boris.feld@octobus.net> [Wed, 15 Aug 2018 12:30:30 +0200] rev 39186
debugrevlog: display snapshot details per depth This help in understanding the final structure of build manifest. All data about snapshot (full and intermediate) are gathered into a sub-list for clarity. Since we do not produce such snapshots yet, the only thing changing in test output is the way the information is presented.
Wed, 15 Aug 2018 12:09:14 +0200 revlog: add a method to retrieve snapshot depth
Boris Feld <boris.feld@octobus.net> [Wed, 15 Aug 2018 12:09:14 +0200] rev 39185
revlog: add a method to retrieve snapshot depth Some snapshot property (eg: maximum size) will depend on their depth.
Fri, 27 Jul 2018 10:52:43 +0200 debugrevlog: include information about intermediate snapshots
Boris Feld <boris.feld@octobus.net> [Fri, 27 Jul 2018 10:52:43 +0200] rev 39184
debugrevlog: include information about intermediate snapshots As we are about to create intermediate snapshots, we need to have a way to debug them. We start by adding very simple debug output and more detailed output will comes in next changesets.
Fri, 20 Jul 2018 13:34:48 +0200 revlog: also detect intermediate snapshots
Paul Morelle <paul.morelle@octobus.net> [Fri, 20 Jul 2018 13:34:48 +0200] rev 39183
revlog: also detect intermediate snapshots Also detect intermediate-snapshot done against another previous snapshot. Doing an intermediate snapshot instead of a full one can reduce the number of full snapshots we need. They are especially useful for content with a lot of churn on the same line (eg: the manifest) where having a delta over multiple revisions can end up being significantly smaller than the sum of these revision deltas. A revlog built using intermediate snapshots can be a bit smaller and reuse snapshot much more efficiently. This last property is useful combined with constraints on chain length. Using intermediate snapshot can produce repository with delta chain ten times shorter without impact on the storage size. Shorter chain lengths are faster to restore, greatly improving read performance. This changesets (and the following ones) focus on getting the core principle of intermediate snapshots into Mercurial core. Later changeset will introduce the strategy to create them.
Fri, 20 Jul 2018 13:32:17 +0200 revlog: add a method to tells whether rev is stored as a snapshot
Paul Morelle <paul.morelle@octobus.net> [Fri, 20 Jul 2018 13:32:17 +0200] rev 39182
revlog: add a method to tells whether rev is stored as a snapshot For now we only have one type of snapshot: full snapshot versus nullrev. However we are looking into adding intermediate snapshot where a large diff against another snapshot is performed instead of storing a full new text. The conditional is a bit strange and is done in order to help readability of a some later changesets.
Wed, 15 Aug 2018 15:20:44 +0200 debugrevlog: fix for non-manifest object
Boris Feld <boris.feld@octobus.net> [Wed, 15 Aug 2018 15:20:44 +0200] rev 39181
debugrevlog: fix for non-manifest object The `filelog` object is no longer an actual revlog. Instead, the actual revlog is stored in the `_revlog` attribute.
Fri, 17 Aug 2018 16:11:35 -0700 merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 17 Aug 2018 16:11:35 -0700] rev 39180
merge with stable
Fri, 17 Aug 2018 15:32:38 -0700 nodes: expand/comment the magic nodes so they are more easily searchable
Kyle Lippincott <spectral@google.com> [Fri, 17 Aug 2018 15:32:38 -0700] rev 39179
nodes: expand/comment the magic nodes so they are more easily searchable We just encountered `000000000000modified`, and it was quite annoying to search for these, even though I knew they existed. For those that don't know that they exist, this is essentially impossible to search for :) (Technically we encountered it in its hex form, 3030303030303030303030306d6f646966696564, so I'm adding comments with those forms in case that's helpful to people in the future). Differential Revision: https://phab.mercurial-scm.org/D4331
Fri, 17 Aug 2018 13:07:33 +0900 revlog: obtain the first node at the lowest layer while building pure nodemap
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 13:07:33 +0900] rev 39178
revlog: obtain the first node at the lowest layer while building pure nodemap Just for clarity. This doesn't matter in practice since changelog.nodemap is accessed *before* filtered revisions get ready.
Fri, 17 Aug 2018 12:54:50 +0900 revlog: fix pure nodemap to not access missing index entry
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 12:54:50 +0900] rev 39177
revlog: fix pure nodemap to not access missing index entry This bug was revealed by a3dacabd476b and a1f934573c0b.
Fri, 17 Aug 2018 12:48:44 +0900 changelog: remove copy of revlog.nodemap()
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 12:48:44 +0900] rev 39176
changelog: remove copy of revlog.nodemap() It's been there since 2012, "clfilter: introduce `filteredrevs` attribute on changelog." I don't think we can apply changelog filtering to nodemap at this level, so this patch removes the nodemap stub completely.
Fri, 17 Aug 2018 10:51:05 +0900 branchmap: explicitly convert file into iterator
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:51:05 +0900] rev 39175
branchmap: explicitly convert file into iterator Follows up 2a4bfbb52111. This is required for httprangereader, which is not an iterable itself.
Fri, 17 Aug 2018 10:25:39 +0900 branchmap: close cache file properly
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:25:39 +0900] rev 39174
branchmap: close cache file properly Follows up 2a4bfbb52111.
Fri, 17 Aug 2018 10:24:29 +0900 branchmap: strip '\n' read from cache file as before
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:24:29 +0900] rev 39173
branchmap: strip '\n' read from cache file as before Follows up 2a4bfbb52111.
Fri, 17 Aug 2018 10:21:25 +0900 rebase: do not pass in user option to rollback in-memory merge conflict
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:21:25 +0900] rev 39172
rebase: do not pass in user option to rollback in-memory merge conflict Nothing passed before e9e742bd0501.
Fri, 17 Aug 2018 10:19:17 +0900 rebase: add test for in-memory merge conflicts
Yuya Nishihara <yuya@tcha.org> [Fri, 17 Aug 2018 10:19:17 +0900] rev 39171
rebase: add test for in-memory merge conflicts
Thu, 16 Aug 2018 18:53:51 +0000 rebase: call _dorebase() properly
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 18:53:51 +0000] rev 39170
rebase: call _dorebase() properly This fixes a regression from e9e742bd0501 where we failed to pass all necessary arguments to _dorebase(). Differential Revision: https://phab.mercurial-scm.org/D4302
Thu, 16 Aug 2018 16:59:40 +0300 context: make sure file is not deleted while checking path conflicts
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 16 Aug 2018 16:59:40 +0300] rev 39169
context: make sure file is not deleted while checking path conflicts If a file is deleted and a directory of same name is created in the same commit, IMM thinks of that as a file conflict, however the file is deleted and hence the directory can be created. The test change demonstrate the fix. Differential Revision: https://phab.mercurial-scm.org/D4300
Thu, 16 Aug 2018 16:53:48 +0300 tests: demonstrate that IMM needs to be smarter with path conflicts
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 16 Aug 2018 16:53:48 +0300] rev 39168
tests: demonstrate that IMM needs to be smarter with path conflicts When we try to rebase a commit which deletes an existing file and make a directory of the same name, rebase with IMM aborts. It should work fine just like the without IMM case. Differential Revision: https://phab.mercurial-scm.org/D4299
Thu, 16 Aug 2018 16:36:32 +0300 tests: don't create new repo inside existing repo in test-rebase-inmemory.t
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 16 Aug 2018 16:36:32 +0300] rev 39167
tests: don't create new repo inside existing repo in test-rebase-inmemory.t Differential Revision: https://phab.mercurial-scm.org/D4298
Wed, 25 Jul 2018 13:40:42 -0400 tests: remove test-py3-commands.t
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:40:42 -0400] rev 39166
tests: remove test-py3-commands.t This was a smoke test for early in the Python 3 porting effort, before anything actually worked. Now that we've got over half the testsuite passing, this test has outlived its utility. Differential Revision: https://phab.mercurial-scm.org/D4288
Wed, 25 Jul 2018 13:41:21 -0400 tests: update test-check-py3-compat.t output in the py3exe branch
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:41:21 -0400] rev 39165
tests: update test-check-py3-compat.t output in the py3exe branch This hasn't been maintained in a while, it looks like. Differential Revision: https://phab.mercurial-scm.org/D4289
Wed, 15 Aug 2018 17:40:21 -0700 overlayworkingctx: fix exception in metadata-only inmemory merges (issue5960)
Kyle Lippincott <spectral@google.com> [Wed, 15 Aug 2018 17:40:21 -0700] rev 39164
overlayworkingctx: fix exception in metadata-only inmemory merges (issue5960) If there was a metadata-only mutation, such as +x or -x on a file, we would create a cache entry with None for data, and this would cause problems later on when some code tried to run fctx.data() or similar, and was expecting a string. My original fix for this involved passing data=self._wrappedctx[path].data() in setflags(), but this version seems slightly better - this way, if we ever call write() and then call setflags(), we don't destroy the data that we wrote that's in the cache. I haven't verified that other fields aren't destroyed, such as date or flags :) Differential Revision: https://phab.mercurial-scm.org/D4287
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip