The $USUAL_COMPRESSIONS$ value that was taken was not compatible with the pure
variant systems as zlib seems to not be available in these case.
Differential Revision: https://phab.mercurial-scm.org/D1562
Upon pull or unbundle, we display a message with the range of new revisions
fetched. This revision range could readily be used after a pull to look out
what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
revisions that might be present in transaction's "changes" but should not be
displayed to the end user.
An extra post processing was added to recognize remote heads that are hidden
locally as "common" instead of "unknown". However, this processing was
removing such hidden heads from the remote heads sets.
It had no impact because we used to pull phase information from all remote
heads.
This series will replace the phase pulling operation to a more efficient
process but requires the unmodified pulled set information.
Now that servers expose a capability indicating they support
application/mercurial-0.2 and compression, clients can key off
this to say they support responses that are compressed with
various compression formats.
After this commit, the HTTP wire protocol client now sends an
"X-HgProto-<N>" request header indicating its support for
"application/mercurial-0.2" media type and various compression
formats.
This commit also implements support for handling
"application/mercurial-0.2" responses. It simply reads the header
compression engine identifier then routes the remainder of the
response to the appropriate decompressor.
There were some test changes, but only to logging. That points to
an obvious gap in our test coverage. This will be addressed in a
subsequent commit once server support is in place (it is hard to
test without server support).
$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.
