Fossil SCM
Typo fix. Removed a block of commented-out pikchr.
Commit
269788ebdbbb64b339829491a219b3074248432a58ea0dab2b28fef7cbc2f94d
Parent
c17054a5df90f11…
1 file changed
+2
-22
+2
-22
| --- www/fossil-is-not-relational.md | ||
| +++ www/fossil-is-not-relational.md | ||
| @@ -3,11 +3,11 @@ | ||
| 3 | 3 | ***An Introduction to the Fossil Data Model*** |
| 4 | 4 | |
| 5 | 5 | Upon hearing that Fossil is based on sqlite, it's natural for people |
| 6 | 6 | unfamiliar with its internals to assume that Fossil stores its |
| 7 | 7 | SCM-relevant data in a database-friendly way and that the SCM history |
| 8 | -could be modified via SQL. The truth, however, is *far stranger than | |
| 8 | +can be modified via SQL. The truth, however, is *far stranger than | |
| 9 | 9 | that.* |
| 10 | 10 | |
| 11 | 11 | This presentation introduces, at a relatively high level: |
| 12 | 12 | |
| 13 | 13 | 1) The underlying enduring and immutable data format, which is |
| @@ -19,31 +19,10 @@ | ||
| 19 | 19 | 3) The transformation of (1) from its immutable raw form to a |
| 20 | 20 | *transient* database-friendly form. |
| 21 | 21 | |
| 22 | 22 | 4) Some of the consequences of this model. |
| 23 | 23 | |
| 24 | -<!-- | |
| 25 | -```pikchr center | |
| 26 | -AllObjects: [ | |
| 27 | -A: file "Artifacts"; | |
| 28 | -down; move to A.s; move 50%; | |
| 29 | -F: file "Client" "files"; | |
| 30 | -right; move 1; up; move 50%; | |
| 31 | -B: cylinder "blob table" | |
| 32 | -right; | |
| 33 | -arrow from A.e to B.w; | |
| 34 | -arrow from F.e to B.w; | |
| 35 | -arrow from B.e; | |
| 36 | -C: box rad 0.1 "Crosslink" "process"; | |
| 37 | -arrow | |
| 38 | -AUX: cylinder "Auxiliary" "tables" | |
| 39 | -arc -> cw dotted from AUX.s to B.s; | |
| 40 | -] # end of AllObjects | |
| 41 | -// text "Architecture Overview" big bold at .1cm above north of AllObjects | |
| 42 | -``` | |
| ---> | ||
| 43 | - | |
| 44 | 24 | |
| 45 | 25 | # Part 1: Artifacts |
| 46 | 26 | |
| 47 | 27 | ```pikchr center |
| 48 | 28 | AllObjects: [ |
| @@ -98,11 +77,11 @@ | ||
| 98 | 77 | makes no attempt at providing a generic format. It contains *only* |
| 99 | 78 | what it *needs* to function, with zero bloat. |
| 100 | 79 | |
| 101 | 80 | - It <u>**holds all SCM-relevant data except for client-level file |
| 102 | 81 | content**</u>, the latter instead being referenced by their unique |
| 103 | - hash values. Storage of the client-side content as an implementation | |
| 82 | + hash values. Storage of the client-side content is an implementation | |
| 104 | 83 | detail delegated to higher-level applications. |
| 105 | 84 | |
| 106 | 85 | - <u>**Auditability**</u>. By following the hash references in |
| 107 | 86 | artifacts it is possible to unambiguously trace the origin of any |
| 108 | 87 | modification to the SCM state. Combined with higher-level tools |
| 109 | 88 |
| --- www/fossil-is-not-relational.md | |
| +++ www/fossil-is-not-relational.md | |
| @@ -3,11 +3,11 @@ | |
| 3 | ***An Introduction to the Fossil Data Model*** |
| 4 | |
| 5 | Upon hearing that Fossil is based on sqlite, it's natural for people |
| 6 | unfamiliar with its internals to assume that Fossil stores its |
| 7 | SCM-relevant data in a database-friendly way and that the SCM history |
| 8 | could be modified via SQL. The truth, however, is *far stranger than |
| 9 | that.* |
| 10 | |
| 11 | This presentation introduces, at a relatively high level: |
| 12 | |
| 13 | 1) The underlying enduring and immutable data format, which is |
| @@ -19,31 +19,10 @@ | |
| 19 | 3) The transformation of (1) from its immutable raw form to a |
| 20 | *transient* database-friendly form. |
| 21 | |
| 22 | 4) Some of the consequences of this model. |
| 23 | |
| 24 | <!-- |
| 25 | ```pikchr center |
| 26 | AllObjects: [ |
| 27 | A: file "Artifacts"; |
| 28 | down; move to A.s; move 50%; |
| 29 | F: file "Client" "files"; |
| 30 | right; move 1; up; move 50%; |
| 31 | B: cylinder "blob table" |
| 32 | right; |
| 33 | arrow from A.e to B.w; |
| 34 | arrow from F.e to B.w; |
| 35 | arrow from B.e; |
| 36 | C: box rad 0.1 "Crosslink" "process"; |
| 37 | arrow |
| 38 | AUX: cylinder "Auxiliary" "tables" |
| 39 | arc -> cw dotted from AUX.s to B.s; |
| 40 | ] # end of AllObjects |
| 41 | // text "Architecture Overview" big bold at .1cm above north of AllObjects |
| 42 | ``` |
| ---> | |
| 43 | |
| 44 | |
| 45 | # Part 1: Artifacts |
| 46 | |
| 47 | ```pikchr center |
| 48 | AllObjects: [ |
| @@ -98,11 +77,11 @@ | |
| 98 | makes no attempt at providing a generic format. It contains *only* |
| 99 | what it *needs* to function, with zero bloat. |
| 100 | |
| 101 | - It <u>**holds all SCM-relevant data except for client-level file |
| 102 | content**</u>, the latter instead being referenced by their unique |
| 103 | hash values. Storage of the client-side content as an implementation |
| 104 | detail delegated to higher-level applications. |
| 105 | |
| 106 | - <u>**Auditability**</u>. By following the hash references in |
| 107 | artifacts it is possible to unambiguously trace the origin of any |
| 108 | modification to the SCM state. Combined with higher-level tools |
| 109 |
| --- www/fossil-is-not-relational.md | |
| +++ www/fossil-is-not-relational.md | |
| @@ -3,11 +3,11 @@ | |
| 3 | ***An Introduction to the Fossil Data Model*** |
| 4 | |
| 5 | Upon hearing that Fossil is based on sqlite, it's natural for people |
| 6 | unfamiliar with its internals to assume that Fossil stores its |
| 7 | SCM-relevant data in a database-friendly way and that the SCM history |
| 8 | can be modified via SQL. The truth, however, is *far stranger than |
| 9 | that.* |
| 10 | |
| 11 | This presentation introduces, at a relatively high level: |
| 12 | |
| 13 | 1) The underlying enduring and immutable data format, which is |
| @@ -19,31 +19,10 @@ | |
| 19 | 3) The transformation of (1) from its immutable raw form to a |
| 20 | *transient* database-friendly form. |
| 21 | |
| 22 | 4) Some of the consequences of this model. |
| 23 | |
| ---> | |
| 24 | |
| 25 | # Part 1: Artifacts |
| 26 | |
| 27 | ```pikchr center |
| 28 | AllObjects: [ |
| @@ -98,11 +77,11 @@ | |
| 77 | makes no attempt at providing a generic format. It contains *only* |
| 78 | what it *needs* to function, with zero bloat. |
| 79 | |
| 80 | - It <u>**holds all SCM-relevant data except for client-level file |
| 81 | content**</u>, the latter instead being referenced by their unique |
| 82 | hash values. Storage of the client-side content is an implementation |
| 83 | detail delegated to higher-level applications. |
| 84 | |
| 85 | - <u>**Auditability**</u>. By following the hash references in |
| 86 | artifacts it is possible to unambiguously trace the origin of any |
| 87 | modification to the SCM state. Combined with higher-level tools |
| 88 |