Sun, 08 Oct 2017 22:22:27 +0200 configitems: register the 'experimental.effect-flags' config
Boris Feld <boris.feld@octobus.net> [Sun, 08 Oct 2017 22:22:27 +0200] rev 34827
configitems: register the 'experimental.effect-flags' config
Sun, 08 Oct 2017 20:37:13 +0200 configitems: register the full 'merge-tools' config and sub-options
Boris Feld <boris.feld@octobus.net> [Sun, 08 Oct 2017 20:37:13 +0200] rev 34826
configitems: register the full 'merge-tools' config and sub-options We register the merge-tools config section (which has an arbitrary base config value) and the possible sub-attribute. The sub-attribute has to be registered first or at the same time otherwise the '.*' item would shadow them. Merge tools could include "." in their name so we can't constrain any more than just ".*".
Sat, 14 Oct 2017 17:05:41 +0200 revlog-sparse-read: add a lower-threshold for read block size
Paul Morelle <paul.morelle@octobus.net> [Sat, 14 Oct 2017 17:05:41 +0200] rev 34825
revlog-sparse-read: add a lower-threshold for read block size The option experimental.sparse-read.min-block-size specifies the minimal size of a deltachain span, under which it won't be split by _slicechunk.
Tue, 10 Oct 2017 17:50:27 +0200 revlog: introduce an experimental flag to slice chunks reads when too sparse
Paul Morelle <paul.morelle@octobus.net> [Tue, 10 Oct 2017 17:50:27 +0200] rev 34824
revlog: introduce an experimental flag to slice chunks reads when too sparse Delta chains can become quite sparse if there is a lot of unrelated data between relevant pieces. Right now, revlog always reads all the necessary data for the delta chain in one single read. This can lead to a lot of unrelated data to be read (see issue5482 for more details). One can use the `experimental.maxdeltachainspan` option with a large value (or -1) to easily produce a very sparse delta chain. This change introduces the ability to slice the chunks retrieval into multiple reads, skipping large sections of unrelated data. Preliminary testing shows interesting results. For example the peak memory consumption to read a manifest on a large repository is reduced from 600MB to 250MB (200MB without maxdeltachainspan). However, the slicing itself and the multiple reads can have an negative impact on performance. This is why the new feature is hidden behind an experimental flag. Future changesets will add various parameters to control the slicing heuristics. We hope to experiment a wide variety of repositories during 4.4 and hopefully turn the feature on by default in 4.5. As a first try, the algorithm itself is prone to deep changes. However, we wish to define APIs and have a baseline to work on.
Mon, 09 Oct 2017 15:13:41 +0200 revlog: ignore empty trailing chunks when reading segments
Paul Morelle <paul.morelle@octobus.net> [Mon, 09 Oct 2017 15:13:41 +0200] rev 34823
revlog: ignore empty trailing chunks when reading segments When a merge commit creates an empty diff in the revlog, its offset may still be quite far from the end of the previous chunk. Skipping these empty chunks may reduce read size significantly. In most cases, there is no gain, and in some cases, little gain. On my clone of pypy, `hg manifest` reads 65% less bytes (96140 i/o 275943) for revision 4260 by ignoring the only empty trailing diff. For revision 2229, 35% (34557 i/o 53435) Sadly, this is difficult to reproduce, as hg clone can make its own different structure every time.
Wed, 20 Sep 2017 19:17:37 +0200 phase: isolate logic to update remote phrase through bundle2 pushkey
Boris Feld <boris.feld@octobus.net> [Wed, 20 Sep 2017 19:17:37 +0200] rev 34822
phase: isolate logic to update remote phrase through bundle2 pushkey Move the logic to build bundle2 pushkey part into its dedicated function. It will help to keep the logic clear when adding support for sending phases change using 'phase-heads' part.
Wed, 11 Oct 2017 07:40:00 +0200 phase: generate a push-race detection part on push
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 07:40:00 +0200] rev 34821
phase: generate a push-race detection part on push We are about to switch phase pushing from using pushkey to using a the new dedicated binary part. We introduce the push race detection on its own to help detect potential impact.
Wed, 11 Oct 2017 07:13:02 +0200 phase: introduce a new 'check:phases' part
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 07:13:02 +0200] rev 34820
phase: introduce a new 'check:phases' part This part checks if revisions are still in the same phase as when the bundle was generated. This is similar to what 'check:heads' or 'check:updated-heads' bundle2 part achieves for changesets. We needs seems before we can move away from pushkey usage from phase since pushkey has it own built-in push-race detection.
Wed, 11 Oct 2017 18:39:04 +0200 phase: gather remote phase information in a summary object
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 18:39:04 +0200] rev 34819
phase: gather remote phase information in a summary object We keep useful phase information around. The data will be reused with detecting push-race in later changesets.
Wed, 11 Oct 2017 18:39:34 +0200 phase: simplify the check for issue3781 shortcut in discovery
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 18:39:34 +0200] rev 34818
phase: simplify the check for issue3781 shortcut in discovery We'll rework the code around this check. Limiting the entanglement will help with later changesets
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip