Skip to content
Snippets Groups Projects
  1. Dec 05, 2015
    • Martin von Zweigbergk's avatar
      revlog: don't consider nullrev when choosing delta base · d9bfe628
      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.
      d9bfe628
  2. Dec 02, 2015
    • Pierre-Yves David's avatar
      addrevision: use general delta when the incoming base delta is bad · 20a9226b
      Pierre-Yves David authored
      We unify the delta selection process to be a simple three options process:
      
      - try to use the incoming delta (if lazydeltabase is on)
      - try to find a suitable parents to delta against (if gd is on)
      - try to delta against the tipmost revision
      
      The first of this option that yield a valid delta will be used.
      
      The test change in 'test-generaldelta.t' show this behavior as we use a delta
      against the parent instead of a full delta when the incoming delta is not
      suitable.
      
      This as some impact on 'test-bundle.t' because a delta somewhere changes. It
      does not seems to change the test semantic and have been ignored.
      20a9226b
    • Pierre-Yves David's avatar
      test: use a bigger manifest in general delta test · 762fbd28
      Pierre-Yves David authored
      The currently used manifest is too small and cannot sustain a chain length
      above "1".  This make testing the 'lazybasedelta' behavior hard. So we add an
      extra file in the manifest to help testing in the next changeset.
      
      The semantic of existing tests have been checked and is not changed.
      762fbd28
  3. Nov 07, 2015
  4. Nov 02, 2015
    • Pierre-Yves David's avatar
      format: introduce 'format.usegeneraldelta` · dfab6edb
      Pierre-Yves David authored
      This option will make repositories created as general delta by default but will
      not make Mercurial aggressively recompute deltas for all incoming bundle.
      Instead, the delta contained in the bundle will be used. This will allow us to
      start having general delta repositories created everywhere without triggering
      massive recomputation costs for all new clients cloning from old servers.
      dfab6edb
  5. Oct 18, 2015
  6. Sep 29, 2015
    • Pierre-Yves David's avatar
      strip: compress bundle2 backup using BZ · eb21b667
      Pierre-Yves David authored
      Storing uncompressed bundle on disk would be a regression. Strip backup using
      bundle2 are now compressed when requested.
      eb21b667
    • Pierre-Yves David's avatar
      strip: use bundle2 + cg2 by default when repository use general delta · c93f91c1
      Pierre-Yves David authored
      The bundle10 format (plain changegroup-01) does not support general delta and
      result into expensive delta re-computation when stripping. If the repository is
      general delta, we store backups as bundle20 containing a changegroup-02 payload.
      
      We remove the experimental feature related to strip backup bundle format because
      this achieve the same goal in a leaner way. Removing the experimental option is
      fine, that is why it experimental in the first place.
      
      Compression of these bundles are coming in later changesets.
      c93f91c1
  7. Aug 30, 2015
    • Durham Goode's avatar
      revlog: add an aggressivemergedelta option · 049005de
      Durham Goode authored
      This adds an option for delta'ing against both p1 and p2 when applying merge
      revisions and picking whichever is smallest.
      
      Some before and after stats on manifest.d size:
      
      internal large repo:
      before: 1.2 GB
      after: 930 MB
      
      mozilla-central:
      before: 261 MB
      after: 92 MB
      049005de
  8. Nov 21, 2014
    • Durham Goode's avatar
      changegroup: fix file linkrevs during reorders (issue4462) · cc0ff93d
      Durham Goode authored
      Previously, if reorder was true during the creation of a changegroup bundle,
      it was possible that the manifest and filelogs would be reordered such that the
      resulting bundle filelog had a linkrev that pointed to a commit that was not
      the earliest instance of the filelog revision. For example:
      
      With commits:
      
      0<-1<---3<-4
        \       /
         --2<---
      
      if 2 and 3 added the same version of a file, if the manifests of 2 and 3 have
      their order reversed, but the changelog did not, it could produce a filelog with
      linkrevs 0<-3 instead of 0<-2, which meant if commit 3 was stripped, it would
      delete that file data from the repository and commit 2 would be corrupt (as
      would any future pulls that tried to build upon that version of the file).
      
      The fix is to make the linkrev fixup smarter. Previously it considered the first
      manifest that added a file to be the first commit that added that file, which is
      not true. Now, for every file revision we add to the bundle we make sure we
      attach it to the earliest applicable linkrev.
      cc0ff93d
  9. Oct 21, 2013
  10. Oct 01, 2013
  11. Sep 23, 2013
  12. Sep 20, 2013
    • Wojciech Lopata's avatar
      generaldelta: initialize basecache properly · e92650e3
      Wojciech Lopata authored
      Previously basecache was incorrectly initialized before adding the first
      revision from a changegroup. Basecache value influences when full revisions are
      stored in revlog (when using generaldelta). As a result it was possible to
      generate a generaldelta-revlog that could be bigger by arbitrary factor than its
      non-generaldelta equivalent.
      e92650e3
Loading