Excess data size for a single revision

[Eli Zaretskii]

> Date: Tue, 24 Jan 2012 13:41:34 +0100
> From: John Arbash Meinel <john at arbash-meinel.com>
> CC: Stefan Monnier <monnier at iro.umontreal.ca>, rgm at gnu.org, 
>  mbp at sourcefrog.net, bazaar at lists.canonical.com
> 
> > Could you please describe what does "do not merge to trunk" do?
> 
> Given the specific history, I'm pretty sure this was done with
> something like:
> 
> cd trunk
> bzr merge ../other-branch
> bzr revert .
> bzr commit -m "Merge but ignore the copyright changes"
> 
> I realize the specifics may be different, but that could easily be why
> you would have lots of changes in the ancestry, but not actually shown
> in the trunk revisions.

Could you please suggest a better way, if it exists, of doing this?

The basic requirement is to record merges from the stable branch to
trunk in the trunk history (so cherrypicking is out).  This is because
we merge from the branch to the trunk from time to time and in chunks;
recording the merges in the history helps us to know where to begin
the next merge, because "bzr missing" etc. do that job.

The disadvantage of the above method, whereby a revision is merged and
then backed out from the tree, is that metadata says revision REV1 is
in the trunk, but no "bzr diff" command will ever show you any of the
changes done in that revision on the branch.  The excessive size of
the transferred data in the case in point is just an extreme example
of where this can lead, but even with "normal" metadata sizes this
leads to confusing contradictions between what the various bzr
commands tell about a particular merged revision.

TIA