Fossil

Check-in [b08fce49]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Clarification of the comment that describes the algorithm used to choose between a baseline manifest and a delta manifest upon checkin. No changes to code.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | experimental
Files: files | file ages | folders
SHA1: b08fce49e14bf57a2d70ff44a350fdad9cab6a3d
User & Date: drh 2010-10-21 15:42:39
Context
2010-10-21
20:08
Replace the RFC-3174 reference implementation of SHA1 with the much faster implementation from NetBSD. check-in: f8f175cf user: drh tags: experimental
15:42
Clarification of the comment that describes the algorithm used to choose between a baseline manifest and a delta manifest upon checkin. No changes to code. check-in: b08fce49 user: drh tags: experimental
14:00
Better algorithm for deciding when to use a delta-manifest on a check-in. check-in: 7c244251 user: drh tags: experimental
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to src/checkin.c.

954
955
956
957
958
959
960






961
962
963


964
965

966
967
968
969
970
971
972
973
974
    }
    if( pBaseline ){
      Blob delta;
      create_manifest(&delta, zBaselineUuid, pBaseline, &comment, vid,
                      !forceFlag, useCksum ? &cksum1 : 0,
                      zDateOvrd, zUserOvrd, zBranch, zBgColor, &szD);
      /*






      ** Let B be the number of F-cards in a baseline manifest and
      ** let D be the number of F-cards in a delta manifest, plus one for
      ** the B-card.  Assume that each delta manifest adds X new F-cards.


      ** Then to minimize the total number of F- and B-cards in the repository,
      ** we should insert a new baseline manifest whenever

      **
      **      D*D >= B*X - X*X
      **
      ** X is an unknown here, but for most repositories, we will not be
      ** far wrong if we assume X=3.
      */
      if( forceDelta || (szD*szD)<(szB*3-9) ){
        blob_reset(&manifest);
        manifest = delta;







>
>
>
>
>
>
|
|
<
>
>

<
>

|







954
955
956
957
958
959
960
961
962
963
964
965
966
967
968

969
970
971

972
973
974
975
976
977
978
979
980
981
    }
    if( pBaseline ){
      Blob delta;
      create_manifest(&delta, zBaselineUuid, pBaseline, &comment, vid,
                      !forceFlag, useCksum ? &cksum1 : 0,
                      zDateOvrd, zUserOvrd, zBranch, zBgColor, &szD);
      /*
      ** At this point, two manifests have been constructed, either of
      ** which would work for this checkin.  The first manifest (held
      ** in the "manifest" variable) is a baseline manifest and the second
      ** (held in variable named "delta") is a delta manifest.  The
      ** question now is: which manifest should we use?
      **
      ** Let B be the number of F-cards in the baseline manifest and
      ** let D be the number of F-cards in the delta manifest, plus one for

      ** the B-card.  (B is held in the szB variable and D is held in the
      ** szD variable.)  Assume that all delta manifests adds X new F-cards.
      ** Then to minimize the total number of F- and B-cards in the repository,

      ** we should use the delta manifest if and only if:
      **
      **      D*D < B*X - X*X
      **
      ** X is an unknown here, but for most repositories, we will not be
      ** far wrong if we assume X=3.
      */
      if( forceDelta || (szD*szD)<(szB*3-9) ){
        blob_reset(&manifest);
        manifest = delta;