exchange: send bundle2 stream clones uncompressed Stream clones don't compress well. And compression undermines a point of stream clones which is to trade significant CPU reductions by increasing size. Building upon our introduction of metadata to communicate bundle information back to callers of exchange.getbundlechunks(), we add an attribute to the bundler that communicates whether the bundle is best left uncompressed. We return this attribute as part of the bundle metadata. And the wire protocol honors it when determining whether to compress the wire protocol response. The added test demonstrates that the raw result from the wire protocol is not compressed. It also demonstrates that the server will serve stream responses when the feature isn't enabled. We'll address that in another commit. The effect of this change is that server-side CPU usage for bundle2 stream clones is significantly reduced by removing zstd compression. For the mozilla-unified repository: before: 37.69 user 8.01 system after: 27.38 user 7.34 system Assuming things are CPU bound, that ~10s reduction would translate to faster clones on the client. zstd can decompress at >1 GB/s. So the overhead from decompression on the client is small in the grand scheme of things. But if zlib compression were being used, the overhead would be much greater. Differential Revision: https://phab.mercurial-scm.org/D1926

tests: update test to work with Git 2.16 It looks like Git 2.16 removed the "..." from some strings. Glob over those characters in the test output. Differential Revision: https://phab.mercurial-scm.org/D1935

exchange: return bundle info from getbundlechunks() (API) We generally want a mechanism to pass information about the generated bundle back to callers (in addition to the byte stream). Ideally we would return a bundler from this function and have the caller code to an interface. But the bundling APIs are not great and getbundlechunks() is the best API we have for obtaining bundle contents in a unified manner. We change getbundlechunks() to return a dict that we can use to communicate metadata. We populate that dict with the bundle version number to demonstrate some value. .. api:: exchange.getbundlechunks() now returns a 2-tuple instead of just an iterator. Differential Revision: https://phab.mercurial-scm.org/D1925

exchange: make stream bundle part deterministic repo.requirements is a set. We need to sort it so the part content is deterministic. Differential Revision: https://phab.mercurial-scm.org/D1924

bundle2: specify what capabilities will be used for We currently assume there is a symmetric relationship of bundle2 capabilities between client and server. However, this may not always be the case. We need a bundle2 capability to advertise bundle2 streaming clone support on servers to differentiate it from the existing, legacy streaming clone support. However, servers may wish to disable streaming clone support. If bundle2 capabilities were the same between client and server, a client (which may also be a server) that has disabled streaming clone support would not be able to perform a streaming clone itself! This commit introduces a "role" argument to bundle2.getrepocaps() that explicitly defines the role being performed. This will allow us (and extensions) to alter bundle2 capabilities depending on the operation being performed. Differential Revision: https://phab.mercurial-scm.org/D1923

wireproto: don't compress errors from getbundle() Errors should be small. There's no real need to compress them. Truth be told, there's no good reason to not compress them either. But leaving them uncompressed makes it easier to test failures by looking at the raw HTTP response. This makes it easier for us to write tests. It may make it easier for people writing their own clients. Differential Revision: https://phab.mercurial-scm.org/D1922

tests: teach get-with-headers.py some new tricks We add the ability to specify arbitrary HTTP request headers and to save the HTTP response body to a file. These will be used in upcoming commits. Differential Revision: https://phab.mercurial-scm.org/D1921

tests: use argparse in get-with-headers.py I'm about to add another flag and I don't want to deal with this organic, artisanal argument parser. Differential Revision: https://phab.mercurial-scm.org/D1920

convert: use a collections.deque This function was doing a list.pop(0) on a list whose length was the number of revisions to convert. Popping an early element from long lists is not an efficient operation. collections.deque supports efficient inserts and pops at both ends. So we switch to that data structure. When converting the mozilla-unified repository, which has 445,748 revisions, this change makes the "sorting..." step of `hg convert --sourcesort` significantly faster: before: ~59.2s after: ~1.3s Differential Revision: https://phab.mercurial-scm.org/D1934

repair: invalidate volatile sets after stripping Matt Harbison reported that some tests were broken on Windows after 1a09dad8b85a (evolution: report new unstable changesets, 2018-01-14). The failures were exactly as seen in this patch. The failures actually seemed correct, which made me wonder why they didn't fail the same way on Linux. It turned out to be a cache invalidation problem. The new orphan mentioned in the test case actually does get created when we're re-applying the temporary bundle that's created while stripping. However, without the invalidation, it appears that there was already an orphan before applying the temporary bundle. The warnings about unknown working parent appear because the aformentioned changeset means that we're now accessing the dirstate while it's invalid. We may want to suppress these messages that happen in the intermediate strip state, but they're technically correct (although confusing to the user), so I think just fixing the cache invalidation is fine for now. I haven't figured out why the caches seemed to get correctly invalidated on Windows. Differential Revision: https://phab.mercurial-scm.org/D1933