Excess data size for a single revision
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