| Submitter | Gregory Szorc |
|---|---|
| Date | Jan. 10, 2017, 7:34 p.m. |
| Message ID | <5afa8b0ba877fd8602b0.1484076891@ubuntu-vm-main> |
| Download | mbox | patch |
| Permalink | /patch/18175/ |
| State | Accepted |
| Headers | show |
Comments
Gregory Szorc <gregory.szorc@gmail.com> writes: > # HG changeset patch > # User Gregory Szorc <gregory.szorc@gmail.com> > # Date 1484076032 28800 > # Tue Jan 10 11:20:32 2017 -0800 > # Node ID 5afa8b0ba877fd8602b0f8bd3b5949f98d56e90b > # Parent 82e5f4db873e2e4e01bb5264a5b2cc22781fc4b3 > commands: config option to control bundle compression level > > Currently, bundle compression uses the default compression level > for the active compression engine. The default compression level > is tuned as a compromise between speed and size. > > Some scenarios may call for a different compression level. For > example, with clone bundles, bundles are generated once and used > several times. Since the cost to generate is paid infrequently, > server operators may wish to trade extra CPU time for better > compression ratios. > > This patch introduces an experimental and undocumented config > option to control the bundle compression level. As the inline > comment says, this approach is a bit hacky. I'd prefer for > the compression level to be encoded in the bundle spec. e.g. > "zstd-v2;complevel=15." However, given that the 4.1 freeze is > imminent, I'm not comfortable implementing this user-facing > change without much time to test and consider the implications. > So, we're going with the quick and dirty solution for now. > > Having this option in the 4.1 release will enable Mozilla to > easily produce and test zlib and zstd bundles with non-default > compression levels in production. This will help drive future > development of the feature and zstd integration with Mercurial. I digested the patches this morning and they seem fine for the experimental section. Pre-reviewed!
On Wed, Jan 11, 2017 at 10:46:36AM -0800, Sean Farley wrote: > Gregory Szorc <gregory.szorc@gmail.com> writes: > > > # HG changeset patch > > # User Gregory Szorc <gregory.szorc@gmail.com> > > # Date 1484076032 28800 > > # Tue Jan 10 11:20:32 2017 -0800 > > # Node ID 5afa8b0ba877fd8602b0f8bd3b5949f98d56e90b > > # Parent 82e5f4db873e2e4e01bb5264a5b2cc22781fc4b3 > > commands: config option to control bundle compression level > > > > Currently, bundle compression uses the default compression level > > for the active compression engine. The default compression level > > is tuned as a compromise between speed and size. > > > > Some scenarios may call for a different compression level. For > > example, with clone bundles, bundles are generated once and used > > several times. Since the cost to generate is paid infrequently, > > server operators may wish to trade extra CPU time for better > > compression ratios. > > > > This patch introduces an experimental and undocumented config > > option to control the bundle compression level. As the inline > > comment says, this approach is a bit hacky. I'd prefer for > > the compression level to be encoded in the bundle spec. e.g. > > "zstd-v2;complevel=15." However, given that the 4.1 freeze is > > imminent, I'm not comfortable implementing this user-facing > > change without much time to test and consider the implications. > > So, we're going with the quick and dirty solution for now. > > > > Having this option in the 4.1 release will enable Mozilla to > > easily produce and test zlib and zstd bundles with non-default > > compression levels in production. This will help drive future > > development of the feature and zstd integration with Mercurial. > > I digested the patches this morning and they seem fine for the > experimental section. Pre-reviewed! Agreed, these are queued. > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Patch
diff --git a/mercurial/commands.py b/mercurial/commands.py --- a/mercurial/commands.py +++ b/mercurial/commands.py @@ -1383,7 +1383,17 @@ def bundle(ui, repo, fname, dest=None, * assert cgversion == '02' bversion = 'HG20' - bundle2.writebundle(ui, cg, fname, bversion, compression=bcompression) + # TODO compression options should be derived from bundlespec parsing. + # This is a temporary hack to allow adjusting bundle compression + # level without a) formalizing the bundlespec changes to declare it + # b) introducing a command flag. + compopts = {} + complevel = ui.configint('experimental', 'bundlecomplevel') + if complevel is not None: + compopts['level'] = complevel + + bundle2.writebundle(ui, cg, fname, bversion, compression=bcompression, + compopts=compopts) @command('cat', [('o', 'output', '', diff --git a/tests/test-bundle-type.t b/tests/test-bundle-type.t --- a/tests/test-bundle-type.t +++ b/tests/test-bundle-type.t @@ -110,6 +110,37 @@ test bundle types c35a0f9217e65d1fdb90c936ffa7dbe679f83ddf gzip-v1 + +Compression level can be adjusted for bundle2 bundles + + $ hg init test-complevel + $ cd test-complevel + + $ cat > file0 << EOF + > this is a file + > with some text + > and some more text + > and other content + > EOF + $ cat > file1 << EOF + > this is another file + > with some other content + > and repeated, repeated, repeated, repeated content + > EOF + $ hg -q commit -A -m initial + + $ hg bundle -a -t gzip-v2 gzip-v2.hg + 1 changesets found + $ f --size gzip-v2.hg + gzip-v2.hg: size=427 + + $ hg --config experimental.bundlecomplevel=1 bundle -a -t gzip-v2 gzip-v2-level1.hg + 1 changesets found + $ f --size gzip-v2-level1.hg + gzip-v2-level1.hg: size=435 + + $ cd .. + #if zstd $ for t in "zstd" "zstd-v2"; do