Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 23 Oct 2018 16:24:04 +0300] rev 40501
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
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 23 Oct 2018 14:26:17 +0300] rev 40500
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
Mads Kiilerich <mads@kiilerich.com> [Sun, 14 Oct 2018 17:08:18 +0200] rev 40499
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.
Boris Feld <boris.feld@octobus.net> [Thu, 18 Oct 2018 12:31:06 +0200] rev 40498
changegroup: add a option to create bundle with full snapshot only
This is easy to implement now and can be useful for benchmarking.