Excess data size for a single revision

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/25/2012 4:03 PM, Stefan Monnier wrote:
>>>> 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.
>> But in this case, we fetched the large diff on the emacs-23
>> branch plus _twice_ the large diff from the trunk.
> 
> I haven't followed the thread closely enough to know what you're 
> referring to.
> 
>> It is that twice part that shouldn't have happened.
> 
> Indeed, I don't think it should happen, can you point to the data
> that shows that it happened?
> 
> 
> Stefan

So doing a revert merge has to create a new node in the text history,
because you have to assert that the text that should have superseded
doesn't. (rev A is the original text, rev B is the updated copyright,
you have to create a rev C that supersedes rev B that has the content
of rev A.)

However, this particular content compresses with 100% efficiency as
long as it is in the same group as text A, which will happen once we
have triggered recompression, but doesn't happen on the original
commit. (We don't delta compress at commit time, unless you trigger an
autopack.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8gGzIACgkQJdeBCYSNAAN5fgCfSZLB8PfXfQylCjF1VkaJRGaH
O6UAnic6/xROvl1Kb3u1aO9gyO3JE02a
=6AdK
-----END PGP SIGNATURE-----