Skip to content
Snippets Groups Projects
  • Martin von Zweigbergk's avatar
    d9bfe6289acf
    revlog: don't consider nullrev when choosing delta base · d9bfe6289acf
    Martin von Zweigbergk authored
    In the most complex case, we try using the incoming delta base, then
    we try both parents, and then we try the previous revlog entry. If
    none of these result in a good delta, we natually use the null
    revision as base. However, we sometimes consider the nullrev before we
    have exhausted our other options. Specifically, when both parents are
    null, we use the nullrev as delta base if it produces a good delta
    (according to _isgooddelta()), and we fail to try the previous revlog
    entry as delta base. After 20a9226bdc8a (addrevision: use general
    delta when the incoming base delta is bad, 2015-12-01), it can also
    happen for non-merge commits when the incoming delta is not good.
    
    The Firefox repo (from many months back) shrinks a tiny bit with this
    patch: from 1.855GB to 1.830GB (1.4%). The hg repo itself shrinks even
    less: by less than 0.1%. There may be repos that get larger instead.
    
    This undoes the unexplained test change in 20a9226bdc8a.
    d9bfe6289acf
    History
    revlog: don't consider nullrev when choosing delta base
    Martin von Zweigbergk authored
    In the most complex case, we try using the incoming delta base, then
    we try both parents, and then we try the previous revlog entry. If
    none of these result in a good delta, we natually use the null
    revision as base. However, we sometimes consider the nullrev before we
    have exhausted our other options. Specifically, when both parents are
    null, we use the nullrev as delta base if it produces a good delta
    (according to _isgooddelta()), and we fail to try the previous revlog
    entry as delta base. After 20a9226bdc8a (addrevision: use general
    delta when the incoming base delta is bad, 2015-12-01), it can also
    happen for non-merge commits when the incoming delta is not good.
    
    The Firefox repo (from many months back) shrinks a tiny bit with this
    patch: from 1.855GB to 1.830GB (1.4%). The hg repo itself shrinks even
    less: by less than 0.1%. There may be repos that get larger instead.
    
    This undoes the unexplained test change in 20a9226bdc8a.