Mercurial: Changelog

cborutil: implement support for streaming encoding, bytestring decoding The vendored cbor2 package is... a bit disappointing. On the encoding side, it insists that you pass it something with a write() to send data to. That means if you want to emit data to a generator, you have to construct an e.g. io.BytesIO(), write() to it, then get the data back out. There can be non-trivial overhead involved. The encoder also doesn't support indefinite types - bytestrings, arrays, and maps that don't have a known length. Again, this is really unfortunate because it requires you to buffer the entire source and destination in memory to encode large things. On the decoding side, it supports reading indefinite length types. But it buffers them completely before returning. More sadness. This commit implements "streaming" encoders for various CBOR types. Encoding emits a generator of hunks. So you can efficiently stream encoded data elsewhere. It also implements support for emitting indefinite length bytestrings, arrays, and maps. On the decoding side, we only implement support for decoding an indefinite length bytestring from a file object. It will emit a generator of raw chunks from the source. I didn't want to reinvent so many wheels. But profiling the wire protocol revealed that the overhead of constructing io.BytesIO() instances to temporarily hold results has a non-trivial overhead. We're talking >15% of execution time for operations like "transfer the fulltexts of all files in a revision." So I can justify this effort. Fortunately, CBOR is a relatively straightforward format. And we have a reference implementation in the repo we can test against. Differential Revision: https://phab.mercurial-scm.org/D3303

configitems: register server.zstdlevel Somehow, I managed to trigger a devel-warn running `hg serve` outside the test suite on one of the repos generated by running test-lfs-serve-access.t --keep. (I'm not hitting it now after doing a `make local`.) The only reference to this in all of the history is the help text added in e75463e3179f, and the translations. (It looks like the string is built dynamically with '%slevel', which is probably how this was missed. I wonder if this isn't getting routed to error.log for some reason.) In any event, server.zliblevel is registered, and that's required to pick up the documented default.

scmutil: make shortesthexnodeidprefix() take a full binary nodeid The shortest() template function depended on the behavior of revlog._partialmatch() for these types of inputs: * non-hex strings * ambiguous strings * too long strings revlog._partialmatch() seems to return the input unchanged in these cases, but we shouldn't depend on such a low-level function to match the behavior we want in the user-facing template function. Instead, let's handle these cases in the template function and always pass a binary nodeid to _partialmatch(). Differential Revision: https://phab.mercurial-scm.org/D3371

scmutil: make shortesthexnodeidprefix() use unfiltered repo Both callers were doing this, and resolvehexnodeidprefix() was also working on the unfiltered repo, so it makes more sense to have it all in one place. Differential Revision: https://phab.mercurial-scm.org/D3313

templates: adjust white space amount in the output of {whyunstable} There used to be 2 spaces between divergent nodes (when not using custom template for divergentnodes) because divergentnodes is a hybrid list, which means it gets ' '.join()ed, but formatnode() already had a space. Now it doesn't, which requires extra effort in writing custom templates for whyunstable, but at least it looks correctly by default. Test output needs to be sorted for stability.