push: rework the computation of fallbackheads to be correct
The previous computation tried to be smart but ended up being wrong. This was
caught by phase movement test while reworking the phase discovery logic to be
faster.
The previous logic was failing to catch case where the pushed set was not based
on a common heads (i.e. when the discovery seemed to have "over discovered"
content, outside the pushed set)
In the following graph, `e` is a common head and we `hg push -r f`. We need to
detect `c` as a fallback heads and we previous failed to do so::
e
|
d f
|/
c
|
b
|
a
The performance impact of the change seems minimal. On the most impacted
repository at hand (mozilla-try), the slowdown seems mostly mixed in the
overall noise `hg push` but seems to be in the hundred of milliseconds order of
magnitude. When using rust, we seems to be a bit faster, probably because we
leverage more accelaratd internals.
I added a couple of performance related common for further investigation later
on.
Test attempting a narrow clone against a server that doesn't support narrowhg.
$ . "$TESTDIR/narrow-library.sh"
$ hg init master
$ cd master
$ for x in `$TESTDIR/seq.py 10`; do
> echo $x > "f$x"
> hg add "f$x"
> hg commit -m "Add $x"
> done
$ hg serve -a localhost -p $HGPORT1 --config extensions.narrow=! -d \
> --pid-file=hg.pid
$ cat hg.pid >> "$DAEMON_PIDS"
$ hg serve -a localhost -p $HGPORT2 -d --pid-file=hg.pid
$ cat hg.pid >> "$DAEMON_PIDS"
Verify that narrow is advertised in the bundle2 capabilities:
$ cat >> unquote.py <<EOF
> import sys
> if sys.version[0] == '3':
> import urllib.parse as up
> unquote = up.unquote_plus
> else:
> import urllib
> unquote = urllib.unquote_plus
> print(unquote(list(sys.stdin)[1]))
> EOF
$ echo hello | hg -R . serve --stdio | \
> "$PYTHON" unquote.py | tr ' ' '\n' | grep narrow
exp-narrow-1
$ cd ..
$ hg clone --narrow --include f1 http://localhost:$HGPORT1/ narrowclone
requesting all changes
abort: server does not support narrow clones
[255]
Make a narrow clone (via HGPORT2), then try to narrow and widen
into it (from HGPORT1) to prove that narrowing is fine and widening fails
gracefully:
$ hg clone -r 0 --narrow --include f1 http://localhost:$HGPORT2/ narrowclone
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
new changesets * (glob)
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd narrowclone
$ hg tracked --addexclude f2 http://localhost:$HGPORT1/
comparing with http://localhost:$HGPORT1/
searching for changes
looking for local changes to affected paths
deleting unwanted files from working copy
$ hg tracked --addinclude f1 http://localhost:$HGPORT1/
nothing to widen or narrow
$ hg tracked --addinclude f9 http://localhost:$HGPORT1/
comparing with http://localhost:$HGPORT1/
abort: server does not support narrow clones
[255]