Mercurial: Changelog

bundle2: always advertise client support for stream parts Previously, enabling of stream clone over bundle2 was a server-side only change. And clients would only advertise bundle2 support for stream clones if an experimental config option was set. This situation wasn't forward compatible because in the future (when the feature is enabled on servers by default), an old client would send a request to the server but it wouldn't send its own bundle2 capability support for stream parts. Servers would have to infer that clients not sending this capability were old Mercurial clients that only sent the capability if the feature was explicitly enabled. Implicit and inferred behavior makes implementing servers hard. It's much better to be explicit about client features. We should either make the config option for bundle2 stream clones disable the feature client-side as well (so a server doesn't see a request from a client not advertising stream support). Or we should always advertise stream support if a client is willing to accept stream parts. Since I anticipating stabilizing stream clone support in bundle2 quickly, I think it's safe to always advertise client support in the bundle2 capabilities. So this commit changes things to do that. Because capabilities now vary between client and server, we had to create variations of the variable substitutions for those strings. Differential Revision: https://phab.mercurial-scm.org/D1931

exchange: don't send stream data when server.uncompressed is set Previously, bundle2 stream support would send out data even though the streaming clone feature was disabled. This commit changes the part handler to respect the server config. Differential Revision: https://phab.mercurial-scm.org/D1930

bundle2: don't advertise stream bundle2 capability when feature disabled The server.uncompressed config option can be used to disable streaming clones. While the top-level capability to advertise streaming clone support isn't advertised when this option is set, we were still sending the bundle2-level capabilities advertising support for stream parts. It makes sense to not advertise that support when streaming clones are globally disabled. If the structure of the new code seems a bit odd, it is because we'll have to further tweak the behavior in commit(s) ahead. Differential Revision: https://phab.mercurial-scm.org/D1929

tests: add more testing around server.uncompressed We already have testing for server.uncompressed in test-http*.t. However, it doesn't cover the new bundle2 use case. And, we don't have comprehensive testing of advertised capabilities. We add tests to test-clone-uncompressed.t that demonstrate behavior for both legacy and bundle2 configurations. If you look closely, the bundle2 capabilities are advertising stream support when it isn't enabled. That's a bug. In addition, while the client is smart enough to not request a stream clone when the server doesn't have the feature enabled, the getbundle wire protocol command is still sending stream clone data. This doesn't match the behavior of the legacy stream_out wire protocol command. That's also a bug. Tests have been added. While I was here, I also changed how the PID is recorded in $DAEMON_PIDS. If we kill a process, the PID formerly in $DAEMON_PIDS no longer exists. So we should replace that file instead of appending to it. Differential Revision: https://phab.mercurial-scm.org/D1928

bundle2: move version of stream clone into part name I don't like having version numbers as part parameters. It means that parts can theoretically vary wildly in their generation and processing semantics. I think that a named part should have consistent behavior over time. In other words, if you need to introduce new functionality or behavior, that should be expressed by inventing a new bundle2 part, not adding functionality to an existing part. This commit applies this advice to the just-introduced stream clone via bundle2 feature. The "version" part parameter is removed. The name of the bundle2 part is now "stream2" instead of "stream" with "version=v2". Differential Revision: https://phab.mercurial-scm.org/D1927

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