- Dec 05, 2015
-
-
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.
-
- Dec 02, 2015
-
-
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.
-
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.
-
- Nov 07, 2015
-
-
Pierre-Yves David authored
This test check the difference between various configurations we have to pin the type of some repositories to ensure the test is still correct when we change the default.
-
- Nov 02, 2015
-
-
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.
-
- Oct 18, 2015
-
-
Pierre-Yves David authored
If general delta becomes the default, we need to be explicit about what we want to be tested.
-
- Sep 29, 2015
-
-
Pierre-Yves David authored
Storing uncompressed bundle on disk would be a regression. Strip backup using bundle2 are now compressed when requested.
-
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.
-
- Aug 30, 2015
-
-
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
-
- Nov 21, 2014
-
-
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.
-
- Oct 21, 2013
-
-
Matt Mackall authored
-
- Oct 01, 2013
-
-
Wojciech Lopata authored
-
- Sep 23, 2013
-
-
Matt Mackall authored
-
- Sep 20, 2013
-
-
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.
-