Excess data size for a single revision
John Arbash Meinel
john at arbash-meinel.com
Wed Jan 25 15:09:39 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
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?
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the bazaar