Excess data size for a single revision
eliz at gnu.org
Mon Jan 23 17:09:52 UTC 2012
> Date: Mon, 23 Jan 2012 15:24:35 +0100
> From: John Arbash Meinel <john at arbash-meinel.com>
> CC: mbp at sourcefrog.net, bazaar at lists.canonical.com
> >>> What am I looking for, though? E.g., the .rix index
> >>> corresponding to the above pack has 35 revisions, while the
> >>> corresponding .tix file has 4088 texts. Is the latter
> >>> unusually large?
> >> Averaged across a lot of histories (bzr, mysql, linux kernel,
> >> emacs I think), a good heuristic is <10 texts changed per commit.
> >> Above is averaging 100 texts changed per commit, or about 10x
> >> normal. So yes, it is larger than expected.
> > As I wrote earlier, only 7 files were changed and the diffs are
> > less than 200 lines.
> bzr log -n0 -r 106891 shows:
> 99634.2.1005 Glenn Morris 2012-01-10
> Update short copyright year to 2012 (do not merge to
> 99634.2.1006 Glenn Morris 2012-01-10
> Add 2012 to FSF copyright years for Emacs files (do
> not merge to trunk)
> Which together modify about 2000 files, and
Since the log messages say "do not merge to trunk" (because the trunk
already had such Copyright changes), I assumed Glenn didn't. Glenn?
> 99634.21.7 Kenichi Handa 2012-01-13 [merge]
> Which also has about 2000 entries (though those may not have been
> modified vs trunk).
And those 2000 entries again change the Copyright notices...
> Now, it is possible that the changes introduced by 99634.2.1005 and
> 99634.2.1006 were reverted when they were merged to trunk. However,
> that history is still part of the ancestry and that 2000 texts is
> still copied around.
So it appears we made some mess to the history by cross-merging the
same changes back and forth between the trunk and the branch, is that
so? If so, how to avoid this in the future?
Could you perhaps take a look in the Emacs trunk at admin/bzrmerge.el
(which is used to do these merges), and give your opinion about the
method it uses?
More information about the bazaar