Thu, 12 Nov 2015 02:52:19 -0800 test: enforce generaldelta format with the right option
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 12 Nov 2015 02:52:19 -0800] rev 26914
test: enforce generaldelta format with the right option The option that will become true by default is now 'usegeneraldelta' We have to adjust the change made in b75fed55f6dc to actually achieve its goal.
Sat, 07 Nov 2015 13:53:11 -0500 test: enforce non-generaldelta base repository in 'test-generaldelta'
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 07 Nov 2015 13:53:11 -0500] rev 26913
test: enforce non-generaldelta base repository in 'test-generaldelta' This test check the difference between various configurations we have to pin the type of some repositories to ensure the test is still correct when we change the default.
Tue, 20 Oct 2015 12:25:51 +0200 test: use generaldelta in 'test-hgweb-command.t'
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 12:25:51 +0200] rev 26912
test: use generaldelta in 'test-hgweb-command.t' Using generaldelta has a meaningless impact on the capabilities string.
Tue, 20 Oct 2015 12:28:42 +0200 stream: sort stream capability before serialisation
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 12:28:42 +0200] rev 26911
stream: sort stream capability before serialisation We want that capability to be stable in our testing. This is currently not an issue because the set is size 1, but this will be once generaldelta related data gets in there.
Tue, 20 Oct 2015 12:25:09 +0200 test: spread capabilities replies in 'test-hgweb-commands'
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 12:25:09 +0200] rev 26910
test: spread capabilities replies in 'test-hgweb-commands' Any changes to the capabilities string was very hard to review. So we introduce two tests. A small one that validates the format and a second one to validate the content, where each capability is on its own line to make changes simpler to review.
Sat, 07 Nov 2015 16:11:49 -0800 phase: improve retractboundary perf
Durham Goode <durham@fb.com> [Sat, 07 Nov 2015 16:11:49 -0800] rev 26909
phase: improve retractboundary perf The existing retractboundary implementation computed the new boundary by walking all descendants of all existing roots and computing the new roots. This is O(commits since first root), which on long repos can be hundreds of thousands of commits. The new algorithm only updates roots that are greater than the new root locations. For common operations like commit on a repo with the earliest root several hundred thousand commits ago, this makes retractboundary go from 1 second to 0.008 seconds. I tested it by running the test suite with both implementations and checking that the root results were always the identical. There was some discussion on IRC about the safety of this (i.e. what if the new nodes are already part of the phase, etc). I've looked into it and believe this patch is safe: 1) The old existing code already filters the input nodes to only contain nodes that require retracting (i.e. we only make node X a new root if the old phase is less than the target phase), so there's no chance of us adding a unnecessary root to the phase (unless the input root is made unnecessary by another root in the same input, but see point #3). 2) Another way of thinking about this is: the only way the new algorithm would be different from the old algorithm is if it added a root that is a descendant of an old root (since the old algorithm would've caught this in the big "roots(%ln::)". At the beginning of the function, when we filter out roots that already meet the phase criteria, the *definition* of meeting the phase criteria is "not being a descendant of an existing root". Therefore, by definition none of the new roots we are processing are descendants of an existing root. 3) If two nodes are passed in as input, and one node is an ancestor of the other (and therefore the later node should not be a root), this is still caught by the 'roots(%ln::)' revset. So there's no chance of an extra root being introduced that way either.
Thu, 12 Nov 2015 13:51:09 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 12 Nov 2015 13:51:09 -0600] rev 26908
merge with stable
Mon, 02 Nov 2015 15:59:12 +0000 format: introduce 'format.usegeneraldelta`
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 02 Nov 2015 15:59:12 +0000] rev 26907
format: introduce 'format.usegeneraldelta` This option will make repositories created as general delta by default but will not make Mercurial aggressively recompute deltas for all incoming bundle. Instead, the delta contained in the bundle will be used. This will allow us to start having general delta repositories created everywhere without triggering massive recomputation costs for all new clients cloning from old servers.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip