Wed, 21 Feb 2018 19:26:41 +0100 revbranchcache: disable the new part for narrow hg bundle
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 19:26:41 +0100] rev 36967
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.
Thu, 18 Jan 2018 14:58:02 +0100 revbranchcache: add the necessary bit to send 'rbc' data over bundle2
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 14:58:02 +0100] rev 36966
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.
Wed, 21 Feb 2018 17:33:00 +0100 bundle: include advisory rev branch cache part in bundle2 bundle
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:33:00 +0100] rev 36965
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.
Wed, 21 Feb 2018 17:26:22 +0100 rev-branch-cache: add a function to generate a part
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:26:22 +0100] rev 36964
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.
Wed, 21 Feb 2018 17:35:04 +0100 revbranchcache: add a bundle2 handler for a rbc part
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:35:04 +0100] rev 36963
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.
Thu, 18 Jan 2018 14:21:05 +0100 revbranchcache: add a public function to update the data
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 14:21:05 +0100] rev 36962
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.
Thu, 15 Mar 2018 11:19:16 -0700 httppeer: consolidate _requestbuilder assignments and document
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 15 Mar 2018 11:19:16 -0700] rev 36961
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
Mon, 05 Mar 2018 00:18:07 -0500 commands: don't check for merge.update() truthiness
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Mar 2018 00:18:07 -0500] rev 36960
commands: don't check for merge.update() truthiness AFAICT ``stats`` is always a tuple in these cases. We don't need to check if the variable has a truthy value. Differential Revision: https://phab.mercurial-scm.org/D2691
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip