This is an archive of the discontinued Mercurial Phabricator instance.

changegroup: refactor delta parent code
ClosedPublic

Authored by indygreg on Aug 9 2018, 4:52 PM.

Details

Summary

We had recently abstracted the delta parent functions to
facilitate extracting code from cgpacker. Now that we're in
a better place, it is time to revisit the design.

Changegroup version 1 requires that the previous node be used as the
delta parent. Later versions allow any available node to be used
as the base.

In the case where an arbitrary parent can be used, the choice of
a delta parent is best left in the hands of the storage backend.
So it makes sense for the delta parent selection to be hidden
away in the storage layer. This means deferring the choice of the
delta parent selection function to as close to delta generation
time as possible.

This commit moves the delta selection logic to essentially just
before delta generation. However, because changegroup version 1
limits what we can do, we have retained the ability to force a
delta against the previous revision.

As part of this, I realized that the ellipsis parent function was
unused! That's because ellipsis mode always sends full revisions
and not deltas.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

indygreg created this revision.Aug 9 2018, 4:52 PM

Yeah, adgar and I spent a long time (and then martinvonz and I did too, I think) trying to figure out how to emit ellipsis deltas, and slowly we reached the conclusion that it wasn't easy, and given that we could assume a big pipe from server to client, we punted. It _might_ be a solvable problem, but it may cost a prohibitive amount of CPU time.

This revision was automatically updated to reflect the committed changes.

It is a hard problem because the server can't make any assumptions about what nodes the receiver has! So you either need the client to transmit the set of nodes it has. Without that, the best the server can do is encode a delta against a revision in the same delta group. And that would strictly be better than what's implemented (which is to always send a full revision!). It should be easy enough to change the logic though. Although we'd need to pass more information down to the code doing the delta generation.