$TESTDIR is added to the path, so this is superfluous. Also,
inconsistent use of quotes means we might have broken on tests with
paths containing spaces.
The conditional was a bit too narrow and produced buggy result when a node was
present in both common and heads (because it pleased the discovery) and it was
locally known but filtered.
This resulted in buggy getbundle request and server side crash.
There is no reason for bookmarks to get a special treatment. As a first step we
move the code as is in the `exchange.pull` function. Integration with the rest
of the flow will come later.
Adding bookmarks to pull means that most clone paths are now pulling bookmarks
through pull. We ensure that bookmark-update messages are properly suppressed in
that case.
In test-pull-http.t the 'requesting all changes' message disappear because we
now get the authentication error on the `listkeys`command before such message
is printed.
The discovery of necessary bookmark updates is now done within the "discovery
phase". This opens the door to the inclusion of bookmarks in a unified bundle2
push.
Recent change in the push process introduced an extra listing of the phase
name space before the push (on default). Meanwhile on default, a fix introduced
a new test with debug output.
We update the test output to be correct.
Pull would send a getbundle command where common heads were sent both as common
and head, even though there is no reason to request a common head.
The request was thus twice as big as necessary and more likely to hit HTTP
header size limits.
Instead, don't request heads that already are common.
This is fixed in bundlerepo.getremotechanges . It could perhaps also have been
fixed in discovery.findcommonincoming but that would have a bigger impact.
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 1
This makes pull agree with the rest of the table and makes it easy to
detect "nothing was pulled" in scripts.
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 0
This fixes the lower-right entry.
It seems ksh, the default shell on AIX, does not permit the creation of a
function called stop(). test-treediscovery.t and test-treediscovery-legacy.t
both fail on AIX with error 'syntax error at line 25 : `(' unexpected'.
Fix by renaming stop() in the scripts to tstop(). For completeness
rename start() to tstart() to match. Both tests then pass on AIX.
Add check for the use of stop() in a shell script to check-code.
Old discovery only returned incoming heads, not all of them (for
changegroupsubset). New discovery must always return all of the remote heads
(for getbundle). I failed to properly adjust treediscovery in 43f4c1113c8d
when introducing setdiscovery.
The actual observable problem was 'remote: unsynced changes' when trying
to push a cset on one named branch to a server with a new cset on another
named branch. This scenario is now tested in test-treediscovery.t.
A '\n' on the command line is turned into a newline by dash, but kept
as-is by bash, which resulted in a syntax error in the config file.
Luckily, dash wont turn '\n' into a newline when it is part of a
here-doc, so we can write the config file using that technique.
I ran the entire test suite with "known" and "getbundle" disabled in
localrepository. This generated failures because the old findoutgoing
had always queried remote's heads explicitly and thus always got them
back in the returned heads. treediscovery.findcommonincoming now
correctly returns remote's heads in all cases.
Also adds a dedicated test for running treediscovery against a
pre-getbundle HTTP server.