[PATCH 2 of 2 V2] changelog: disable delta chains

[Gregory Szorc]

> On Oct 5, 2016, at 17:39, Ryan McElroy <rm at fb.com> wrote:
> 
>> On 10/2/2016 6:33 PM, Gregory Szorc wrote:
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1475429177 25200
>> #      Sun Oct 02 10:26:17 2016 -0700
>> # Node ID 20c0d05c4f8e9f6f0c64cf17cd8fb89530ba0af3
>> # Parent  b4ca569d38c9e35f542b90868f86247ad8844b4c
>> changelog: disable delta chains
>> 
>> This patch disables delta chains on changelogs. After this patch, new
>> entries on changelogs - including existing changelogs - will be stored
>> as the fulltext of that data (likely compressed). No delta computation
>> will be performed.
> 
> I always wondered why we attempted delta compression on changelogs at all. I'm impressed that there are even delta chains of 7 in these repos (but I guess if you search hard enough for deltas, you might find some). In short, this change makes sense to me!
> 
>> Delta chains are also used during changegroup generation. This
>> operation essentially converts a series of revisions to one large
>> delta chain. And changegroup generation is smart: if the delta in
>> the revlog matches what the changegroup is emitting, it will reuse
>> the delta instead of recalculating it. We can measure the impact
>> removing changelog delta chains has on changegroup generation via
>> `hg perfchangegroupchangelog`:
> 
> Is requiring deltas at this stage required? How much work is your proposed optimization of always deltaing against the null commit (or to put it another way, why isn't that optimization included in this series?)

It shouldn't be too difficult - just time consuming. We don't have terrific tools around measuring changegroup performance and size. Then we have to consider impact on legacy clients that would re-delta the changegroup entries. I figured it best to deal with the subject later.

> 
> Thanks also for the great write-up!
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel