Fossil SCM
Minor pedantic doc touchups [https://claude.ai/code/artifact/c121be7a-5c6a-4a18-ab7f-63d086ac8071|suggested by an LLM] focused on RFCing the fossil artifact format.
Commit
f44ad30da14633f9bfd82ea207c3dab625f3bc3915722484e8781a84fcd21d00
Parent
7a131cfa173b0a1…
2 files changed
+9
+2
-1
+9
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -171,10 +171,19 @@ | ||
| 171 | 171 | is optional. The file format might be extended with new permission |
| 172 | 172 | letters in the future. The optional 4th argument is the name of the |
| 173 | 173 | same file as it existed in the parent check-in. If the name of the |
| 174 | 174 | file is unchanged from its parent, then the 4th argument is omitted. |
| 175 | 175 | |
| 176 | +Sidebar: due to a minor bug in Fossil's early history (specifically | |
| 177 | +2008-08-11 to 2009-01-20), manifest parsers must be able to tolerate a | |
| 178 | +single space character after the UUID value even if no permissions | |
| 179 | +value is set. Normally the space would indicate that another token | |
| 180 | +is expected, but this one case requires leniency to allow | |
| 181 | +[/artifact/32b480faa3465591|a single known historical artifact] to parse. | |
| 182 | +For full details see | |
| 183 | +[https://claude.ai/code/artifact/c121be7a-5c6a-4a18-ab7f-63d086ac8071|this article]. | |
| 184 | + | |
| 176 | 185 | A manifest has zero or one <b>N</b> cards. The <b>N</b> card specifies the mimetype for the |
| 177 | 186 | text in the comment of the <b>C</b> card. If the <b>N</b> card is omitted, a default mimetype |
| 178 | 187 | is used. Note that the <b>N</b> card has never actually been used by |
| 179 | 188 | any Fossil implementation. The implementation has always interpreted |
| 180 | 189 | check-in comments according to the [/wiki_rules|Fossil Wiki formatting rules]. |
| 181 | 190 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -171,10 +171,19 @@ | |
| 171 | is optional. The file format might be extended with new permission |
| 172 | letters in the future. The optional 4th argument is the name of the |
| 173 | same file as it existed in the parent check-in. If the name of the |
| 174 | file is unchanged from its parent, then the 4th argument is omitted. |
| 175 | |
| 176 | A manifest has zero or one <b>N</b> cards. The <b>N</b> card specifies the mimetype for the |
| 177 | text in the comment of the <b>C</b> card. If the <b>N</b> card is omitted, a default mimetype |
| 178 | is used. Note that the <b>N</b> card has never actually been used by |
| 179 | any Fossil implementation. The implementation has always interpreted |
| 180 | check-in comments according to the [/wiki_rules|Fossil Wiki formatting rules]. |
| 181 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -171,10 +171,19 @@ | |
| 171 | is optional. The file format might be extended with new permission |
| 172 | letters in the future. The optional 4th argument is the name of the |
| 173 | same file as it existed in the parent check-in. If the name of the |
| 174 | file is unchanged from its parent, then the 4th argument is omitted. |
| 175 | |
| 176 | Sidebar: due to a minor bug in Fossil's early history (specifically |
| 177 | 2008-08-11 to 2009-01-20), manifest parsers must be able to tolerate a |
| 178 | single space character after the UUID value even if no permissions |
| 179 | value is set. Normally the space would indicate that another token |
| 180 | is expected, but this one case requires leniency to allow |
| 181 | [/artifact/32b480faa3465591|a single known historical artifact] to parse. |
| 182 | For full details see |
| 183 | [https://claude.ai/code/artifact/c121be7a-5c6a-4a18-ab7f-63d086ac8071|this article]. |
| 184 | |
| 185 | A manifest has zero or one <b>N</b> cards. The <b>N</b> card specifies the mimetype for the |
| 186 | text in the comment of the <b>C</b> card. If the <b>N</b> card is omitted, a default mimetype |
| 187 | is used. Note that the <b>N</b> card has never actually been used by |
| 188 | any Fossil implementation. The implementation has always interpreted |
| 189 | check-in comments according to the [/wiki_rules|Fossil Wiki formatting rules]. |
| 190 |
+2
-1
| --- www/fossil-is-not-relational.md | ||
| +++ www/fossil-is-not-relational.md | ||
| @@ -275,11 +275,12 @@ | ||
| 275 | 275 | (checkin, wiki, tag, etc.). However, given that all of those |
| 276 | 276 | relationships, including the timeline, are *transient*, how can Fossil |
| 277 | 277 | distinguish between the two types of data? |
| 278 | 278 | |
| 279 | 279 | Fossil's artifact format is extremely rigid and is *strictly* enforced |
| 280 | -internally, with zero room provided for leniency. Every artifact which | |
| 280 | +internally, with very near zero room provided for leniency (barring a | |
| 281 | +small handful of historical compatibility cases). Every artifact which | |
| 281 | 282 | is internally created is re-parsed for validity before it is committed |
| 282 | 283 | to the database, making it impossible that Fossil can inject an |
| 283 | 284 | invalid artifact into the repository. Because of the strictness of the |
| 284 | 285 | artifact parser, the chances that any given piece of arbitrary client |
| 285 | 286 | data could be successfully parsed as an artifact, even if it is |
| 286 | 287 |
| --- www/fossil-is-not-relational.md | |
| +++ www/fossil-is-not-relational.md | |
| @@ -275,11 +275,12 @@ | |
| 275 | (checkin, wiki, tag, etc.). However, given that all of those |
| 276 | relationships, including the timeline, are *transient*, how can Fossil |
| 277 | distinguish between the two types of data? |
| 278 | |
| 279 | Fossil's artifact format is extremely rigid and is *strictly* enforced |
| 280 | internally, with zero room provided for leniency. Every artifact which |
| 281 | is internally created is re-parsed for validity before it is committed |
| 282 | to the database, making it impossible that Fossil can inject an |
| 283 | invalid artifact into the repository. Because of the strictness of the |
| 284 | artifact parser, the chances that any given piece of arbitrary client |
| 285 | data could be successfully parsed as an artifact, even if it is |
| 286 |
| --- www/fossil-is-not-relational.md | |
| +++ www/fossil-is-not-relational.md | |
| @@ -275,11 +275,12 @@ | |
| 275 | (checkin, wiki, tag, etc.). However, given that all of those |
| 276 | relationships, including the timeline, are *transient*, how can Fossil |
| 277 | distinguish between the two types of data? |
| 278 | |
| 279 | Fossil's artifact format is extremely rigid and is *strictly* enforced |
| 280 | internally, with very near zero room provided for leniency (barring a |
| 281 | small handful of historical compatibility cases). Every artifact which |
| 282 | is internally created is re-parsed for validity before it is committed |
| 283 | to the database, making it impossible that Fossil can inject an |
| 284 | invalid artifact into the repository. Because of the strictness of the |
| 285 | artifact parser, the chances that any given piece of arbitrary client |
| 286 | data could be successfully parsed as an artifact, even if it is |
| 287 |