[PATCH] changegroup: allow sending snapshot deltas in cg2
mpm at selenic.com
Tue Nov 25 17:58:58 CST 2014
On Tue, 2014-11-25 at 13:17 -0800, Pierre-Yves David wrote:
> 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.
This doesn't get me any closer to answering the above concerns.
> >> 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?
It's what the general in generaldelta means: delta against any revision.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel