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.
Boris Feld <boris.feld@octobus.net> [Wed, 10 Oct 2018 00:21:02 +0200] rev 40497
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.