@@ -1,19 +1,32 @@
+<nowiki>
<h1 align="center">
Fossil Delta Format
</h1>
-<p>A key component for the efficient storage of multiple revisions of
-a file in fossil repositories is the use of delta-compression, i.e. to
-store only the changes between revisions instead of the whole
-file.</p>
-
-<p>This document describes the format used to encode such changes,
-also known as "delta". It is targeted at developers working on either
-<a href="index.html">fossil</a> itself, or on tools compatible with
-it.</p>
-
-<a name="structure"><h2>1.0 Structure</h2>
+<p>Fossil achieves efficient storage and low-bandwidth synchronization
+through the use of delta-compression. Instead of storing
+or transmitting the complete content of an artifact, fossil stores or
+transmits only the changes relative to a related artifact.
+</p>
+
+<p>This document describes the delta-encoding format used by fossil.
+The intended audience is developers working on either
+<a href="index.wiki">fossil</a> itself, or on tools compatible with
+fossil.</p>
+
+<p>Note that the delta-encoding is not a fundamental element of the
+state of a fossil repository. A state of a fossil repository is
+defined by the uncompressed and undeltaed content of all artifacts.
+The fact the artifacts
+are stored on disk using this delta-encoding format is merely an
+optimization. One could, in theory, create an entirely new and
+compatible implementation of fossil that used a different delta-encoding
+or did no delta-encoding at all. However, experience has shown that
+the delta-encoding described here is both efficient to compute and
+results in very small deltas, so its continued use is recommended.</p>
+
+<a name="structure"></a><h2>1.0 Structure</h2>
<img src="delta1.gif" align="left" hspace="10">
<p>A delta consists of three parts, a "header", a "trailer", and a
"segment-list" between them.</p>
@@ -21,9 +34,9 @@
<p>Both header and trailer provide information about the target
helping the decoder, and the segment-list describes how the target can
be constructed from the original.</p>
-<a name="header"><h3>1.1 Header</h3>
+<a name="header"></a><h3>1.1 Header</h3>
<img src="delta6.gif" align="left" hspace="10">
<p>The header consists of a single number followed by a newline
character (ASCII 0x0a). The number is the length of the target in
@@ -33,9 +46,9 @@
the target (and allocate any necessary memory based on that) by simply
reading the first line of the delta and decoding the number found
there. In other words, before it has to decode everything else.</p>
-<a name="trailer"><h3>1.2 Trailer</h3>
+<a name="trailer"></a><h3>1.2 Trailer</h3>
<img src="delta5.gif" align="left" hspace="10">
<p>The trailer consists of a single number followed by a semicolon (ASCII
0x3b). This number is a checksum of the target and can be used by a
@@ -50,9 +63,9 @@
<p>By putting this information at the end of the delta a decoder has
it available immediately after the target has been reconstructed
fully.</p>
-<a name="slist"><h3>1.3 Segment-List</h3>
+<a name="slist"></a><h3>1.3 Segment-List</h3>
<img src="delta2.gif" align="left" hspace="10">
<p>The segment-list of a delta describes how to create the target from
the original by a combination of inserting literal byte-sequences and
@@ -63,9 +76,9 @@
<p>The target is constructed from beginning to end, with the data
generated by each instruction appended after the data of all previous
instructions, with no gaps.</p>
-<a name="insertlit"><h4>1.3.1 Insert Literal</h4>
+<a name="insertlit"></a><h4>1.3.1 Insert Literal</h4>
<p>A literal is specified by two elements, the size of the literal in
bytes, and the bytes of the literal itself.</p>
@@ -72,9 +85,9 @@
<img src="delta4.gif" align="left" hspace="10">
<p>The length is written first, followed by a colon character (ASCII
0x3a), followed by the bytes of the literal.</p>
-<a name="copyrange"><h4>1.3.2 Copy Range</h4>
+<a name="copyrange"></a><h4>1.3.2 Copy Range</h4>
<p>A range to copy is specified by two numbers, the offset of the
first byte in the original to copy, and the size of the range, in
bytes. The size zero is special, its usage indicates that the range
@@ -83,9 +96,9 @@
<img src="delta3.gif" align="left" hspace="10">
<p>The length is written first, followed by an "at" character (ASCII
0x40), then the offset, followed by a comma (ASCII 0x2c).</p>
-<a name="intcoding"><h2>2.0 Encoding of integers</h2>
+<a name="intcoding"></a><h2>2.0 Encoding of integers</h2>
<p>
The format currently handles only 32 bit integer numbers. They are
written base-64 encoded, MSB first, and without leading
@@ -96,11 +109,11 @@
The base-64 coding is described in
<a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>.
</p>
-<a name="examples"><h2>3.0 Examples</h2>
-
-<a name="examplesint"><h3>3.1 Integer encoding</h3>
+<a name="examples"></a><h2>3.0 Examples</h2>
+
+<a name="examplesint"></a><h3>3.1 Integer encoding</h3>
<table border=1>
<tr>
<th>Value</th>
@@ -119,9 +132,9 @@
<td>2zMM3E</td>
</tr>
</table>
-<a name="examplesdelta"><h3>3.2 Delta encoding</h3>
+<a name="examplesdelta"></a><h3>3.2 Delta encoding</h3>
<p>An example of a delta using the specified encoding is:</p>
<table border=1><tr><td><pre>
@@ -195,19 +208,17 @@
</pre></td></tr></table>
-<a name="notes"><h2>Notes</h2>
+<a name="notes"></a><h2>Notes</h2>
<ul>
<li>Pure text files generate a pure text delta.
</li>
<li>Binary files generate a delta that may contain some binary data.
</li>
-<li>Instead of putting special instructions for general compression
-into the delta-format itself, specifically the segment-list, like
-run-length encoding of literals, etc. it was considered to be much
-more sensible to keep the various concern separate and use a general
-compression library, like <a href="http://www.zlib.net">zlib</a>, to
-compress the full delta after its generation.
+<li>The delta encoding does not attempt to compress the content
+It was considered to be much
+more sensible to do compression using a separate general-purpose
+compression library, like <a href="http://www.zlib.net">zlib</a>.
</li>
</ul>