Fossil SCM
Canonicalize use of SQLite where it makes sense instead of sqlite. Also changed from 'an sqlite' to 'a SQLite' as authors use seekwilite for pronunciation
Commit
b9079597a41d6fe4afc13da5ba97e1ff192abf0f0dfb0ec154a07eb9c25f0ac1
Parent
d12511740f82527…
6 files changed
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
| --- www/fossil-is-not-relational.md | ||
| +++ www/fossil-is-not-relational.md | ||
| @@ -131,11 +131,11 @@ | ||
| 131 | 131 | metadata. |
| 132 | 132 | |
| 133 | 133 | - Raw file content of versioned files. These data are external to |
| 134 | 134 | artifacts, which refer to them by their hashes. How they are stored |
| 135 | 135 | is not the concern of the data model, but (spoiler alert!) Fossil |
| 136 | - stores them in an sqlite database, one record per distinct hash, in | |
| 136 | + stores them in a SQLite database, one record per distinct hash, in | |
| 137 | 137 | its `blob` table (which we will cover more very soon). |
| 138 | 138 | |
| 139 | 139 | Non-SCM-relevant state includes: |
| 140 | 140 | |
| 141 | 141 | - Fossil's list of users and their metadata (permissions, email |
| 142 | 142 |
| --- www/fossil-is-not-relational.md | |
| +++ www/fossil-is-not-relational.md | |
| @@ -131,11 +131,11 @@ | |
| 131 | metadata. |
| 132 | |
| 133 | - Raw file content of versioned files. These data are external to |
| 134 | artifacts, which refer to them by their hashes. How they are stored |
| 135 | is not the concern of the data model, but (spoiler alert!) Fossil |
| 136 | stores them in an sqlite database, one record per distinct hash, in |
| 137 | its `blob` table (which we will cover more very soon). |
| 138 | |
| 139 | Non-SCM-relevant state includes: |
| 140 | |
| 141 | - Fossil's list of users and their metadata (permissions, email |
| 142 |
| --- www/fossil-is-not-relational.md | |
| +++ www/fossil-is-not-relational.md | |
| @@ -131,11 +131,11 @@ | |
| 131 | metadata. |
| 132 | |
| 133 | - Raw file content of versioned files. These data are external to |
| 134 | artifacts, which refer to them by their hashes. How they are stored |
| 135 | is not the concern of the data model, but (spoiler alert!) Fossil |
| 136 | stores them in a SQLite database, one record per distinct hash, in |
| 137 | its `blob` table (which we will cover more very soon). |
| 138 | |
| 139 | Non-SCM-relevant state includes: |
| 140 | |
| 141 | - Fossil's list of users and their metadata (permissions, email |
| 142 |
+1
-1
| --- www/history.md | ||
| +++ www/history.md | ||
| @@ -53,11 +53,11 @@ | ||
| 53 | 53 | [330]: https://sqlite.org/src/timeline?c=20030101&n1=10&nd |
| 54 | 54 | |
| 55 | 55 | At about this same time, the [Monotone][335] system appeared. |
| 56 | 56 | Monotone was one of the first distributed version control systems. As far as |
| 57 | 57 | this author is aware, Monotone was the first VCS to make use of |
| 58 | -SHA1 to identify artifacts. Monotone stored its content in an SQLite | |
| 58 | +SHA1 to identify artifacts. Monotone stored its content in a SQLite | |
| 59 | 59 | database, which is what brought it to the attention of the SQLite architect. |
| 60 | 60 | These design choices were a major source of inspiration for Fossil. |
| 61 | 61 | |
| 62 | 62 | [335]: https://www.monotone.ca/ |
| 63 | 63 | |
| 64 | 64 |
| --- www/history.md | |
| +++ www/history.md | |
| @@ -53,11 +53,11 @@ | |
| 53 | [330]: https://sqlite.org/src/timeline?c=20030101&n1=10&nd |
| 54 | |
| 55 | At about this same time, the [Monotone][335] system appeared. |
| 56 | Monotone was one of the first distributed version control systems. As far as |
| 57 | this author is aware, Monotone was the first VCS to make use of |
| 58 | SHA1 to identify artifacts. Monotone stored its content in an SQLite |
| 59 | database, which is what brought it to the attention of the SQLite architect. |
| 60 | These design choices were a major source of inspiration for Fossil. |
| 61 | |
| 62 | [335]: https://www.monotone.ca/ |
| 63 | |
| 64 |
| --- www/history.md | |
| +++ www/history.md | |
| @@ -53,11 +53,11 @@ | |
| 53 | [330]: https://sqlite.org/src/timeline?c=20030101&n1=10&nd |
| 54 | |
| 55 | At about this same time, the [Monotone][335] system appeared. |
| 56 | Monotone was one of the first distributed version control systems. As far as |
| 57 | this author is aware, Monotone was the first VCS to make use of |
| 58 | SHA1 to identify artifacts. Monotone stored its content in a SQLite |
| 59 | database, which is what brought it to the attention of the SQLite architect. |
| 60 | These design choices were a major source of inspiration for Fossil. |
| 61 | |
| 62 | [335]: https://www.monotone.ca/ |
| 63 | |
| 64 |
+1
-1
| --- www/index.wiki | ||
| +++ www/index.wiki | ||
| @@ -76,11 +76,11 @@ | ||
| 76 | 76 | [./branching.wiki | forking and merging] often |
| 77 | 77 | associated with distributed projects. |
| 78 | 78 | |
| 79 | 79 | 7. <b>Robust & Reliable</b> — |
| 80 | 80 | Fossil stores content using an [./fileformat.wiki | enduring file format] |
| 81 | - in an SQLite database so that transactions are | |
| 81 | + in a SQLite database so that transactions are | |
| 82 | 82 | atomic even if interrupted by a power loss or system crash. |
| 83 | 83 | Automatic [./selfcheck.wiki | self-checks] verify that all aspects of |
| 84 | 84 | the repository are consistent prior to each commit. |
| 85 | 85 | |
| 86 | 86 | 8. <b>Free and Open-Source</b> — [../COPYRIGHT-BSD2.txt|2-clause BSD license]. |
| 87 | 87 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -76,11 +76,11 @@ | |
| 76 | [./branching.wiki | forking and merging] often |
| 77 | associated with distributed projects. |
| 78 | |
| 79 | 7. <b>Robust & Reliable</b> — |
| 80 | Fossil stores content using an [./fileformat.wiki | enduring file format] |
| 81 | in an SQLite database so that transactions are |
| 82 | atomic even if interrupted by a power loss or system crash. |
| 83 | Automatic [./selfcheck.wiki | self-checks] verify that all aspects of |
| 84 | the repository are consistent prior to each commit. |
| 85 | |
| 86 | 8. <b>Free and Open-Source</b> — [../COPYRIGHT-BSD2.txt|2-clause BSD license]. |
| 87 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -76,11 +76,11 @@ | |
| 76 | [./branching.wiki | forking and merging] often |
| 77 | associated with distributed projects. |
| 78 | |
| 79 | 7. <b>Robust & Reliable</b> — |
| 80 | Fossil stores content using an [./fileformat.wiki | enduring file format] |
| 81 | in a SQLite database so that transactions are |
| 82 | atomic even if interrupted by a power loss or system crash. |
| 83 | Automatic [./selfcheck.wiki | self-checks] verify that all aspects of |
| 84 | the repository are consistent prior to each commit. |
| 85 | |
| 86 | 8. <b>Free and Open-Source</b> — [../COPYRIGHT-BSD2.txt|2-clause BSD license]. |
| 87 |
+1
-1
| --- www/patchcmd.md | ||
| +++ www/patchcmd.md | ||
| @@ -81,11 +81,11 @@ | ||
| 81 | 81 | |
| 82 | 82 | |
| 83 | 83 | ## Implementation Details |
| 84 | 84 | |
| 85 | 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | -changes in an SQLite database file. If the argument to "fossil patch create" | |
| 86 | +changes in a SQLite database file. If the argument to "fossil patch create" | |
| 87 | 87 | is a filename, then the patch-file database is written into that file. |
| 88 | 88 | If the argument is "-" then the database is written on standard output. |
| 89 | 89 | |
| 90 | 90 | The "fossil patch apply" command reads the patch-file database |
| 91 | 91 | and applies it to the local check-out. If a filename is given as an |
| 92 | 92 |
| --- www/patchcmd.md | |
| +++ www/patchcmd.md | |
| @@ -81,11 +81,11 @@ | |
| 81 | |
| 82 | |
| 83 | ## Implementation Details |
| 84 | |
| 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | changes in an SQLite database file. If the argument to "fossil patch create" |
| 87 | is a filename, then the patch-file database is written into that file. |
| 88 | If the argument is "-" then the database is written on standard output. |
| 89 | |
| 90 | The "fossil patch apply" command reads the patch-file database |
| 91 | and applies it to the local check-out. If a filename is given as an |
| 92 |
| --- www/patchcmd.md | |
| +++ www/patchcmd.md | |
| @@ -81,11 +81,11 @@ | |
| 81 | |
| 82 | |
| 83 | ## Implementation Details |
| 84 | |
| 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | changes in a SQLite database file. If the argument to "fossil patch create" |
| 87 | is a filename, then the patch-file database is written into that file. |
| 88 | If the argument is "-" then the database is written on standard output. |
| 89 | |
| 90 | The "fossil patch apply" command reads the patch-file database |
| 91 | and applies it to the local check-out. If a filename is given as an |
| 92 |
+1
-1
| --- www/qandc.wiki | ||
| +++ www/qandc.wiki | ||
| @@ -142,11 +142,11 @@ | ||
| 142 | 142 | fossil supports disconnected operation. |
| 143 | 143 | |
| 144 | 144 | As for bloat: Fossil is a single self-contained executable. |
| 145 | 145 | You do not need any other packages |
| 146 | 146 | (diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache, |
| 147 | -sqlite, and so forth) | |
| 147 | +SQLite, and so forth) | |
| 148 | 148 | in order to run fossil. Fossil runs just fine in a chroot jail all |
| 149 | 149 | by itself. And the self-contained fossil |
| 150 | 150 | executable is much less than 1MB in size. (Update 2015-01-12: Fossil has |
| 151 | 151 | grown in the years since the previous sentence was written but is still |
| 152 | 152 | much less than 2MB according to "size" when compiled using -Os on x64 Linux.) |
| 153 | 153 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -142,11 +142,11 @@ | |
| 142 | fossil supports disconnected operation. |
| 143 | |
| 144 | As for bloat: Fossil is a single self-contained executable. |
| 145 | You do not need any other packages |
| 146 | (diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache, |
| 147 | sqlite, and so forth) |
| 148 | in order to run fossil. Fossil runs just fine in a chroot jail all |
| 149 | by itself. And the self-contained fossil |
| 150 | executable is much less than 1MB in size. (Update 2015-01-12: Fossil has |
| 151 | grown in the years since the previous sentence was written but is still |
| 152 | much less than 2MB according to "size" when compiled using -Os on x64 Linux.) |
| 153 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -142,11 +142,11 @@ | |
| 142 | fossil supports disconnected operation. |
| 143 | |
| 144 | As for bloat: Fossil is a single self-contained executable. |
| 145 | You do not need any other packages |
| 146 | (diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache, |
| 147 | SQLite, and so forth) |
| 148 | in order to run fossil. Fossil runs just fine in a chroot jail all |
| 149 | by itself. And the self-contained fossil |
| 150 | executable is much less than 1MB in size. (Update 2015-01-12: Fossil has |
| 151 | grown in the years since the previous sentence was written but is still |
| 152 | much less than 2MB according to "size" when compiled using -Os on x64 Linux.) |
| 153 |
+1
-1
| --- www/theory1.wiki | ||
| +++ www/theory1.wiki | ||
| @@ -45,11 +45,11 @@ | ||
| 45 | 45 | the exceptional case of [./shunning.wiki | shunning].) Repositories |
| 46 | 46 | synchronize by computing the union of their artifact sets. SQL and |
| 47 | 47 | relation theory play no role in any of this. |
| 48 | 48 | |
| 49 | 49 | SQL enters the picture only in the implementation details. The current |
| 50 | -implementation of Fossil stores each artifact as a BLOB in an SQLite | |
| 50 | +implementation of Fossil stores each artifact as a BLOB in a SQLite | |
| 51 | 51 | database. |
| 52 | 52 | The current implementation also parses up each control artifact as it |
| 53 | 53 | arrives and stores the information discovered from that parse in various |
| 54 | 54 | other SQLite tables to facilitate rapid generation of reports such as |
| 55 | 55 | timelines, file histories, file lists, branch lists, and so forth. Note |
| 56 | 56 |
| --- www/theory1.wiki | |
| +++ www/theory1.wiki | |
| @@ -45,11 +45,11 @@ | |
| 45 | the exceptional case of [./shunning.wiki | shunning].) Repositories |
| 46 | synchronize by computing the union of their artifact sets. SQL and |
| 47 | relation theory play no role in any of this. |
| 48 | |
| 49 | SQL enters the picture only in the implementation details. The current |
| 50 | implementation of Fossil stores each artifact as a BLOB in an SQLite |
| 51 | database. |
| 52 | The current implementation also parses up each control artifact as it |
| 53 | arrives and stores the information discovered from that parse in various |
| 54 | other SQLite tables to facilitate rapid generation of reports such as |
| 55 | timelines, file histories, file lists, branch lists, and so forth. Note |
| 56 |
| --- www/theory1.wiki | |
| +++ www/theory1.wiki | |
| @@ -45,11 +45,11 @@ | |
| 45 | the exceptional case of [./shunning.wiki | shunning].) Repositories |
| 46 | synchronize by computing the union of their artifact sets. SQL and |
| 47 | relation theory play no role in any of this. |
| 48 | |
| 49 | SQL enters the picture only in the implementation details. The current |
| 50 | implementation of Fossil stores each artifact as a BLOB in a SQLite |
| 51 | database. |
| 52 | The current implementation also parses up each control artifact as it |
| 53 | arrives and stores the information discovered from that parse in various |
| 54 | other SQLite tables to facilitate rapid generation of reports such as |
| 55 | timelines, file histories, file lists, branch lists, and so forth. Note |
| 56 |