Excess data size for a single revision

Stefan Monnier monnier at iro.umontreal.ca
Wed Jan 25 13:27:54 UTC 2012

>> > Nobody else seems particularly interested in either of these tedious
>> > jobs (updating years, merging between branches) so I did them to the
>> > best of my abilities.
>> AFAICT you did it just fine, indeed.  The size of those revisions is
>> a bit annoying, but I don't think it's that bad.  Furthermore, I don't
>> know how we could have done it better.  AFAIK, even if we had applied
>> the patch to the emacs-23 branch first and then merged it into trunk and
>> that went all very smoothly (e.g. no spurious conflicts), I believe Bzr
>> would have shown the same large data size on both branches, i.e. it
>> would not have helped.

> You are missing the point.  I didn't complain about the large size of
> the revision that changes all 2000 files.  I complained about the
> revision that changes twice that much, for some reason.  See the
> numbers shown by John in his analysis of the merge commit.

Same difference: if we merge emacs-23 into the trunk, then when we fetch
the trunk we'll fetch the large diff on the trunk plus the large diff on
emacs-23 because Bazaar always wants to have the complete DAG locally.


More information about the bazaar mailing list