Mon, 07 Nov 2016 18:35:43 -0800 bundle2: use new compression engine API for compression
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:35:43 -0800] rev 30351
bundle2: use new compression engine API for compression Now that we have a new API to define compression engines, let's put it to use! The new code stores a reference to the compression engine instead of a low-level compressor object. This will allow us to more easily transition to different APIs on the compression engine interface once we implement them. As part of this, we change the registration in bundletypes to use 'UN' instead of None. Previously, util.compressors had the no-op compressor registered under both the 'UN' and None keys. Since we're switching to a new API, I don't see the point in carrying this dual registration forward.
Mon, 07 Nov 2016 18:31:39 -0800 util: create new abstraction for compression engines
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Nov 2016 18:31:39 -0800] rev 30350
util: create new abstraction for compression engines Currently, util.py has "compressors" and "decompressors" dicts mapping compression algorithms to callables returning objects that perform well-defined operations. In addition, revlog.py has code for calling into a compressor or decompressor explicitly. And, there is code in the wire protocol for performing zlib compression. The 3rd party lz4revlog extension has demonstrated the utility of supporting alternative compression formats for revlog storage. But it stops short of supporting lz4 for bundles and the wire protocol. There are also plans to support zstd as a general compression replacement. So, there appears to be a market for a unified API for registering compression engines. This commit starts the process of establishing one. This commit establishes a base class/interface for defining compression engines and how they will be used. A collection class to hold references to registered compression engines has also been introduced. The built-in zlib, bz2, truncated bz2, and no-op compression engines are registered with a singleton instance of the collection class. The compression engine API will change once consumers are ported to the new API and some common patterns can be simplified at the engine API level. So don't get too attached to the API...
Sun, 09 Oct 2016 09:25:39 -0400 config: mark parser regexes as bytes explicitly
Augie Fackler <augie@google.com> [Sun, 09 Oct 2016 09:25:39 -0400] rev 30349
config: mark parser regexes as bytes explicitly r-strings are not transformed into bytes by our source transformer magic.
Sun, 09 Oct 2016 09:17:49 -0400 ui: explicitly open config files in binary mode
Augie Fackler <augie@google.com> [Sun, 09 Oct 2016 09:17:49 -0400] rev 30348
ui: explicitly open config files in binary mode This has been working mostly accidentally, but now it works explicitly.
Wed, 09 Nov 2016 16:04:44 -0800 help: fix double word usage
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 09 Nov 2016 16:04:44 -0800] rev 30347
help: fix double word usage "most" was used twice. (I fixed a grammar error before timeless spotted it!)
Wed, 09 Nov 2016 22:08:30 +0000 setup: move cffi stuff to mercurial/cffi
Jun Wu <quark@fb.com> [Wed, 09 Nov 2016 22:08:30 +0000] rev 30346
setup: move cffi stuff to mercurial/cffi This patch moves all setup*cffi stuff to mercurial/cffi to make the root directory cleaner. The idea was from mpm [1]: > It seems like we could have a fair amount of cffi definitions, and > cluttering the root directory (or mercurial/) with them is probably not > a great long-term solution. We could probably add a cffi/ directory > under mercurial/ to parallel pure/. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-July/086442.html
Tue, 08 Nov 2016 08:03:43 -0800 manifest: remove manifest.add and add memmfctx.write
Durham Goode <durham@fb.com> [Tue, 08 Nov 2016 08:03:43 -0800] rev 30345
manifest: remove manifest.add and add memmfctx.write This removes one more dependency on the manifest class by moving the write functionality onto the memmanifestctx classes and changing the one consumer to use the new API. By moving the write path to a manifestctx, we now give the individual manifests control over how they're read and serialized. This will be useful in developing new manifest formats and storage systems.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip