[PATCH] changegroup: allow sending snapshot deltas in cg2

[Pierre-Yves David]

On 11/21/2014 05:28 PM, Matt Mackall wrote:
> On Fri, 2014-11-21 at 17:53 -0500, Mike Edgar wrote:
>> # HG changeset patch
>> # User Mike Edgar <adgar at google.com>
>> # Date 1416610038 18000
>> #      Fri Nov 21 17:47:18 2014 -0500
>> # Node ID ce1d4cdad3e2a324198a348f5a62f86e9b0e1a73
>> # Parent  a179db3db9b96b38c10c491e6e7e7ad5f40a7787
>> changegroup: allow sending snapshot deltas in cg2
>>
>> The changegroup2 format allows each revision to be sent with
>> a configurable base. That base is presently restricted to
>> p1, p2, or the previous revision in the revlog. By allowing
>> a null base, we can send snapshot deltas when it is efficient
>> to do so.
>
> Not sure what you mean by efficient here. We generally assume that
> bandwidth is more scarce than CPU, so calculating a new delta is
> generally preferred to sending a full revision. This seems to prefer the
> opposite trade-off?

This change comes to support the "Censored" nodes effort. The censored 
node cannot be used as delta base (and would likely be inefficient 
anyway) so we have an alternative. It some case it would be an easy but 
suboptinal solution to issue a full delta. In some other it will be the 
only available option.


>
>> diff -r a179db3db9b9 -r ce1d4cdad3e2 mercurial/changegroup.py
>> --- a/mercurial/changegroup.py	Wed Nov 19 23:15:07 2014 -0800
>> +++ b/mercurial/changegroup.py	Fri Nov 21 17:47:18 2014 -0500
>> @@ -455,9 +455,9 @@
>>
>>       def deltaparent(self, revlog, rev, p1, p2, prev):
>>           dp = revlog.deltaparent(rev)
>> -        # avoid storing full revisions; pick prev in those cases
>> -        # also pick prev when we can't be sure remote has dp
>> -        if dp == nullrev or (dp != p1 and dp != p2 and dp != prev):
>> +        # if revlog delta base is null, send a snapshot, no known good base.
>> +        # otherwise, pick prev when we can't be sure remote has dp
>> +        if dp != nullrev and dp != p1 and dp != p2 and dp != prev:

However, this part seems related to the create of bundle, not there 
consumption. Does this mean the unpacker already have the logic to deal 
with base againts nullrev in the middle of the stream?

-- 
Pierre-Yves David