Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 27 Jun 2017 01:03:01 +0200] rev 33142
obsutil: move 'successorssets' to the new modules
We have a new 'obsutil' module now. We move this high level utility there to bring
'obsolete.py' back to a more reasonable size.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Jun 2017 13:49:34 +0200] rev 33141
revlog: add an experimental option to mitigated delta issues (issue5480)
The general delta heuristic to select a delta do not scale with the number of
branch. The delta base is frequently too far away to be able to reuse a chain
according to the "distance" criteria. This leads to insertion of larger delta (or
even full text) that themselves push the bases for the next delta further away
leading to more large deltas and full texts. This full text and frequent
recomputation throw Mercurial performance in disarray.
For example of a slightly large repository
280 000 files (2 150 000 versions)
430 000 changesets (10 000 topological heads)
Number below compares repository with and without the distance criteria:
manifest size:
with: 21.4 GB
without: 0.3 GB
store size:
with: 28.7 GB
without 7.4 GB
bundle last 15 00 revisions:
with: 800 seconds
971 MB
without: 50 seconds
73 MB
unbundle time (of the last 15K revisions):
with: 1150 seconds (~19 minutes)
without: 35 seconds
Similar issues has been observed in other repositories.
Adding a new option or "feature" on stable is uncommon. However, given that this
issues is making Mercurial practically unusable, I'm exceptionally targeting
this patch for stable.
What is actually needed is a full rework of the delta building and reading
logic. However, that will be a longer process and churn not suitable for stable.
In the meantime, we introduces a quick and dirty mitigation of this in the
'experimental' config space. The new option introduces a way to set the maximum
amount of memory usable to store a diff in memory. This extend the ability for
Mercurial to create chains without removing all safe guard regarding memory
access. The option should be phased out when core has a more proper solution
available.
Setting the limit to '0' remove all limits, setting it to '-1' use the default
limit (textsize x 4).
Adam Simpkins <simpkins@fb.com> [Thu, 29 Jun 2017 11:29:19 -0700] rev 33140
tests: fix variable name regular expression in _genrestoreenv()
Update the code to correctly anchor the expression on the end of the name, to
require that the entire name match this expression. It was already anchored at
the start by using re.match(), but this does not anchor it at the end.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Jun 2017 15:21:52 -0700] rev 33139
merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Jun 2017 17:41:25 +0200] rev 33138
pushrace: avoid crash on bare push when using concurrent push mode
If the remote is empty, we do now bother computing head changes and the
'pushbranchmap' attribute stays at None.
We now handle and tests this case.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 25 Jun 2017 22:20:37 -0700] rev 33137
show: config option to register aliases for views
As part of using `hg show` in my daily workflow, I've found it slightly
annoying to have to type full view names, complete with a space. I've
locally registered an alias for "swork = show work."
I think others will have this same complaint and could benefit from
some automation to streamline the creation of aliases. So, this
commit introduces a config option that allows `hg show` views to be
automatically aliased using a given prefix. e.g. a value of "s"
will automatically register "swork" and "sbookmarks." Multiple
values can be given for ultimate flexibility. This arguably isn't
needed now. But since we don't register aliases if there will be
a collision and we're bound to have a collision, it makes sense to
allow multiple prefixes so specific views can avoid collisions by
using different prefixes.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 18 Jun 2017 20:49:08 +0200] rev 33136
blackbox: use a human readable version of the default
Now that the default value is also converted we can use a human readable version
for it. This will be useful if we start to automatically display the default
config value in various place.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 13:21:06 +0200] rev 33135
configitems: register 'blackbox.maxsize' as an example of 'configbytes'
This exercise the default value handling in 'configbytes'.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 13:41:28 +0200] rev 33134
blackbox: minor code reordering
The version declaration should come first in my opinion. This will help gather
the command table with the config table.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 18 Jun 2017 19:52:54 +0200] rev 33133
configitems: add a devel warning for extensions items overiding core one
We do not want such case to pass silently. In the future we'll likely have
useful tool for an extension to alter the existing definition in core.