Fossil SCM
Resolve broken hyperlinks and other minor cleanup in the documentation.
Commit
16094f7ebc5a6bdf91c10e51252dcbe273151a00
Parent
a4d7e9162dc506a…
7 files changed
+1
-1
+1
+19
-18
+38
-27
+1
-1
+3
-2
+4
-2
+1
-1
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -4,11 +4,11 @@ | ||
| 4 | 4 | whole process is designed to be very easy.</p> |
| 5 | 5 | |
| 6 | 6 | <h2>0.0 Using A Precompiled Binary</h2> |
| 7 | 7 | |
| 8 | 8 | <p>You can skip steps 1.0 and 2.0 below by downloading |
| 9 | -a <a href="http://www.fossil-scm.org/download.html">FIXME precompiled binary</a> | |
| 9 | +a <a href="http://www.fossil-scm.org/download.html">precompiled binary</a> | |
| 10 | 10 | appropriate for your platform. If you use a precompiled binary |
| 11 | 11 | jump immediate to step 3.0.</p> |
| 12 | 12 | |
| 13 | 13 | <h2>1.0 Obtaining The Source Code</h2> |
| 14 | 14 | |
| 15 | 15 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -4,11 +4,11 @@ | |
| 4 | whole process is designed to be very easy.</p> |
| 5 | |
| 6 | <h2>0.0 Using A Precompiled Binary</h2> |
| 7 | |
| 8 | <p>You can skip steps 1.0 and 2.0 below by downloading |
| 9 | a <a href="http://www.fossil-scm.org/download.html">FIXME precompiled binary</a> |
| 10 | appropriate for your platform. If you use a precompiled binary |
| 11 | jump immediate to step 3.0.</p> |
| 12 | |
| 13 | <h2>1.0 Obtaining The Source Code</h2> |
| 14 | |
| 15 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -4,11 +4,11 @@ | |
| 4 | whole process is designed to be very easy.</p> |
| 5 | |
| 6 | <h2>0.0 Using A Precompiled Binary</h2> |
| 7 | |
| 8 | <p>You can skip steps 1.0 and 2.0 below by downloading |
| 9 | a <a href="http://www.fossil-scm.org/download.html">precompiled binary</a> |
| 10 | appropriate for your platform. If you use a precompiled binary |
| 11 | jump immediate to step 3.0.</p> |
| 12 | |
| 13 | <h2>1.0 Obtaining The Source Code</h2> |
| 14 | |
| 15 |
+1
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -207,10 +207,11 @@ | ||
| 207 | 207 | token after the name of the fossil executable, as shown above.</p> |
| 208 | 208 | |
| 209 | 209 | <h2>4.0 Workflow</h2> |
| 210 | 210 | |
| 211 | 211 | <img src="concept2.gif" align="right" hspace="10"> |
| 212 | + | |
| 212 | 213 | <ol> |
| 213 | 214 | <li><p> |
| 214 | 215 | Establish a local repository using either the <b>new</b> command |
| 215 | 216 | to start a new project, or the <b>clone</b> command to make a clone |
| 216 | 217 | of a repository for an existing project. |
| 217 | 218 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -207,10 +207,11 @@ | |
| 207 | token after the name of the fossil executable, as shown above.</p> |
| 208 | |
| 209 | <h2>4.0 Workflow</h2> |
| 210 | |
| 211 | <img src="concept2.gif" align="right" hspace="10"> |
| 212 | <ol> |
| 213 | <li><p> |
| 214 | Establish a local repository using either the <b>new</b> command |
| 215 | to start a new project, or the <b>clone</b> command to make a clone |
| 216 | of a repository for an existing project. |
| 217 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -207,10 +207,11 @@ | |
| 207 | token after the name of the fossil executable, as shown above.</p> |
| 208 | |
| 209 | <h2>4.0 Workflow</h2> |
| 210 | |
| 211 | <img src="concept2.gif" align="right" hspace="10"> |
| 212 | |
| 213 | <ol> |
| 214 | <li><p> |
| 215 | Establish a local repository using either the <b>new</b> command |
| 216 | to start a new project, or the <b>clone</b> command to make a clone |
| 217 | of a repository for an existing project. |
| 218 |
+19
-18
| --- www/delta_encoder_algorithm.wiki | ||
| +++ www/delta_encoder_algorithm.wiki | ||
| @@ -1,5 +1,6 @@ | ||
| 1 | +<nowiki> | |
| 1 | 2 | <h1 align="center"> |
| 2 | 3 | Fossil Delta Encoding Algorithm |
| 3 | 4 | </h1> |
| 4 | 5 | |
| 5 | 6 | <p>A key component for the efficient storage of multiple revisions of |
| @@ -7,21 +8,21 @@ | ||
| 7 | 8 | store only the changes between revisions instead of the whole |
| 8 | 9 | file.</p> |
| 9 | 10 | |
| 10 | 11 | <p>This document describes the encoding algorithm used by Fossil to |
| 11 | 12 | generate deltas. It is targeted at developers working on either |
| 12 | -<a href="index.html">fossil</a> itself, or on tools compatible with | |
| 13 | +<a href="index.wiki">fossil</a> itself, or on tools compatible with | |
| 13 | 14 | it. The exact format of the generated byte-sequences, while in general |
| 14 | 15 | not necessary to understand encoder operation, can be found in the |
| 15 | -companion specification titled "<a href="delta_format.html">Fossil | |
| 16 | +companion specification titled "<a href="delta_format.wiki">Fossil | |
| 16 | 17 | Delta Format</a>". |
| 17 | 18 | </p> |
| 18 | 19 | |
| 19 | 20 | <p>The entire algorithm is inspired |
| 20 | 21 | by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p> |
| 21 | 22 | |
| 22 | -<a name="argresparam"><h2>1.0 Arguments, Results, and Parameters</h2> | |
| 23 | +<a name="argresparam"></a><h2>1.0 Arguments, Results, and Parameters</h2> | |
| 23 | 24 | |
| 24 | 25 | <p>The encoder takes two byte-sequences as input, the "original", and |
| 25 | 26 | the "target", and returns a single byte-sequence containing the |
| 26 | 27 | "delta" which transforms the original into the target upon its |
| 27 | 28 | application.</p> |
| @@ -33,28 +34,28 @@ | ||
| 33 | 34 | "sliding window" for the "rolling hash", in bytes. These two terms are |
| 34 | 35 | explained in the next section. The value of this parameter has to be a |
| 35 | 36 | power of two for the algorithm to work. For Fossil the value of this |
| 36 | 37 | parameter is set to "16".</p> |
| 37 | 38 | |
| 38 | -<a name="operation"><h2>2.0 Operation</h2> | |
| 39 | +<a name="operation"></a><h2>2.0 Operation</h2> | |
| 39 | 40 | |
| 40 | 41 | <p>The algorithm is split into three phases which generate |
| 41 | -the <a href="delta_format.html#header">header</a>, | |
| 42 | -<a href="delta_format.html#slist">segment list</a>, | |
| 43 | -and <a href="delta_format.html#trailer">trailer</a> of the delta, per | |
| 44 | -its general <a href="delta_format.html#structure">structure</a>.</p> | |
| 42 | +the <a href="delta_format.wiki#header">header</a>, | |
| 43 | +<a href="delta_format.wiki#slist">segment list</a>, | |
| 44 | +and <a href="delta_format.wiki#trailer">trailer</a> of the delta, per | |
| 45 | +its general <a href="delta_format.wiki#structure">structure</a>.</p> | |
| 45 | 46 | |
| 46 | 47 | <p>The two phases generating header and trailer are not covered here |
| 47 | 48 | as their implementation trivially follows directly from the |
| 48 | -specification of the <a href="delta_format.html">delta format</a>.</p> | |
| 49 | +specification of the <a href="delta_format.wiki">delta format</a>.</p> | |
| 49 | 50 | |
| 50 | 51 | <p>This leaves the segment-list. Its generation is done in two phases, |
| 51 | 52 | a pre-processing step operating on the "original" byte-sequence, |
| 52 | 53 | followed by the processing of the "target" byte-sequence using the |
| 53 | 54 | information gathered by the first step.</p> |
| 54 | 55 | |
| 55 | -<a name="preprocessing"><h3>2.1 Preprocessing the original</h3> | |
| 56 | +<a name="preprocessing"></a><h3>2.1 Preprocessing the original</h3> | |
| 56 | 57 | |
| 57 | 58 | <p>A major part of the processing of the "target" is to find a range |
| 58 | 59 | in the "original" which contains the same content as found at the |
| 59 | 60 | current location in the "target".</p> |
| 60 | 61 | |
| @@ -83,11 +84,11 @@ | ||
| 83 | 84 | <li>A hashtable is filled, mapping from the hashes of the chunks to |
| 84 | 85 | the list of chunk locations having this hash. |
| 85 | 86 | </li> |
| 86 | 87 | </ol> |
| 87 | 88 | |
| 88 | -<a name="processing"><h3>2.1 Processing the target</h3> | |
| 89 | +<a name="processing"></a><h3>2.1 Processing the target</h3> | |
| 89 | 90 | |
| 90 | 91 | <p>This, the main phase of the encoder, processes the target in a loop |
| 91 | 92 | from beginning to end. The state of the encoder is captured by two |
| 92 | 93 | locations, the "base" and the "slide". "base" points to the first byte |
| 93 | 94 | of the target for which no delta output has been generated yet, and |
| @@ -96,15 +97,15 @@ | ||
| 96 | 97 | |
| 97 | 98 | <p>Initially both "base" and "slide" point to the beginning of the |
| 98 | 99 | "target". In each iteration of the loop the encoder decides whether to |
| 99 | 100 | <ul> |
| 100 | 101 | <li>emit a single instruction |
| 101 | -to <a href="delta_format.html#copyrange">copy a range</a>, or | |
| 102 | +to <a href="delta_format.wiki#copyrange">copy a range</a>, or | |
| 102 | 103 | </li> |
| 103 | 104 | <li>emit two instructions, first |
| 104 | -to <a href="delta_format.html#insertlit">insert a literal</a>, then | |
| 105 | -to <a href="delta_format.html#copyrange">copy a range</a>, or | |
| 105 | +to <a href="delta_format.wiki#insertlit">insert a literal</a>, then | |
| 106 | +to <a href="delta_format.wiki#copyrange">copy a range</a>, or | |
| 106 | 107 | </li> |
| 107 | 108 | <li>move the window forward one byte. |
| 108 | 109 | </li> |
| 109 | 110 | </ul> |
| 110 | 111 | </p> |
| @@ -167,29 +168,29 @@ | ||
| 167 | 168 | <p>If the processing loop left bytes unencoded, i.e. "base" not |
| 168 | 169 | exactly at the end of the "target", as is possible for both end |
| 169 | 170 | conditions, then one last insert instruction is emitted to put these |
| 170 | 171 | bytes into the delta.<p> |
| 171 | 172 | |
| 172 | -<a name="exceptions"><h2>3.0 Exceptions</h2> | |
| 173 | +<a name="exceptions"></a><h2>3.0 Exceptions</h2> | |
| 173 | 174 | |
| 174 | 175 | <p>If the "original" is at most NHASH bytes long no compression of |
| 175 | 176 | changes is possible, and the segment-list of the delta consists of a |
| 176 | 177 | single literal which contains the entire "target".</p> |
| 177 | 178 | |
| 178 | 179 | <p>This is actually equivalent to the second end condition of the |
| 179 | 180 | processing loop described in the previous section, just checked before |
| 180 | 181 | actually entering the loop.</p> |
| 181 | 182 | |
| 182 | -<a name="rollhash"><h2>4.0 The rolling hash</h2> | |
| 183 | +<a name="rollhash"></a><h2>4.0 The rolling hash</h2> | |
| 183 | 184 | |
| 184 | 185 | <p>The rolling hash described below and used to compute content |
| 185 | 186 | signatures was chosen not only for good hashing properties, but also |
| 186 | 187 | to enable the easy (incremental) recalculation of its value for a |
| 187 | 188 | sliding window, i.e. where the oldest byte is removed from the window |
| 188 | 189 | and a new byte is shifted in.<p> |
| 189 | 190 | |
| 190 | -<a name="rhdef"><h3>4.1 Definition</h3> | |
| 191 | +<a name="rhdef"></a><h3>4.1 Definition</h3> | |
| 191 | 192 | |
| 192 | 193 | <p>Assuming an array Z of NHASH bytes (indexing starting at 0) the |
| 193 | 194 | hash V is computed via</p> |
| 194 | 195 | |
| 195 | 196 | <p align=center><table><tr><td> |
| @@ -199,11 +200,11 @@ | ||
| 199 | 200 | </td></tr></table></p> |
| 200 | 201 | |
| 201 | 202 | where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and |
| 202 | 203 | V is a 32-bit unsigned integer with B as MSB, A as LSB. |
| 203 | 204 | |
| 204 | -<a name="rhincr"><h3>4.2 Incremental recalculation</h3> | |
| 205 | +<a name="rhincr"></a><h3>4.2 Incremental recalculation</h3> | |
| 205 | 206 | |
| 206 | 207 | <p>Assuming an array Z of NHASH bytes (indexing starting at 0) with |
| 207 | 208 | hash V (and components A and B), the dropped |
| 208 | 209 | byte <img src="encode4.gif" align="center">, and the new byte |
| 209 | 210 | <img src="encode5.gif" align="center"> , the new hash can |
| 210 | 211 |
| --- www/delta_encoder_algorithm.wiki | |
| +++ www/delta_encoder_algorithm.wiki | |
| @@ -1,5 +1,6 @@ | |
| 1 | <h1 align="center"> |
| 2 | Fossil Delta Encoding Algorithm |
| 3 | </h1> |
| 4 | |
| 5 | <p>A key component for the efficient storage of multiple revisions of |
| @@ -7,21 +8,21 @@ | |
| 7 | store only the changes between revisions instead of the whole |
| 8 | file.</p> |
| 9 | |
| 10 | <p>This document describes the encoding algorithm used by Fossil to |
| 11 | generate deltas. It is targeted at developers working on either |
| 12 | <a href="index.html">fossil</a> itself, or on tools compatible with |
| 13 | it. The exact format of the generated byte-sequences, while in general |
| 14 | not necessary to understand encoder operation, can be found in the |
| 15 | companion specification titled "<a href="delta_format.html">Fossil |
| 16 | Delta Format</a>". |
| 17 | </p> |
| 18 | |
| 19 | <p>The entire algorithm is inspired |
| 20 | by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p> |
| 21 | |
| 22 | <a name="argresparam"><h2>1.0 Arguments, Results, and Parameters</h2> |
| 23 | |
| 24 | <p>The encoder takes two byte-sequences as input, the "original", and |
| 25 | the "target", and returns a single byte-sequence containing the |
| 26 | "delta" which transforms the original into the target upon its |
| 27 | application.</p> |
| @@ -33,28 +34,28 @@ | |
| 33 | "sliding window" for the "rolling hash", in bytes. These two terms are |
| 34 | explained in the next section. The value of this parameter has to be a |
| 35 | power of two for the algorithm to work. For Fossil the value of this |
| 36 | parameter is set to "16".</p> |
| 37 | |
| 38 | <a name="operation"><h2>2.0 Operation</h2> |
| 39 | |
| 40 | <p>The algorithm is split into three phases which generate |
| 41 | the <a href="delta_format.html#header">header</a>, |
| 42 | <a href="delta_format.html#slist">segment list</a>, |
| 43 | and <a href="delta_format.html#trailer">trailer</a> of the delta, per |
| 44 | its general <a href="delta_format.html#structure">structure</a>.</p> |
| 45 | |
| 46 | <p>The two phases generating header and trailer are not covered here |
| 47 | as their implementation trivially follows directly from the |
| 48 | specification of the <a href="delta_format.html">delta format</a>.</p> |
| 49 | |
| 50 | <p>This leaves the segment-list. Its generation is done in two phases, |
| 51 | a pre-processing step operating on the "original" byte-sequence, |
| 52 | followed by the processing of the "target" byte-sequence using the |
| 53 | information gathered by the first step.</p> |
| 54 | |
| 55 | <a name="preprocessing"><h3>2.1 Preprocessing the original</h3> |
| 56 | |
| 57 | <p>A major part of the processing of the "target" is to find a range |
| 58 | in the "original" which contains the same content as found at the |
| 59 | current location in the "target".</p> |
| 60 | |
| @@ -83,11 +84,11 @@ | |
| 83 | <li>A hashtable is filled, mapping from the hashes of the chunks to |
| 84 | the list of chunk locations having this hash. |
| 85 | </li> |
| 86 | </ol> |
| 87 | |
| 88 | <a name="processing"><h3>2.1 Processing the target</h3> |
| 89 | |
| 90 | <p>This, the main phase of the encoder, processes the target in a loop |
| 91 | from beginning to end. The state of the encoder is captured by two |
| 92 | locations, the "base" and the "slide". "base" points to the first byte |
| 93 | of the target for which no delta output has been generated yet, and |
| @@ -96,15 +97,15 @@ | |
| 96 | |
| 97 | <p>Initially both "base" and "slide" point to the beginning of the |
| 98 | "target". In each iteration of the loop the encoder decides whether to |
| 99 | <ul> |
| 100 | <li>emit a single instruction |
| 101 | to <a href="delta_format.html#copyrange">copy a range</a>, or |
| 102 | </li> |
| 103 | <li>emit two instructions, first |
| 104 | to <a href="delta_format.html#insertlit">insert a literal</a>, then |
| 105 | to <a href="delta_format.html#copyrange">copy a range</a>, or |
| 106 | </li> |
| 107 | <li>move the window forward one byte. |
| 108 | </li> |
| 109 | </ul> |
| 110 | </p> |
| @@ -167,29 +168,29 @@ | |
| 167 | <p>If the processing loop left bytes unencoded, i.e. "base" not |
| 168 | exactly at the end of the "target", as is possible for both end |
| 169 | conditions, then one last insert instruction is emitted to put these |
| 170 | bytes into the delta.<p> |
| 171 | |
| 172 | <a name="exceptions"><h2>3.0 Exceptions</h2> |
| 173 | |
| 174 | <p>If the "original" is at most NHASH bytes long no compression of |
| 175 | changes is possible, and the segment-list of the delta consists of a |
| 176 | single literal which contains the entire "target".</p> |
| 177 | |
| 178 | <p>This is actually equivalent to the second end condition of the |
| 179 | processing loop described in the previous section, just checked before |
| 180 | actually entering the loop.</p> |
| 181 | |
| 182 | <a name="rollhash"><h2>4.0 The rolling hash</h2> |
| 183 | |
| 184 | <p>The rolling hash described below and used to compute content |
| 185 | signatures was chosen not only for good hashing properties, but also |
| 186 | to enable the easy (incremental) recalculation of its value for a |
| 187 | sliding window, i.e. where the oldest byte is removed from the window |
| 188 | and a new byte is shifted in.<p> |
| 189 | |
| 190 | <a name="rhdef"><h3>4.1 Definition</h3> |
| 191 | |
| 192 | <p>Assuming an array Z of NHASH bytes (indexing starting at 0) the |
| 193 | hash V is computed via</p> |
| 194 | |
| 195 | <p align=center><table><tr><td> |
| @@ -199,11 +200,11 @@ | |
| 199 | </td></tr></table></p> |
| 200 | |
| 201 | where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and |
| 202 | V is a 32-bit unsigned integer with B as MSB, A as LSB. |
| 203 | |
| 204 | <a name="rhincr"><h3>4.2 Incremental recalculation</h3> |
| 205 | |
| 206 | <p>Assuming an array Z of NHASH bytes (indexing starting at 0) with |
| 207 | hash V (and components A and B), the dropped |
| 208 | byte <img src="encode4.gif" align="center">, and the new byte |
| 209 | <img src="encode5.gif" align="center"> , the new hash can |
| 210 |
| --- www/delta_encoder_algorithm.wiki | |
| +++ www/delta_encoder_algorithm.wiki | |
| @@ -1,5 +1,6 @@ | |
| 1 | <nowiki> |
| 2 | <h1 align="center"> |
| 3 | Fossil Delta Encoding Algorithm |
| 4 | </h1> |
| 5 | |
| 6 | <p>A key component for the efficient storage of multiple revisions of |
| @@ -7,21 +8,21 @@ | |
| 8 | store only the changes between revisions instead of the whole |
| 9 | file.</p> |
| 10 | |
| 11 | <p>This document describes the encoding algorithm used by Fossil to |
| 12 | generate deltas. It is targeted at developers working on either |
| 13 | <a href="index.wiki">fossil</a> itself, or on tools compatible with |
| 14 | it. The exact format of the generated byte-sequences, while in general |
| 15 | not necessary to understand encoder operation, can be found in the |
| 16 | companion specification titled "<a href="delta_format.wiki">Fossil |
| 17 | Delta Format</a>". |
| 18 | </p> |
| 19 | |
| 20 | <p>The entire algorithm is inspired |
| 21 | by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p> |
| 22 | |
| 23 | <a name="argresparam"></a><h2>1.0 Arguments, Results, and Parameters</h2> |
| 24 | |
| 25 | <p>The encoder takes two byte-sequences as input, the "original", and |
| 26 | the "target", and returns a single byte-sequence containing the |
| 27 | "delta" which transforms the original into the target upon its |
| 28 | application.</p> |
| @@ -33,28 +34,28 @@ | |
| 34 | "sliding window" for the "rolling hash", in bytes. These two terms are |
| 35 | explained in the next section. The value of this parameter has to be a |
| 36 | power of two for the algorithm to work. For Fossil the value of this |
| 37 | parameter is set to "16".</p> |
| 38 | |
| 39 | <a name="operation"></a><h2>2.0 Operation</h2> |
| 40 | |
| 41 | <p>The algorithm is split into three phases which generate |
| 42 | the <a href="delta_format.wiki#header">header</a>, |
| 43 | <a href="delta_format.wiki#slist">segment list</a>, |
| 44 | and <a href="delta_format.wiki#trailer">trailer</a> of the delta, per |
| 45 | its general <a href="delta_format.wiki#structure">structure</a>.</p> |
| 46 | |
| 47 | <p>The two phases generating header and trailer are not covered here |
| 48 | as their implementation trivially follows directly from the |
| 49 | specification of the <a href="delta_format.wiki">delta format</a>.</p> |
| 50 | |
| 51 | <p>This leaves the segment-list. Its generation is done in two phases, |
| 52 | a pre-processing step operating on the "original" byte-sequence, |
| 53 | followed by the processing of the "target" byte-sequence using the |
| 54 | information gathered by the first step.</p> |
| 55 | |
| 56 | <a name="preprocessing"></a><h3>2.1 Preprocessing the original</h3> |
| 57 | |
| 58 | <p>A major part of the processing of the "target" is to find a range |
| 59 | in the "original" which contains the same content as found at the |
| 60 | current location in the "target".</p> |
| 61 | |
| @@ -83,11 +84,11 @@ | |
| 84 | <li>A hashtable is filled, mapping from the hashes of the chunks to |
| 85 | the list of chunk locations having this hash. |
| 86 | </li> |
| 87 | </ol> |
| 88 | |
| 89 | <a name="processing"></a><h3>2.1 Processing the target</h3> |
| 90 | |
| 91 | <p>This, the main phase of the encoder, processes the target in a loop |
| 92 | from beginning to end. The state of the encoder is captured by two |
| 93 | locations, the "base" and the "slide". "base" points to the first byte |
| 94 | of the target for which no delta output has been generated yet, and |
| @@ -96,15 +97,15 @@ | |
| 97 | |
| 98 | <p>Initially both "base" and "slide" point to the beginning of the |
| 99 | "target". In each iteration of the loop the encoder decides whether to |
| 100 | <ul> |
| 101 | <li>emit a single instruction |
| 102 | to <a href="delta_format.wiki#copyrange">copy a range</a>, or |
| 103 | </li> |
| 104 | <li>emit two instructions, first |
| 105 | to <a href="delta_format.wiki#insertlit">insert a literal</a>, then |
| 106 | to <a href="delta_format.wiki#copyrange">copy a range</a>, or |
| 107 | </li> |
| 108 | <li>move the window forward one byte. |
| 109 | </li> |
| 110 | </ul> |
| 111 | </p> |
| @@ -167,29 +168,29 @@ | |
| 168 | <p>If the processing loop left bytes unencoded, i.e. "base" not |
| 169 | exactly at the end of the "target", as is possible for both end |
| 170 | conditions, then one last insert instruction is emitted to put these |
| 171 | bytes into the delta.<p> |
| 172 | |
| 173 | <a name="exceptions"></a><h2>3.0 Exceptions</h2> |
| 174 | |
| 175 | <p>If the "original" is at most NHASH bytes long no compression of |
| 176 | changes is possible, and the segment-list of the delta consists of a |
| 177 | single literal which contains the entire "target".</p> |
| 178 | |
| 179 | <p>This is actually equivalent to the second end condition of the |
| 180 | processing loop described in the previous section, just checked before |
| 181 | actually entering the loop.</p> |
| 182 | |
| 183 | <a name="rollhash"></a><h2>4.0 The rolling hash</h2> |
| 184 | |
| 185 | <p>The rolling hash described below and used to compute content |
| 186 | signatures was chosen not only for good hashing properties, but also |
| 187 | to enable the easy (incremental) recalculation of its value for a |
| 188 | sliding window, i.e. where the oldest byte is removed from the window |
| 189 | and a new byte is shifted in.<p> |
| 190 | |
| 191 | <a name="rhdef"></a><h3>4.1 Definition</h3> |
| 192 | |
| 193 | <p>Assuming an array Z of NHASH bytes (indexing starting at 0) the |
| 194 | hash V is computed via</p> |
| 195 | |
| 196 | <p align=center><table><tr><td> |
| @@ -199,11 +200,11 @@ | |
| 200 | </td></tr></table></p> |
| 201 | |
| 202 | where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and |
| 203 | V is a 32-bit unsigned integer with B as MSB, A as LSB. |
| 204 | |
| 205 | <a name="rhincr"></a><h3>4.2 Incremental recalculation</h3> |
| 206 | |
| 207 | <p>Assuming an array Z of NHASH bytes (indexing starting at 0) with |
| 208 | hash V (and components A and B), the dropped |
| 209 | byte <img src="encode4.gif" align="center">, and the new byte |
| 210 | <img src="encode5.gif" align="center"> , the new hash can |
| 211 |
+38
-27
| --- www/delta_format.wiki | ||
| +++ www/delta_format.wiki | ||
| @@ -1,30 +1,43 @@ | ||
| 1 | +<nowiki> | |
| 1 | 2 | <h1 align="center"> |
| 2 | 3 | Fossil Delta Format |
| 3 | 4 | </h1> |
| 4 | 5 | |
| 5 | -<p>A key component for the efficient storage of multiple revisions of | |
| 6 | -a file in fossil repositories is the use of delta-compression, i.e. to | |
| 7 | -store only the changes between revisions instead of the whole | |
| 8 | -file.</p> | |
| 9 | - | |
| 10 | -<p>This document describes the format used to encode such changes, | |
| 11 | -also known as "delta". It is targeted at developers working on either | |
| 12 | -<a href="index.html">fossil</a> itself, or on tools compatible with | |
| 13 | -it.</p> | |
| 14 | - | |
| 15 | -<a name="structure"><h2>1.0 Structure</h2> | |
| 6 | +<p>Fossil achieves efficient storage and low-bandwidth synchronization | |
| 7 | +through the use of delta-compression. Instead of storing | |
| 8 | +or transmitting the complete content of an artifact, fossil stores or | |
| 9 | +transmits only the changes relative to a related artifact. | |
| 10 | +</p> | |
| 11 | + | |
| 12 | +<p>This document describes the delta-encoding format used by fossil. | |
| 13 | +The intended audience is developers working on either | |
| 14 | +<a href="index.wiki">fossil</a> itself, or on tools compatible with | |
| 15 | +fossil.</p> | |
| 16 | + | |
| 17 | +<p>Note that the delta-encoding is not a fundamental element of the | |
| 18 | +state of a fossil repository. A state of a fossil repository is | |
| 19 | +defined by the uncompressed and undeltaed content of all artifacts. | |
| 20 | +The fact the artifacts | |
| 21 | +are stored on disk using this delta-encoding format is merely an | |
| 22 | +optimization. One could, in theory, create an entirely new and | |
| 23 | +compatible implementation of fossil that used a different delta-encoding | |
| 24 | +or did no delta-encoding at all. However, experience has shown that | |
| 25 | +the delta-encoding described here is both efficient to compute and | |
| 26 | +results in very small deltas, so its continued use is recommended.</p> | |
| 27 | + | |
| 28 | +<a name="structure"></a><h2>1.0 Structure</h2> | |
| 16 | 29 | <img src="delta1.gif" align="left" hspace="10"> |
| 17 | 30 | |
| 18 | 31 | <p>A delta consists of three parts, a "header", a "trailer", and a |
| 19 | 32 | "segment-list" between them.</p> |
| 20 | 33 | |
| 21 | 34 | <p>Both header and trailer provide information about the target |
| 22 | 35 | helping the decoder, and the segment-list describes how the target can |
| 23 | 36 | be constructed from the original.</p> |
| 24 | 37 | |
| 25 | -<a name="header"><h3>1.1 Header</h3> | |
| 38 | +<a name="header"></a><h3>1.1 Header</h3> | |
| 26 | 39 | <img src="delta6.gif" align="left" hspace="10"> |
| 27 | 40 | |
| 28 | 41 | <p>The header consists of a single number followed by a newline |
| 29 | 42 | character (ASCII 0x0a). The number is the length of the target in |
| 30 | 43 | bytes.</p> |
| @@ -32,11 +45,11 @@ | ||
| 32 | 45 | <p>This means that, given a delta, the decoder can compute the size of |
| 33 | 46 | the target (and allocate any necessary memory based on that) by simply |
| 34 | 47 | reading the first line of the delta and decoding the number found |
| 35 | 48 | there. In other words, before it has to decode everything else.</p> |
| 36 | 49 | |
| 37 | -<a name="trailer"><h3>1.2 Trailer</h3> | |
| 50 | +<a name="trailer"></a><h3>1.2 Trailer</h3> | |
| 38 | 51 | <img src="delta5.gif" align="left" hspace="10"> |
| 39 | 52 | |
| 40 | 53 | <p>The trailer consists of a single number followed by a semicolon (ASCII |
| 41 | 54 | 0x3b). This number is a checksum of the target and can be used by a |
| 42 | 55 | decoder to verify that the delta applied correctly, reconstructing the |
| @@ -49,11 +62,11 @@ | ||
| 49 | 62 | |
| 50 | 63 | <p>By putting this information at the end of the delta a decoder has |
| 51 | 64 | it available immediately after the target has been reconstructed |
| 52 | 65 | fully.</p> |
| 53 | 66 | |
| 54 | -<a name="slist"><h3>1.3 Segment-List</h3> | |
| 67 | +<a name="slist"></a><h3>1.3 Segment-List</h3> | |
| 55 | 68 | <img src="delta2.gif" align="left" hspace="10"> |
| 56 | 69 | |
| 57 | 70 | <p>The segment-list of a delta describes how to create the target from |
| 58 | 71 | the original by a combination of inserting literal byte-sequences and |
| 59 | 72 | copying ranges of bytes from the original. This is there the |
| @@ -62,20 +75,20 @@ | ||
| 62 | 75 | |
| 63 | 76 | <p>The target is constructed from beginning to end, with the data |
| 64 | 77 | generated by each instruction appended after the data of all previous |
| 65 | 78 | instructions, with no gaps.</p> |
| 66 | 79 | |
| 67 | -<a name="insertlit"><h4>1.3.1 Insert Literal</h4> | |
| 80 | +<a name="insertlit"></a><h4>1.3.1 Insert Literal</h4> | |
| 68 | 81 | |
| 69 | 82 | <p>A literal is specified by two elements, the size of the literal in |
| 70 | 83 | bytes, and the bytes of the literal itself.</p> |
| 71 | 84 | |
| 72 | 85 | <img src="delta4.gif" align="left" hspace="10"> |
| 73 | 86 | <p>The length is written first, followed by a colon character (ASCII |
| 74 | 87 | 0x3a), followed by the bytes of the literal.</p> |
| 75 | 88 | |
| 76 | -<a name="copyrange"><h4>1.3.2 Copy Range</h4> | |
| 89 | +<a name="copyrange"></a><h4>1.3.2 Copy Range</h4> | |
| 77 | 90 | |
| 78 | 91 | <p>A range to copy is specified by two numbers, the offset of the |
| 79 | 92 | first byte in the original to copy, and the size of the range, in |
| 80 | 93 | bytes. The size zero is special, its usage indicates that the range |
| 81 | 94 | extends to the end of the original.</p> |
| @@ -82,11 +95,11 @@ | ||
| 82 | 95 | |
| 83 | 96 | <img src="delta3.gif" align="left" hspace="10"> |
| 84 | 97 | <p>The length is written first, followed by an "at" character (ASCII |
| 85 | 98 | 0x40), then the offset, followed by a comma (ASCII 0x2c).</p> |
| 86 | 99 | |
| 87 | -<a name="intcoding"><h2>2.0 Encoding of integers</h2> | |
| 100 | +<a name="intcoding"></a><h2>2.0 Encoding of integers</h2> | |
| 88 | 101 | |
| 89 | 102 | <p> |
| 90 | 103 | The format currently handles only 32 bit integer numbers. They are |
| 91 | 104 | written base-64 encoded, MSB first, and without leading |
| 92 | 105 | "0"-characters, except if they are significant (i.e. 0 => "0"). |
| @@ -95,13 +108,13 @@ | ||
| 95 | 108 | <p> |
| 96 | 109 | The base-64 coding is described in |
| 97 | 110 | <a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>. |
| 98 | 111 | </p> |
| 99 | 112 | |
| 100 | -<a name="examples"><h2>3.0 Examples</h2> | |
| 113 | +<a name="examples"></a><h2>3.0 Examples</h2> | |
| 101 | 114 | |
| 102 | -<a name="examplesint"><h3>3.1 Integer encoding</h3> | |
| 115 | +<a name="examplesint"></a><h3>3.1 Integer encoding</h3> | |
| 103 | 116 | |
| 104 | 117 | <table border=1> |
| 105 | 118 | <tr> |
| 106 | 119 | <th>Value</th> |
| 107 | 120 | <th>Encoding</th> |
| @@ -118,11 +131,11 @@ | ||
| 118 | 131 | <td>-1101438770</td> |
| 119 | 132 | <td>2zMM3E</td> |
| 120 | 133 | </tr> |
| 121 | 134 | </table> |
| 122 | 135 | |
| 123 | -<a name="examplesdelta"><h3>3.2 Delta encoding</h3> | |
| 136 | +<a name="examplesdelta"></a><h3>3.2 Delta encoding</h3> | |
| 124 | 137 | |
| 125 | 138 | <p>An example of a delta using the specified encoding is:</p> |
| 126 | 139 | |
| 127 | 140 | <table border=1><tr><td><pre> |
| 128 | 141 | 1Xb |
| @@ -194,20 +207,18 @@ | ||
| 194 | 207 | |
| 195 | 208 | </pre></td></tr></table> |
| 196 | 209 | |
| 197 | 210 | |
| 198 | 211 | |
| 199 | -<a name="notes"><h2>Notes</h2> | |
| 212 | +<a name="notes"></a><h2>Notes</h2> | |
| 200 | 213 | |
| 201 | 214 | <ul> |
| 202 | 215 | <li>Pure text files generate a pure text delta. |
| 203 | 216 | </li> |
| 204 | 217 | <li>Binary files generate a delta that may contain some binary data. |
| 205 | 218 | </li> |
| 206 | -<li>Instead of putting special instructions for general compression | |
| 207 | -into the delta-format itself, specifically the segment-list, like | |
| 208 | -run-length encoding of literals, etc. it was considered to be much | |
| 209 | -more sensible to keep the various concern separate and use a general | |
| 210 | -compression library, like <a href="http://www.zlib.net">zlib</a>, to | |
| 211 | -compress the full delta after its generation. | |
| 219 | +<li>The delta encoding does not attempt to compress the content | |
| 220 | +It was considered to be much | |
| 221 | +more sensible to do compression using a separate general-purpose | |
| 222 | +compression library, like <a href="http://www.zlib.net">zlib</a>. | |
| 212 | 223 | </li> |
| 213 | 224 | </ul> |
| 214 | 225 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -1,30 +1,43 @@ | |
| 1 | <h1 align="center"> |
| 2 | Fossil Delta Format |
| 3 | </h1> |
| 4 | |
| 5 | <p>A key component for the efficient storage of multiple revisions of |
| 6 | a file in fossil repositories is the use of delta-compression, i.e. to |
| 7 | store only the changes between revisions instead of the whole |
| 8 | file.</p> |
| 9 | |
| 10 | <p>This document describes the format used to encode such changes, |
| 11 | also known as "delta". It is targeted at developers working on either |
| 12 | <a href="index.html">fossil</a> itself, or on tools compatible with |
| 13 | it.</p> |
| 14 | |
| 15 | <a name="structure"><h2>1.0 Structure</h2> |
| 16 | <img src="delta1.gif" align="left" hspace="10"> |
| 17 | |
| 18 | <p>A delta consists of three parts, a "header", a "trailer", and a |
| 19 | "segment-list" between them.</p> |
| 20 | |
| 21 | <p>Both header and trailer provide information about the target |
| 22 | helping the decoder, and the segment-list describes how the target can |
| 23 | be constructed from the original.</p> |
| 24 | |
| 25 | <a name="header"><h3>1.1 Header</h3> |
| 26 | <img src="delta6.gif" align="left" hspace="10"> |
| 27 | |
| 28 | <p>The header consists of a single number followed by a newline |
| 29 | character (ASCII 0x0a). The number is the length of the target in |
| 30 | bytes.</p> |
| @@ -32,11 +45,11 @@ | |
| 32 | <p>This means that, given a delta, the decoder can compute the size of |
| 33 | the target (and allocate any necessary memory based on that) by simply |
| 34 | reading the first line of the delta and decoding the number found |
| 35 | there. In other words, before it has to decode everything else.</p> |
| 36 | |
| 37 | <a name="trailer"><h3>1.2 Trailer</h3> |
| 38 | <img src="delta5.gif" align="left" hspace="10"> |
| 39 | |
| 40 | <p>The trailer consists of a single number followed by a semicolon (ASCII |
| 41 | 0x3b). This number is a checksum of the target and can be used by a |
| 42 | decoder to verify that the delta applied correctly, reconstructing the |
| @@ -49,11 +62,11 @@ | |
| 49 | |
| 50 | <p>By putting this information at the end of the delta a decoder has |
| 51 | it available immediately after the target has been reconstructed |
| 52 | fully.</p> |
| 53 | |
| 54 | <a name="slist"><h3>1.3 Segment-List</h3> |
| 55 | <img src="delta2.gif" align="left" hspace="10"> |
| 56 | |
| 57 | <p>The segment-list of a delta describes how to create the target from |
| 58 | the original by a combination of inserting literal byte-sequences and |
| 59 | copying ranges of bytes from the original. This is there the |
| @@ -62,20 +75,20 @@ | |
| 62 | |
| 63 | <p>The target is constructed from beginning to end, with the data |
| 64 | generated by each instruction appended after the data of all previous |
| 65 | instructions, with no gaps.</p> |
| 66 | |
| 67 | <a name="insertlit"><h4>1.3.1 Insert Literal</h4> |
| 68 | |
| 69 | <p>A literal is specified by two elements, the size of the literal in |
| 70 | bytes, and the bytes of the literal itself.</p> |
| 71 | |
| 72 | <img src="delta4.gif" align="left" hspace="10"> |
| 73 | <p>The length is written first, followed by a colon character (ASCII |
| 74 | 0x3a), followed by the bytes of the literal.</p> |
| 75 | |
| 76 | <a name="copyrange"><h4>1.3.2 Copy Range</h4> |
| 77 | |
| 78 | <p>A range to copy is specified by two numbers, the offset of the |
| 79 | first byte in the original to copy, and the size of the range, in |
| 80 | bytes. The size zero is special, its usage indicates that the range |
| 81 | extends to the end of the original.</p> |
| @@ -82,11 +95,11 @@ | |
| 82 | |
| 83 | <img src="delta3.gif" align="left" hspace="10"> |
| 84 | <p>The length is written first, followed by an "at" character (ASCII |
| 85 | 0x40), then the offset, followed by a comma (ASCII 0x2c).</p> |
| 86 | |
| 87 | <a name="intcoding"><h2>2.0 Encoding of integers</h2> |
| 88 | |
| 89 | <p> |
| 90 | The format currently handles only 32 bit integer numbers. They are |
| 91 | written base-64 encoded, MSB first, and without leading |
| 92 | "0"-characters, except if they are significant (i.e. 0 => "0"). |
| @@ -95,13 +108,13 @@ | |
| 95 | <p> |
| 96 | The base-64 coding is described in |
| 97 | <a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>. |
| 98 | </p> |
| 99 | |
| 100 | <a name="examples"><h2>3.0 Examples</h2> |
| 101 | |
| 102 | <a name="examplesint"><h3>3.1 Integer encoding</h3> |
| 103 | |
| 104 | <table border=1> |
| 105 | <tr> |
| 106 | <th>Value</th> |
| 107 | <th>Encoding</th> |
| @@ -118,11 +131,11 @@ | |
| 118 | <td>-1101438770</td> |
| 119 | <td>2zMM3E</td> |
| 120 | </tr> |
| 121 | </table> |
| 122 | |
| 123 | <a name="examplesdelta"><h3>3.2 Delta encoding</h3> |
| 124 | |
| 125 | <p>An example of a delta using the specified encoding is:</p> |
| 126 | |
| 127 | <table border=1><tr><td><pre> |
| 128 | 1Xb |
| @@ -194,20 +207,18 @@ | |
| 194 | |
| 195 | </pre></td></tr></table> |
| 196 | |
| 197 | |
| 198 | |
| 199 | <a name="notes"><h2>Notes</h2> |
| 200 | |
| 201 | <ul> |
| 202 | <li>Pure text files generate a pure text delta. |
| 203 | </li> |
| 204 | <li>Binary files generate a delta that may contain some binary data. |
| 205 | </li> |
| 206 | <li>Instead of putting special instructions for general compression |
| 207 | into the delta-format itself, specifically the segment-list, like |
| 208 | run-length encoding of literals, etc. it was considered to be much |
| 209 | more sensible to keep the various concern separate and use a general |
| 210 | compression library, like <a href="http://www.zlib.net">zlib</a>, to |
| 211 | compress the full delta after its generation. |
| 212 | </li> |
| 213 | </ul> |
| 214 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -1,30 +1,43 @@ | |
| 1 | <nowiki> |
| 2 | <h1 align="center"> |
| 3 | Fossil Delta Format |
| 4 | </h1> |
| 5 | |
| 6 | <p>Fossil achieves efficient storage and low-bandwidth synchronization |
| 7 | through the use of delta-compression. Instead of storing |
| 8 | or transmitting the complete content of an artifact, fossil stores or |
| 9 | transmits only the changes relative to a related artifact. |
| 10 | </p> |
| 11 | |
| 12 | <p>This document describes the delta-encoding format used by fossil. |
| 13 | The intended audience is developers working on either |
| 14 | <a href="index.wiki">fossil</a> itself, or on tools compatible with |
| 15 | fossil.</p> |
| 16 | |
| 17 | <p>Note that the delta-encoding is not a fundamental element of the |
| 18 | state of a fossil repository. A state of a fossil repository is |
| 19 | defined by the uncompressed and undeltaed content of all artifacts. |
| 20 | The fact the artifacts |
| 21 | are stored on disk using this delta-encoding format is merely an |
| 22 | optimization. One could, in theory, create an entirely new and |
| 23 | compatible implementation of fossil that used a different delta-encoding |
| 24 | or did no delta-encoding at all. However, experience has shown that |
| 25 | the delta-encoding described here is both efficient to compute and |
| 26 | results in very small deltas, so its continued use is recommended.</p> |
| 27 | |
| 28 | <a name="structure"></a><h2>1.0 Structure</h2> |
| 29 | <img src="delta1.gif" align="left" hspace="10"> |
| 30 | |
| 31 | <p>A delta consists of three parts, a "header", a "trailer", and a |
| 32 | "segment-list" between them.</p> |
| 33 | |
| 34 | <p>Both header and trailer provide information about the target |
| 35 | helping the decoder, and the segment-list describes how the target can |
| 36 | be constructed from the original.</p> |
| 37 | |
| 38 | <a name="header"></a><h3>1.1 Header</h3> |
| 39 | <img src="delta6.gif" align="left" hspace="10"> |
| 40 | |
| 41 | <p>The header consists of a single number followed by a newline |
| 42 | character (ASCII 0x0a). The number is the length of the target in |
| 43 | bytes.</p> |
| @@ -32,11 +45,11 @@ | |
| 45 | <p>This means that, given a delta, the decoder can compute the size of |
| 46 | the target (and allocate any necessary memory based on that) by simply |
| 47 | reading the first line of the delta and decoding the number found |
| 48 | there. In other words, before it has to decode everything else.</p> |
| 49 | |
| 50 | <a name="trailer"></a><h3>1.2 Trailer</h3> |
| 51 | <img src="delta5.gif" align="left" hspace="10"> |
| 52 | |
| 53 | <p>The trailer consists of a single number followed by a semicolon (ASCII |
| 54 | 0x3b). This number is a checksum of the target and can be used by a |
| 55 | decoder to verify that the delta applied correctly, reconstructing the |
| @@ -49,11 +62,11 @@ | |
| 62 | |
| 63 | <p>By putting this information at the end of the delta a decoder has |
| 64 | it available immediately after the target has been reconstructed |
| 65 | fully.</p> |
| 66 | |
| 67 | <a name="slist"></a><h3>1.3 Segment-List</h3> |
| 68 | <img src="delta2.gif" align="left" hspace="10"> |
| 69 | |
| 70 | <p>The segment-list of a delta describes how to create the target from |
| 71 | the original by a combination of inserting literal byte-sequences and |
| 72 | copying ranges of bytes from the original. This is there the |
| @@ -62,20 +75,20 @@ | |
| 75 | |
| 76 | <p>The target is constructed from beginning to end, with the data |
| 77 | generated by each instruction appended after the data of all previous |
| 78 | instructions, with no gaps.</p> |
| 79 | |
| 80 | <a name="insertlit"></a><h4>1.3.1 Insert Literal</h4> |
| 81 | |
| 82 | <p>A literal is specified by two elements, the size of the literal in |
| 83 | bytes, and the bytes of the literal itself.</p> |
| 84 | |
| 85 | <img src="delta4.gif" align="left" hspace="10"> |
| 86 | <p>The length is written first, followed by a colon character (ASCII |
| 87 | 0x3a), followed by the bytes of the literal.</p> |
| 88 | |
| 89 | <a name="copyrange"></a><h4>1.3.2 Copy Range</h4> |
| 90 | |
| 91 | <p>A range to copy is specified by two numbers, the offset of the |
| 92 | first byte in the original to copy, and the size of the range, in |
| 93 | bytes. The size zero is special, its usage indicates that the range |
| 94 | extends to the end of the original.</p> |
| @@ -82,11 +95,11 @@ | |
| 95 | |
| 96 | <img src="delta3.gif" align="left" hspace="10"> |
| 97 | <p>The length is written first, followed by an "at" character (ASCII |
| 98 | 0x40), then the offset, followed by a comma (ASCII 0x2c).</p> |
| 99 | |
| 100 | <a name="intcoding"></a><h2>2.0 Encoding of integers</h2> |
| 101 | |
| 102 | <p> |
| 103 | The format currently handles only 32 bit integer numbers. They are |
| 104 | written base-64 encoded, MSB first, and without leading |
| 105 | "0"-characters, except if they are significant (i.e. 0 => "0"). |
| @@ -95,13 +108,13 @@ | |
| 108 | <p> |
| 109 | The base-64 coding is described in |
| 110 | <a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>. |
| 111 | </p> |
| 112 | |
| 113 | <a name="examples"></a><h2>3.0 Examples</h2> |
| 114 | |
| 115 | <a name="examplesint"></a><h3>3.1 Integer encoding</h3> |
| 116 | |
| 117 | <table border=1> |
| 118 | <tr> |
| 119 | <th>Value</th> |
| 120 | <th>Encoding</th> |
| @@ -118,11 +131,11 @@ | |
| 131 | <td>-1101438770</td> |
| 132 | <td>2zMM3E</td> |
| 133 | </tr> |
| 134 | </table> |
| 135 | |
| 136 | <a name="examplesdelta"></a><h3>3.2 Delta encoding</h3> |
| 137 | |
| 138 | <p>An example of a delta using the specified encoding is:</p> |
| 139 | |
| 140 | <table border=1><tr><td><pre> |
| 141 | 1Xb |
| @@ -194,20 +207,18 @@ | |
| 207 | |
| 208 | </pre></td></tr></table> |
| 209 | |
| 210 | |
| 211 | |
| 212 | <a name="notes"></a><h2>Notes</h2> |
| 213 | |
| 214 | <ul> |
| 215 | <li>Pure text files generate a pure text delta. |
| 216 | </li> |
| 217 | <li>Binary files generate a delta that may contain some binary data. |
| 218 | </li> |
| 219 | <li>The delta encoding does not attempt to compress the content |
| 220 | It was considered to be much |
| 221 | more sensible to do compression using a separate general-purpose |
| 222 | compression library, like <a href="http://www.zlib.net">zlib</a>. |
| 223 | </li> |
| 224 | </ul> |
| 225 |
+1
-1
| --- www/pop.wiki | ||
| +++ www/pop.wiki | ||
| @@ -65,10 +65,10 @@ | ||
| 65 | 65 | <li><p>Every baseline has a special file at the top-level |
| 66 | 66 | named "manifest" which is an index of all other files in |
| 67 | 67 | that baseline. The manifest is automatically created and |
| 68 | 68 | maintained by the system.</p></li> |
| 69 | 69 | |
| 70 | -<li><p>The <a href="fileformat.html">file formats</a> | |
| 70 | +<li><p>The <a href="fileformat.wiki">file formats</a> | |
| 71 | 71 | used by Fossil are all very simple so that with access |
| 72 | 72 | to the original content files, one can easily reconstruct |
| 73 | 73 | the content of a baseline without the need for any |
| 74 | 74 | special tools or software.</p></li> |
| 75 | 75 |
| --- www/pop.wiki | |
| +++ www/pop.wiki | |
| @@ -65,10 +65,10 @@ | |
| 65 | <li><p>Every baseline has a special file at the top-level |
| 66 | named "manifest" which is an index of all other files in |
| 67 | that baseline. The manifest is automatically created and |
| 68 | maintained by the system.</p></li> |
| 69 | |
| 70 | <li><p>The <a href="fileformat.html">file formats</a> |
| 71 | used by Fossil are all very simple so that with access |
| 72 | to the original content files, one can easily reconstruct |
| 73 | the content of a baseline without the need for any |
| 74 | special tools or software.</p></li> |
| 75 |
| --- www/pop.wiki | |
| +++ www/pop.wiki | |
| @@ -65,10 +65,10 @@ | |
| 65 | <li><p>Every baseline has a special file at the top-level |
| 66 | named "manifest" which is an index of all other files in |
| 67 | that baseline. The manifest is automatically created and |
| 68 | maintained by the system.</p></li> |
| 69 | |
| 70 | <li><p>The <a href="fileformat.wiki">file formats</a> |
| 71 | used by Fossil are all very simple so that with access |
| 72 | to the original content files, one can easily reconstruct |
| 73 | the content of a baseline without the need for any |
| 74 | special tools or software.</p></li> |
| 75 |
+3
-2
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -1,14 +1,16 @@ | ||
| 1 | +<nowiki> | |
| 1 | 2 | <h1 align="center">Fossil Quick Start</h1> |
| 2 | 3 | |
| 3 | 4 | <p>This is a guide to get you started using fossil quickly |
| 4 | 5 | and painlessly.</p> |
| 5 | 6 | |
| 6 | 7 | <h2>Installing</h2><blockquote> |
| 7 | 8 | |
| 8 | 9 | <p>Fossil is a single self-contained C program. You need to |
| 9 | - either download a <a href="download.wiki">FIXME precompiled binary</a> | |
| 10 | + either download a | |
| 11 | + <a href="http://www.fossil-scm.org/download.html">precompiled binary</a> | |
| 10 | 12 | or <a href="build.wiki">build it yourself</a> from sources. |
| 11 | 13 | Install fossil by putting the fossil binary |
| 12 | 14 | someplace on your PATH environment variable.</p> |
| 13 | 15 | |
| 14 | 16 | </blockquote> |
| @@ -270,6 +272,5 @@ | ||
| 270 | 272 | |
| 271 | 273 | <p>Explore and have fun!</p> |
| 272 | 274 | |
| 273 | 275 | |
| 274 | 276 | </blockquote> |
| 275 | - | |
| 276 | 277 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -1,14 +1,16 @@ | |
| 1 | <h1 align="center">Fossil Quick Start</h1> |
| 2 | |
| 3 | <p>This is a guide to get you started using fossil quickly |
| 4 | and painlessly.</p> |
| 5 | |
| 6 | <h2>Installing</h2><blockquote> |
| 7 | |
| 8 | <p>Fossil is a single self-contained C program. You need to |
| 9 | either download a <a href="download.wiki">FIXME precompiled binary</a> |
| 10 | or <a href="build.wiki">build it yourself</a> from sources. |
| 11 | Install fossil by putting the fossil binary |
| 12 | someplace on your PATH environment variable.</p> |
| 13 | |
| 14 | </blockquote> |
| @@ -270,6 +272,5 @@ | |
| 270 | |
| 271 | <p>Explore and have fun!</p> |
| 272 | |
| 273 | |
| 274 | </blockquote> |
| 275 | |
| 276 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -1,14 +1,16 @@ | |
| 1 | <nowiki> |
| 2 | <h1 align="center">Fossil Quick Start</h1> |
| 3 | |
| 4 | <p>This is a guide to get you started using fossil quickly |
| 5 | and painlessly.</p> |
| 6 | |
| 7 | <h2>Installing</h2><blockquote> |
| 8 | |
| 9 | <p>Fossil is a single self-contained C program. You need to |
| 10 | either download a |
| 11 | <a href="http://www.fossil-scm.org/download.html">precompiled binary</a> |
| 12 | or <a href="build.wiki">build it yourself</a> from sources. |
| 13 | Install fossil by putting the fossil binary |
| 14 | someplace on your PATH environment variable.</p> |
| 15 | |
| 16 | </blockquote> |
| @@ -270,6 +272,5 @@ | |
| 272 | |
| 273 | <p>Explore and have fun!</p> |
| 274 | |
| 275 | |
| 276 | </blockquote> |
| 277 |
+4
-2
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -1,5 +1,6 @@ | ||
| 1 | +<nowiki> | |
| 1 | 2 | <h1 align="center"> |
| 2 | 3 | Fossil Repository Integrity Self-Checks |
| 3 | 4 | </h1> |
| 4 | 5 | |
| 5 | 6 | <p> |
| @@ -9,11 +10,12 @@ | ||
| 9 | 10 | lose your files. This note describes the defensive measures that |
| 10 | 11 | fossil uses to help prevent file loss due to bugs. |
| 11 | 12 | </p> |
| 12 | 13 | |
| 13 | 14 | <p><i>Follow-up as of 2007-11-24:</i> |
| 14 | -Fossil has been hosting itself and several other projects for | |
| 15 | +<i>Reiterated on 2008-05-16:</i> | |
| 16 | +Fossil has been hosting itself and many other projects for | |
| 15 | 17 | months now. Many bugs have been encountered. But, thanks in large |
| 16 | 18 | part to the defensive measures described here, no data has been |
| 17 | 19 | lost. The integrity checks are doing their job well.</p> |
| 18 | 20 | |
| 19 | 21 | <h2>Atomic Check-ins With Rollback</h2> |
| @@ -20,11 +22,11 @@ | ||
| 20 | 22 | |
| 21 | 23 | <p> |
| 22 | 24 | The fossil repository is an |
| 23 | 25 | <a href="http://www.sqlite.org/">SQLite version 3</a> database file. |
| 24 | 26 | SQLite is very mature and stable and has been in wide-spread use for many |
| 25 | -years, so we have little worries that it might cause repository | |
| 27 | +years, so we are confident it will not cause repository | |
| 26 | 28 | corruption. SQLite |
| 27 | 29 | databases do not corrupt even if a program or system crash or power |
| 28 | 30 | failure occurs in the middle of the update. If some kind of crash |
| 29 | 31 | does occur in the middle of a change, then all the changes are rolled |
| 30 | 32 | back the next time that the database is accessed. |
| 31 | 33 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -1,5 +1,6 @@ | |
| 1 | <h1 align="center"> |
| 2 | Fossil Repository Integrity Self-Checks |
| 3 | </h1> |
| 4 | |
| 5 | <p> |
| @@ -9,11 +10,12 @@ | |
| 9 | lose your files. This note describes the defensive measures that |
| 10 | fossil uses to help prevent file loss due to bugs. |
| 11 | </p> |
| 12 | |
| 13 | <p><i>Follow-up as of 2007-11-24:</i> |
| 14 | Fossil has been hosting itself and several other projects for |
| 15 | months now. Many bugs have been encountered. But, thanks in large |
| 16 | part to the defensive measures described here, no data has been |
| 17 | lost. The integrity checks are doing their job well.</p> |
| 18 | |
| 19 | <h2>Atomic Check-ins With Rollback</h2> |
| @@ -20,11 +22,11 @@ | |
| 20 | |
| 21 | <p> |
| 22 | The fossil repository is an |
| 23 | <a href="http://www.sqlite.org/">SQLite version 3</a> database file. |
| 24 | SQLite is very mature and stable and has been in wide-spread use for many |
| 25 | years, so we have little worries that it might cause repository |
| 26 | corruption. SQLite |
| 27 | databases do not corrupt even if a program or system crash or power |
| 28 | failure occurs in the middle of the update. If some kind of crash |
| 29 | does occur in the middle of a change, then all the changes are rolled |
| 30 | back the next time that the database is accessed. |
| 31 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -1,5 +1,6 @@ | |
| 1 | <nowiki> |
| 2 | <h1 align="center"> |
| 3 | Fossil Repository Integrity Self-Checks |
| 4 | </h1> |
| 5 | |
| 6 | <p> |
| @@ -9,11 +10,12 @@ | |
| 10 | lose your files. This note describes the defensive measures that |
| 11 | fossil uses to help prevent file loss due to bugs. |
| 12 | </p> |
| 13 | |
| 14 | <p><i>Follow-up as of 2007-11-24:</i> |
| 15 | <i>Reiterated on 2008-05-16:</i> |
| 16 | Fossil has been hosting itself and many other projects for |
| 17 | months now. Many bugs have been encountered. But, thanks in large |
| 18 | part to the defensive measures described here, no data has been |
| 19 | lost. The integrity checks are doing their job well.</p> |
| 20 | |
| 21 | <h2>Atomic Check-ins With Rollback</h2> |
| @@ -20,11 +22,11 @@ | |
| 22 | |
| 23 | <p> |
| 24 | The fossil repository is an |
| 25 | <a href="http://www.sqlite.org/">SQLite version 3</a> database file. |
| 26 | SQLite is very mature and stable and has been in wide-spread use for many |
| 27 | years, so we are confident it will not cause repository |
| 28 | corruption. SQLite |
| 29 | databases do not corrupt even if a program or system crash or power |
| 30 | failure occurs in the middle of the update. If some kind of crash |
| 31 | does occur in the middle of a change, then all the changes are rolled |
| 32 | back the next time that the database is accessed. |
| 33 |