[PATCH rfc] bundle: when verbose, show what takes up the space in the uncompressed bundle

Mads Kiilerich mads at kiilerich.com
Fri Aug 29 16:59:36 CDT 2014


On 08/29/2014 05:06 PM, Matt Mackall wrote:
> On Fri, 2014-08-29 at 14:23 +0200, Kevin Bullock wrote:
>> On Aug 29, 2014, at 11:45 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>>
>>> # HG changeset patch
>>> # User Mads Kiilerich <madski at unity3d.com>
>>> # Date 1408124612 -7200
>>> #      Fri Aug 15 19:43:32 2014 +0200
>>> # Node ID c6f7a80ae75f32f5d876fbdf3a4e1b8a6a389128
>>> # Parent  926bc0d3b595caf37c5d70833a347eb43285de2f
>>> bundle: when verbose, show what takes up the space in the uncompressed bundle
>>>
>>> This is kind of similar to the debugbundle command but gives summarized actual
>>> numbers when creating the bundle.
>>>
>>> Useful before pushing stuff from others to assess whether it makes sense to
>>> increase the repo size that much or if large files accidentally have been
>>> committed.
>>>
>>> This output doesn't combine well with debug output so we only enable it when
>>> verbose without debug.
>> Not a bad idea, but I'd like to see units on those numbers.

Adding "bytes" to every line would be weird. And a "bundle content and size in bytes" preample seems even more weird than the existing one.


> Let's put this under --debug?

That would interleave it with "progress" info like on 
http://selenic.com/repo/hg/file/bdc0e04df243/tests/test-bundle.t#l623 
and I don't think that would be useful ... unless the old progress info 
could be removed. I doubt it would be feasible to collect these numbers 
at the level where the progress info is collected.

Anyway, this is just a very rough approximation of the amount of 
information (a la Nyquist) added to the repository. Both the bundle 
format and the repo storage format are however far from that so the 
approximation might be way off and irrelevant ... but it seems to be the 
best we have.

Now, enter the brave new world of clever deltas and bundle2 ... That 
will make these numbers more relevant.

/Mads


More information about the Mercurial-devel mailing list