Fossil SCM
Update the file format documentation.
Commit
c6646951861ae7324effa5c470261f255fdd0d4f
Parent
8b6cf431fb80c45…
1 file changed
+17
-2
+17
-2
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -51,18 +51,18 @@ | ||
| 51 | 51 | <li> Ticket Changes </li> |
| 52 | 52 | </ul> |
| 53 | 53 | |
| 54 | 54 | <p>These five artifact types are described in the sequel.</p> |
| 55 | 55 | |
| 56 | -<p>In the current implementation (as of 2008-10-04) the artifacts that | |
| 56 | +<p>In the current implementation (as of 2009-01-25) the artifacts that | |
| 57 | 57 | make up a fossil repository are stored in in as delta- and zlib-compressed |
| 58 | 58 | blobs in an <a href="http://www.sqlite.org/">SQLite</a> database. This |
| 59 | 59 | is an implementation detail and might change in a future release. For |
| 60 | 60 | the purpose of this article "file format" means the format of the artifacts, |
| 61 | 61 | not how the artifacts are stored on disk. It is the artifact format that |
| 62 | 62 | is intended to be enduring. The specifics of how artifacts are stored on |
| 63 | -disk, though stable, is not intended to have as long a lifespan as the | |
| 63 | +disk, though stable, is not intended to live as long as the | |
| 64 | 64 | artifact format.</p> |
| 65 | 65 | |
| 66 | 66 | <h2>1.0 The Manifest</h2> |
| 67 | 67 | |
| 68 | 68 | <p>A manifest defines a check-in or version of the project |
| @@ -107,10 +107,11 @@ | ||
| 107 | 107 | <b>C</b> <i>checkin-comment</i><br> |
| 108 | 108 | <b>D</b> <i>time-and-date-stamp</i><br> |
| 109 | 109 | <b>F</b> <i>filename</i> <i>SHA1-hash</i> <i>permissions</i> <i>old-name</i><br> |
| 110 | 110 | <b>P</b> <i>SHA1-hash</i>+<br> |
| 111 | 111 | <b>R</b> <i>repository-checksum</i><br> |
| 112 | +<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name <b>*</b> ?value?</i><br> | |
| 112 | 113 | <b>U</b> <i>user-login</i><br> |
| 113 | 114 | <b>Z</b> <i>manifest-checksum</i> |
| 114 | 115 | </blockquote> |
| 115 | 116 | |
| 116 | 117 | <p> |
| @@ -192,10 +193,24 @@ | ||
| 192 | 193 | size of the file in ASCII decimal, a single newline |
| 193 | 194 | character (ASCII 0x0A), and the complete text of the file. |
| 194 | 195 | Compute the MD5 checksum of the the result. |
| 195 | 196 | </p> |
| 196 | 197 | |
| 198 | +<p> | |
| 199 | +A manifest might contain one or more T-cards used to set tags or | |
| 200 | +properties on the check-in. The format of the T-card is the same as | |
| 201 | +described in <i>Control Artifacts</i> section below, except that the | |
| 202 | +second argument is the single characcter "<b>*</b>" instead of an | |
| 203 | +artifact ID. The <b>*</b> in place of the artifact ID indicates that | |
| 204 | +the tag or property applies to the current artifact. It is not | |
| 205 | +possible to encode the current artifact ID as part of an artifact, | |
| 206 | +since the act of inserting the artifact ID would change the artifact ID, | |
| 207 | +hence a <b>*</b> is used to represent "self". T-cards are typically | |
| 208 | +added to manifests in order to set the <b>branch</b> property and a | |
| 209 | +symbolic name when the check-in is intended to start a new branch. | |
| 210 | +</p> | |
| 211 | + | |
| 197 | 212 | <p> |
| 198 | 213 | Each manifest has a single U-card. The argument to the U-card is |
| 199 | 214 | the login of the user who created the manifest. The login name |
| 200 | 215 | is encoded using the same character escapes as is used for the |
| 201 | 216 | check-in comment argument to the C-card. |
| 202 | 217 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -51,18 +51,18 @@ | |
| 51 | <li> Ticket Changes </li> |
| 52 | </ul> |
| 53 | |
| 54 | <p>These five artifact types are described in the sequel.</p> |
| 55 | |
| 56 | <p>In the current implementation (as of 2008-10-04) the artifacts that |
| 57 | make up a fossil repository are stored in in as delta- and zlib-compressed |
| 58 | blobs in an <a href="http://www.sqlite.org/">SQLite</a> database. This |
| 59 | is an implementation detail and might change in a future release. For |
| 60 | the purpose of this article "file format" means the format of the artifacts, |
| 61 | not how the artifacts are stored on disk. It is the artifact format that |
| 62 | is intended to be enduring. The specifics of how artifacts are stored on |
| 63 | disk, though stable, is not intended to have as long a lifespan as the |
| 64 | artifact format.</p> |
| 65 | |
| 66 | <h2>1.0 The Manifest</h2> |
| 67 | |
| 68 | <p>A manifest defines a check-in or version of the project |
| @@ -107,10 +107,11 @@ | |
| 107 | <b>C</b> <i>checkin-comment</i><br> |
| 108 | <b>D</b> <i>time-and-date-stamp</i><br> |
| 109 | <b>F</b> <i>filename</i> <i>SHA1-hash</i> <i>permissions</i> <i>old-name</i><br> |
| 110 | <b>P</b> <i>SHA1-hash</i>+<br> |
| 111 | <b>R</b> <i>repository-checksum</i><br> |
| 112 | <b>U</b> <i>user-login</i><br> |
| 113 | <b>Z</b> <i>manifest-checksum</i> |
| 114 | </blockquote> |
| 115 | |
| 116 | <p> |
| @@ -192,10 +193,24 @@ | |
| 192 | size of the file in ASCII decimal, a single newline |
| 193 | character (ASCII 0x0A), and the complete text of the file. |
| 194 | Compute the MD5 checksum of the the result. |
| 195 | </p> |
| 196 | |
| 197 | <p> |
| 198 | Each manifest has a single U-card. The argument to the U-card is |
| 199 | the login of the user who created the manifest. The login name |
| 200 | is encoded using the same character escapes as is used for the |
| 201 | check-in comment argument to the C-card. |
| 202 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -51,18 +51,18 @@ | |
| 51 | <li> Ticket Changes </li> |
| 52 | </ul> |
| 53 | |
| 54 | <p>These five artifact types are described in the sequel.</p> |
| 55 | |
| 56 | <p>In the current implementation (as of 2009-01-25) the artifacts that |
| 57 | make up a fossil repository are stored in in as delta- and zlib-compressed |
| 58 | blobs in an <a href="http://www.sqlite.org/">SQLite</a> database. This |
| 59 | is an implementation detail and might change in a future release. For |
| 60 | the purpose of this article "file format" means the format of the artifacts, |
| 61 | not how the artifacts are stored on disk. It is the artifact format that |
| 62 | is intended to be enduring. The specifics of how artifacts are stored on |
| 63 | disk, though stable, is not intended to live as long as the |
| 64 | artifact format.</p> |
| 65 | |
| 66 | <h2>1.0 The Manifest</h2> |
| 67 | |
| 68 | <p>A manifest defines a check-in or version of the project |
| @@ -107,10 +107,11 @@ | |
| 107 | <b>C</b> <i>checkin-comment</i><br> |
| 108 | <b>D</b> <i>time-and-date-stamp</i><br> |
| 109 | <b>F</b> <i>filename</i> <i>SHA1-hash</i> <i>permissions</i> <i>old-name</i><br> |
| 110 | <b>P</b> <i>SHA1-hash</i>+<br> |
| 111 | <b>R</b> <i>repository-checksum</i><br> |
| 112 | <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name <b>*</b> ?value?</i><br> |
| 113 | <b>U</b> <i>user-login</i><br> |
| 114 | <b>Z</b> <i>manifest-checksum</i> |
| 115 | </blockquote> |
| 116 | |
| 117 | <p> |
| @@ -192,10 +193,24 @@ | |
| 193 | size of the file in ASCII decimal, a single newline |
| 194 | character (ASCII 0x0A), and the complete text of the file. |
| 195 | Compute the MD5 checksum of the the result. |
| 196 | </p> |
| 197 | |
| 198 | <p> |
| 199 | A manifest might contain one or more T-cards used to set tags or |
| 200 | properties on the check-in. The format of the T-card is the same as |
| 201 | described in <i>Control Artifacts</i> section below, except that the |
| 202 | second argument is the single characcter "<b>*</b>" instead of an |
| 203 | artifact ID. The <b>*</b> in place of the artifact ID indicates that |
| 204 | the tag or property applies to the current artifact. It is not |
| 205 | possible to encode the current artifact ID as part of an artifact, |
| 206 | since the act of inserting the artifact ID would change the artifact ID, |
| 207 | hence a <b>*</b> is used to represent "self". T-cards are typically |
| 208 | added to manifests in order to set the <b>branch</b> property and a |
| 209 | symbolic name when the check-in is intended to start a new branch. |
| 210 | </p> |
| 211 | |
| 212 | <p> |
| 213 | Each manifest has a single U-card. The argument to the U-card is |
| 214 | the login of the user who created the manifest. The login name |
| 215 | is encoded using the same character escapes as is used for the |
| 216 | check-in comment argument to the C-card. |
| 217 |