Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:19:16 -0800] rev 30371
dirstate: change added/modified placeholder hash length to 20 bytes
Previously the added/modified placeholder hash for manifests generated from the
dirstate was a 21byte long string consisting of the p1 file hash plus a single
character to indicate an add or a modify. Normal hashes are only 20 bytes long.
This makes it complicated to implement more efficient manifest implementations
which rely on the hashes being fixed length.
Let's change this hash to just be 20 bytes long, and rely on the astronomical
improbability of an actual hash being these 20 bytes (just like we rely on no
hash every being the nullid).
This changes the possible behavior slightly in that the hash for all
added/modified entries in the dirstate manifest will now be the same (so simple
node comparisons would say they are equal), but we should never be doing simple
node comparisons on these nodes even with the old hashes, because they did not
accurately represent the content (i.e. two files based off the same p1 file
node, with different working copy contents would have the same hash (even with
the appended character) in the old scheme too, so we couldn't depend on the
hashes period).
Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:17:22 -0800] rev 30370
dirstate: change placeholder hash length to 20 bytes
Previously the new-node placeholder hash for manifests generated from the
dirstate was a 21byte long string of "!" characters. Normal hashes are only 20
bytes long. This makes it complicated to implement more efficient manifest
implementations which rely on the hashes being fixed length.
Let's change this hash to just be 20 bytes long, and rely on the astronomical
improbability of an actual hash being 20 "!" bytes in a row (just like we rely
on no hash ever being the nullid).
A future diff will do this for added and modified dirstate markers as well, so
we're putting the new newnodeid in node.py so there's a common place for these
placeholders.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:57:54 -0800] rev 30369
util: remove compressorobj API from compression engines
All callers have been replaced with "compressstream." It is quite
low-level and redundant with "compressstream." So eliminate it.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:54:35 -0800] rev 30368
hgweb: use compression engine API for zlib compression
More low-level compression code elimination because we now have nice
APIs.
This patch also demonstrates why we needed and implemented the
"level" option on the "compressstream" API.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:46:37 -0800] rev 30367
bundle2: use compressstream compression engine API
Compression engines now have an API for compressing a stream of
chunks. Switch to it and make low-level compression code disappear.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:57:07 -0800] rev 30366
util: add a stream compression API to compression engines
It is a common pattern throughout the code to perform compression
on an iterator of chunks, yielding an iterator of compressed chunks.
Let's formalize that as part of the compression engine API.
The zlib and bzip2 implementations allow an optional "level" option
to control the compression level. The default values are the same as
what the Python modules use. This option will be used in subsequent
patches.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:39:08 -0800] rev 30365
util: remove decompressors dict (API)
All in-tree consumers are now using the compengines registrar.
Extensions should switch to it as well.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:38:13 -0800] rev 30364
changegroup: use compression engines API
The new API doesn't have the equivalence for None and 'UN' so we
introduce code to use 'UN' explicitly.