Excess data size for a single revision

Eli Zaretskii 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
> trunk)
> 
> and
>     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?

Thanks.



More information about the bazaar mailing list