Fossil SCM
(Grammar) theory1.wiki changes.
Commit
e2c79bb90e2f5333ef7e595f0a79098a31b6a5a5b80816b3373b4afb1b62ade4
Parent
aa1ea7091c652c3…
1 file changed
+2
-2
+2
-2
| --- www/theory1.wiki | ||
| +++ www/theory1.wiki | ||
| @@ -73,14 +73,14 @@ | ||
| 73 | 73 | implementation detail which currently happens to use SQLite. |
| 74 | 74 | |
| 75 | 75 | Another way to think of the relational tables in a Fossil repository is |
| 76 | 76 | as an index for the artifacts. Without the relational tables, |
| 77 | 77 | to generate a report like a timeline would require scanning every artifact - |
| 78 | -the equivalent of a full table scan. The relational tables hold pointers | |
| 78 | +the equivalent of a full table scan. The relational tables hold pointers to | |
| 79 | 79 | the relevant artifacts in presorted order so that generating a timeline |
| 80 | 80 | is much more efficient. So like an index in a relational database, the |
| 81 | -relational tables in an Fossil repository do not add any new information, | |
| 81 | +relational tables in a Fossil repository do not add any new information, | |
| 82 | 82 | they merely make the information in the artifacts faster and easier to |
| 83 | 83 | look up. |
| 84 | 84 | |
| 85 | 85 | Fossil is not "based" on SQLite. Fossil simply exploits SQLite as |
| 86 | 86 | a powerful tool to make the implementation easier. |
| 87 | 87 |
| --- www/theory1.wiki | |
| +++ www/theory1.wiki | |
| @@ -73,14 +73,14 @@ | |
| 73 | implementation detail which currently happens to use SQLite. |
| 74 | |
| 75 | Another way to think of the relational tables in a Fossil repository is |
| 76 | as an index for the artifacts. Without the relational tables, |
| 77 | to generate a report like a timeline would require scanning every artifact - |
| 78 | the equivalent of a full table scan. The relational tables hold pointers |
| 79 | the relevant artifacts in presorted order so that generating a timeline |
| 80 | is much more efficient. So like an index in a relational database, the |
| 81 | relational tables in an Fossil repository do not add any new information, |
| 82 | they merely make the information in the artifacts faster and easier to |
| 83 | look up. |
| 84 | |
| 85 | Fossil is not "based" on SQLite. Fossil simply exploits SQLite as |
| 86 | a powerful tool to make the implementation easier. |
| 87 |
| --- www/theory1.wiki | |
| +++ www/theory1.wiki | |
| @@ -73,14 +73,14 @@ | |
| 73 | implementation detail which currently happens to use SQLite. |
| 74 | |
| 75 | Another way to think of the relational tables in a Fossil repository is |
| 76 | as an index for the artifacts. Without the relational tables, |
| 77 | to generate a report like a timeline would require scanning every artifact - |
| 78 | the equivalent of a full table scan. The relational tables hold pointers to |
| 79 | the relevant artifacts in presorted order so that generating a timeline |
| 80 | is much more efficient. So like an index in a relational database, the |
| 81 | relational tables in a Fossil repository do not add any new information, |
| 82 | they merely make the information in the artifacts faster and easier to |
| 83 | look up. |
| 84 | |
| 85 | Fossil is not "based" on SQLite. Fossil simply exploits SQLite as |
| 86 | a powerful tool to make the implementation easier. |
| 87 |