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.
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.
test: use generaldelta in 'test-hgweb-command.t'
Using generaldelta has a meaningless impact on the capabilities string.
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.
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.
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.