Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Update the file format documentation. |
|---|---|
| Downloads: | Tarball | ZIP archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
c6646951861ae7324effa5c470261f25 |
| User & Date: | drh 2009-01-25 16:00:22.000 |
Context
|
2009-01-25
| ||
| 19:18 | Documentation tweaks. Change the "Setup" menu title to "Admin". Added pages under Admin to view the RCVFROM table of the database. check-in: 766bec08ce user: drh tags: trunk | |
| 16:00 | Update the file format documentation. check-in: c664695186 user: drh tags: trunk | |
|
2009-01-24
| ||
| 23:40 | correct 'branch' subcommand usage string check-in: 8b6cf431fb user: bch tags: trunk | |
Changes
Changes to www/fileformat.wiki.
| ︙ | ︙ | |||
49 50 51 52 53 54 55 | <li> Control Artifacts </li> <li> Wiki Pages </li> <li> Ticket Changes </li> </ul> <p>These five artifact types are described in the sequel.</p> | | | | 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 | <li> Control Artifacts </li> <li> Wiki Pages </li> <li> Ticket Changes </li> </ul> <p>These five artifact types are described in the sequel.</p> <p>In the current implementation (as of 2009-01-25) the artifacts that make up a fossil repository are stored in in as delta- and zlib-compressed blobs in an <a href="http://www.sqlite.org/">SQLite</a> database. This is an implementation detail and might change in a future release. For the purpose of this article "file format" means the format of the artifacts, not how the artifacts are stored on disk. It is the artifact format that is intended to be enduring. The specifics of how artifacts are stored on disk, though stable, is not intended to live as long as the artifact format.</p> <h2>1.0 The Manifest</h2> <p>A manifest defines a check-in or version of the project source tree. The manifest contains a list of artifacts for each file in the project and the corresponding filenames, as |
| ︙ | ︙ | |||
105 106 107 108 109 110 111 112 113 114 115 116 117 118 | <blockquote> <b>C</b> <i>checkin-comment</i><br> <b>D</b> <i>time-and-date-stamp</i><br> <b>F</b> <i>filename</i> <i>SHA1-hash</i> <i>permissions</i> <i>old-name</i><br> <b>P</b> <i>SHA1-hash</i>+<br> <b>R</b> <i>repository-checksum</i><br> <b>U</b> <i>user-login</i><br> <b>Z</b> <i>manifest-checksum</i> </blockquote> <p> A manifest must have exactly one C-card. The sole argument to the C-card is a check-in comment that describes the check-in that | > | 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 | <blockquote> <b>C</b> <i>checkin-comment</i><br> <b>D</b> <i>time-and-date-stamp</i><br> <b>F</b> <i>filename</i> <i>SHA1-hash</i> <i>permissions</i> <i>old-name</i><br> <b>P</b> <i>SHA1-hash</i>+<br> <b>R</b> <i>repository-checksum</i><br> <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name <b>*</b> ?value?</i><br> <b>U</b> <i>user-login</i><br> <b>Z</b> <i>manifest-checksum</i> </blockquote> <p> A manifest must have exactly one C-card. The sole argument to the C-card is a check-in comment that describes the check-in that |
| ︙ | ︙ | |||
190 191 192 193 194 195 196 197 198 199 200 201 202 203 | take the pathname of the file relative to the root of the repository, append a single space (ASCII 0x20), the size of the file in ASCII decimal, a single newline character (ASCII 0x0A), and the complete text of the file. Compute the MD5 checksum of the the result. </p> <p> Each manifest has a single U-card. The argument to the U-card is the login of the user who created the manifest. The login name is encoded using the same character escapes as is used for the check-in comment argument to the C-card. </p> | > > > > > > > > > > > > > > | 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 | take the pathname of the file relative to the root of the repository, append a single space (ASCII 0x20), the size of the file in ASCII decimal, a single newline character (ASCII 0x0A), and the complete text of the file. Compute the MD5 checksum of the the result. </p> <p> A manifest might contain one or more T-cards used to set tags or properties on the check-in. The format of the T-card is the same as described in <i>Control Artifacts</i> section below, except that the second argument is the single characcter "<b>*</b>" instead of an artifact ID. The <b>*</b> in place of the artifact ID indicates that the tag or property applies to the current artifact. It is not possible to encode the current artifact ID as part of an artifact, since the act of inserting the artifact ID would change the artifact ID, hence a <b>*</b> is used to represent "self". T-cards are typically added to manifests in order to set the <b>branch</b> property and a symbolic name when the check-in is intended to start a new branch. </p> <p> Each manifest has a single U-card. The argument to the U-card is the login of the user who created the manifest. The login name is encoded using the same character escapes as is used for the check-in comment argument to the C-card. </p> |
| ︙ | ︙ |