Yuya Nishihara <yuya@tcha.org> [Fri, 16 Mar 2018 23:59:13 +0900] rev 36976
py3: make test-template-engine.t bytes-safe
Yuya Nishihara <yuya@tcha.org> [Thu, 15 Mar 2018 20:10:54 +0900] rev 36975
test-template-engine: deduplicate methods of custom template engine
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 15:10:22 +0100] rev 36974
revbranchcache: advertise and use 'rbc' exchange capability
The feature is now advertised and use.
Updating the branchmap cache can be very expensive (up to minutes on large
repository) and fetching revision branch data is about 80% of that. Exchanging
the rev branch cache over the wire really help to recover from branch map
invalidation.
(There is a good chance other in flight chance would conflict on
test-http-bad-server.t and other. So here is a small note to help update that
test again: capabilities=19bytes, part-107bytes)
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 19:26:41 +0100] rev 36973
revbranchcache: disable the new part for narrow hg bundle
The lack of some revisions confuses the new cache part. To simplify things, we
disable it for now.
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 14:58:02 +0100] rev 36972
revbranchcache: add the necessary bit to send 'rbc' data over bundle2
Getbundle is now capable of sending rev-branch-cache information for the
changesets it bundle. The data sent are mostly nodes so it is quite compact.
The goal of the rev-branch-cache is to speed up branch map computation,
especially when the branchmap gets invalidated so we send data for all
exchanged changesets. In addition, computing the relevant heads to send in
case of partial pulling would be challenging.
The feature is still inactive since the capability is not advertised yet.
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:33:00 +0100] rev 36971
bundle: include advisory rev branch cache part in bundle2 bundle
`hg bundle` command producing bundle2 will now include an optional part
containing the revision-branch cache data.
The data sent are mostly nodes so it is quite compact. The goal of the
rev-branch-cache is to speed up branch map computation, especially when the
branchmap gets invalidated so we send data for all exchanged changesets. In
addition, computing the relevant heads to send in case of partial pulling would
be challenging.
As a reminder, the rev branch cache data significantly speed up branch
computation. Having it around provides a small speedup to pull/clone and much
higher tolerance to branch map cache invalidation that might happens from later
commands.
On the Mercurial repository, computing the visible branchmap from scratch move
from 2.00 seconds to 0.34s (a -83% speedup).
Using this new part, Unbundling the full Mercurial repository moves from 25.736
seconds to 24.030 seconds (around -7% speedup). The bundle size increase is
around 3% (from 22.43 MB to 23.13MB)
On an half a million revision repository with twenty thousand
branches, computing the branchmap moves from 75 seconds to 45 second (-40%) if
the caches is used.
A bundle containing 50 000 changesets in such repository get a 0.5% size
increase from such part for a -3% unbundling time speedup.
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:26:22 +0100] rev 36970
rev-branch-cache: add a function to generate a part
The function is able to produce a rbc part consumed by the function introduced
into previous changesets. More details on usage and impact in the next
changesets.
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:35:04 +0100] rev 36969
revbranchcache: add a bundle2 handler for a rbc part
We add the necessary bit to process a part containing rev-branch-cache
information. The local rev branch cache is then updated with the received
information.
Computing branch cache can become a significant part of the time spent pulling.
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 14:21:05 +0100] rev 36968
revbranchcache: add a public function to update the data
We want to exchange more cached data over the wire. To do so, we need a clean
way to update the cache on the receiving ends.
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 15 Mar 2018 11:19:16 -0700] rev 36967
httppeer: consolidate _requestbuilder assignments and document
I collapsed multiple assignments because they don't appear to
be necessary. We don't invoke the requestbuilder in anything
called during __init__. So there's no reason to not define it
earlier AFAICT.
This seemingly useless attribute is actually an extension point.
Document it as such.
(A previous version of this patch removed the attribute because
it appeared to just be an alias.)
Differential Revision: https://phab.mercurial-scm.org/D2723