Tue, 23 Oct 2018 16:24:04 +0300 narrow: rework logic to check whether we need to widen and narrow
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 23 Oct 2018 16:24:04 +0300] rev 40436
narrow: rework logic to check whether we need to widen and narrow This patch reworks logic which calculates whether we need to extend or narrow our working copy or not. We filter the addincludes, removeincludes, addexcludes and removeexcludes passed from user to the actual added and removed includes and excludes. What that means is a user can pass an already included path as addincludes, a path which is not included as removeincludes etc. In such situations the old logic use to think we need to do some work, whereas we don't need to do that work. In old logic, even if we don't have anything new to include but it believes we need to call widen, this adds some good amount of work on large repository. A widen calls involves computing incomming csets, calling the narrow_widen() which in non-ellipses cases goes through all the set of csets which are available which can take ~2-3 mins on large repos. Those 2-3 minutes are spend on doing nothing which a client can prevent by checking is there really anything which needs to be included. The tests changes shows that we don't go to the server anymore in such cases which is nice. Differential Revision: https://phab.mercurial-scm.org/D5183
Tue, 23 Oct 2018 14:26:17 +0300 tests: show that adding an already included path still calls narrow_widen()
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 23 Oct 2018 14:26:17 +0300] rev 40435
tests: show that adding an already included path still calls narrow_widen() This patch adds tests demonstrating that we still go to the server in non-ellipses widening when we have that path already on the client and there is nothing new to download. The next patch will try to make client side logic smart and not go to the server if we don't need to download anything. Differential Revision: https://phab.mercurial-scm.org/D5182
Sun, 14 Oct 2018 17:08:18 +0200 graft: introduce --base option for using custom base revision while merging
Mads Kiilerich <mads@kiilerich.com> [Sun, 14 Oct 2018 17:08:18 +0200] rev 40434
graft: introduce --base option for using custom base revision while merging The graft command usually performs an internal merge of the current parent revision with the graft revision, using p1 of the grafted revision as base for the merge. As a trivial extension of this, we introduce the --base option to allow for using another base revision. This can be used as a building block for grafting and collapsing multiple changesets at once, or for grafting the resulting change from a merge as a single simple change. (This is kind of similar to backout --parent ... only different: this graft base must be an ancestor, but is usually *not* a parent.) This is probably an advanced use case, and we do thus not show it in the non-verbose help.
Thu, 18 Oct 2018 12:31:06 +0200 changegroup: add a option to create bundle with full snapshot only
Boris Feld <boris.feld@octobus.net> [Thu, 18 Oct 2018 12:31:06 +0200] rev 40433
changegroup: add a option to create bundle with full snapshot only This is easy to implement now and can be useful for benchmarking.
Wed, 10 Oct 2018 00:21:02 +0200 changegroup: allow to force delta to be against p1
Boris Feld <boris.feld@octobus.net> [Wed, 10 Oct 2018 00:21:02 +0200] rev 40432
changegroup: allow to force delta to be against p1 This new developer option is useful to general more "generic" bundle. Without this option, a bundle generated from the repository use deltas similar to the one stored in the specific repository it was generated from. This makes performance testing a bit tricky. Using deltas similar to the final result means all delta stored in the bundle can be applied to the target repository without any further processing (except for the rare case of a full snapshot). The application of such bundles (almost) never exercises the (slower) path of searching for a new valid delta. This result in unrealistic and too favorable timing and profile. Instead, we introduce an option to make sure all revisions are stored as a delta against p1. It might not be the best generation option, but it guarantees that the content will be "generic", not favoring a specific target.
Wed, 31 Oct 2018 21:16:54 +0900 fix: disable use of thread-based worker stable
Yuya Nishihara <yuya@tcha.org> [Wed, 31 Oct 2018 21:16:54 +0900] rev 40431
fix: disable use of thread-based worker getfixes() accesses to repo, changectx, filectx, etc., so I believe there are code paths triggering data race. Mercurial API isn't thread safe in general.
Tue, 09 Oct 2018 23:26:35 +0200 storage: also use `deltamode argument` for ifiledata
Boris Feld <boris.feld@octobus.net> [Tue, 09 Oct 2018 23:26:35 +0200] rev 40430
storage: also use `deltamode argument` for ifiledata Now that lower level uses such argument, we can propagate the change to higher layers.
Wed, 31 Oct 2018 15:27:06 +0300 configitems: rename the config to prevent adding an alias in future stable
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 31 Oct 2018 15:27:06 +0300] rev 40429
configitems: rename the config to prevent adding an alias in future Right now the config option looks like: [experimental.server] stream-narrow-clones= which does not match how config options are generally defined in core. So let's rename this to: [experimental] server.stream-narrow-clones= before the new release so that we don't have to add an alias in future for this. Differential Revision: https://phab.mercurial-scm.org/D5198
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip