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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Sep 17 19:02:29 CDT 2014


So what's the status of this patch ?

On 08/29/2014 02:59 PM, Mads Kiilerich wrote:
> 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
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list