Briefly, our parsing of the Mercurial wire protocol is buggy, and recent versions of Mercurial have extended the wire protocol so that we don't have proper behavior. Known issues:
Bundle2 Filtering: Since D14241/T9450, we attempt to filter the protocol and tell the client that we don't support bundle2. This probably doesn't work. A more desirable behavior is to support bundle2.
Here's some evidence this doesn't work:
$ hg push --debug ... remote: 346 remote: capabilities: lookup changegroupsubset branchmap pushkey known getbundle unbundlehash batch stream bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Aphases%3Dheads%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps unbundle=HG10GZ,HG10BZ,HG10UN
That looks a lot like the server claiming it supports bundle2.
This doesn't necessarily cause any problems on its own, and may fix some problems, but ideally we'd remove this code and then fix whatever that breaks.
Pushing A Large File: These steps can reproduce a specific wire protocol parsing issue:
Server version 4.4.1, client version 4.4.1, SSH.
$ head -c4096000 /dev/zero > 4MB.zero $ hg add 4MB.zero $ hg commit -m 'High quality change.' $ hg push
$ hg push pushing to ssh://email@example.com/diffusion/39/new-api-mercurial-repo/ searching for changes remote: abort: stream ended unexpectedly (got 0 bytes, expected 4) <... snip ...> remote: ValueError: need more than 1 value to unpack remote: Exception: Writing to a closed pipe!
Pushing a smaller change doesn't reproduce this issue, so Mercurial's protocol negotiation presumably considers the size of the change being transmitted in selecting the protocol format.