Fossil SCM
Spelling fixes, minor editorial
Commit
6b5c797cc3c926834da07a22096cbc605560d4c3
Parent
dabc1105ba85c5d…
1 file changed
+8
-8
+8
-8
| --- www/tech_overview.wiki | ||
| +++ www/tech_overview.wiki | ||
| @@ -33,11 +33,11 @@ | ||
| 33 | 33 | [http://www.sqlite.org/ | SQLite] database files. |
| 34 | 34 | SQLite keeps an entire relational database, including multiple tables and |
| 35 | 35 | indices, in a single disk file. The SQLite library allows the database |
| 36 | 36 | files to be efficiently queried and updated using the industry-standard |
| 37 | 37 | SQL language. And SQLite makes updates to these database files atomic, |
| 38 | -even if a system crashe or power failure occurs in the middle of the | |
| 38 | +even if a system crashes or power failure occurs in the middle of the | |
| 39 | 39 | update, meaning that repository content is protected even during severe |
| 40 | 40 | malfunctions. |
| 41 | 41 | |
| 42 | 42 | Fossil uses three separate classes of SQLite databases: |
| 43 | 43 | |
| @@ -53,11 +53,11 @@ | ||
| 53 | 53 | file that people are normally referring to when they say |
| 54 | 54 | "a Fossil repository". The checkout database is found in the working |
| 55 | 55 | checkout for a project and contains state information that is unique |
| 56 | 56 | to that working checkout. |
| 57 | 57 | |
| 58 | -Fossil does not always use all three databaes files. The web interface, | |
| 58 | +Fossil does not always use all three database files. The web interface, | |
| 59 | 59 | for example, typically only uses the repository database. And the |
| 60 | 60 | [/help/all | fossil setting] command only opens the configuration database |
| 61 | 61 | when the --global option is used. But other commands use all three |
| 62 | 62 | databases at once. For example, the [/help/status | fossil status] |
| 63 | 63 | command will first locate the checkout database, then use the checkout |
| @@ -119,11 +119,11 @@ | ||
| 119 | 119 | apply to a single repository, or they can apply globally to all repositories |
| 120 | 120 | for a user. If both a global and a repository value exists for a setting, |
| 121 | 121 | then the repository-specific value takes precedence. All of the settings |
| 122 | 122 | have reasonable defaults, and so many users will never need to change them. |
| 123 | 123 | But if changes to settings are desired, the configuration database provides |
| 124 | -a why to change settings for all repositories with a single command, rather | |
| 124 | +a way to change settings for all repositories with a single command, rather | |
| 125 | 125 | than having to change the setting individually on each repository. |
| 126 | 126 | |
| 127 | 127 | The configuration database also maintains a list of respositories. This |
| 128 | 128 | list is used by the [/help/all | fossil all] command in order to run various |
| 129 | 129 | operations such as "sync" or "rebuild" on all repositories managed by a user. |
| @@ -135,12 +135,12 @@ | ||
| 135 | 135 | LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. |
| 136 | 136 | |
| 137 | 137 | <h3>2.2 Repository Databases</h3> |
| 138 | 138 | |
| 139 | 139 | The repository database is the file that is commonly referred to as |
| 140 | -"the repository". This is because the responsitory database contains, | |
| 141 | -among other than, the complete revision, ticket, and wiki history for | |
| 140 | +"the repository". This is because the repository database contains, | |
| 141 | +among other things, the complete revision, ticket, and wiki history for | |
| 142 | 142 | a project. It is customary to name the respository database after then |
| 143 | 143 | name of the project, with a ".fossil" suffix. For example, the respository |
| 144 | 144 | database for the self-hosting Fossil repository is called "fossil.fossil" |
| 145 | 145 | and the repository database for SQLite is called "sqlite.fossil". |
| 146 | 146 | |
| @@ -155,16 +155,16 @@ | ||
| 155 | 155 | The combination of zlib and delta compression results in a considerable |
| 156 | 156 | space savings. For the SQLite project, at the time of this writing, |
| 157 | 157 | the total size of all artifacts is over 1.7 GB but thanks to the |
| 158 | 158 | combined zlib and delta compression, that content only takes up |
| 159 | 159 | 51.4 MB of space in the repository database, for a compression ratio |
| 160 | -of about 33 to 1. | |
| 160 | +of about 33:1. | |
| 161 | 161 | |
| 162 | -Note that the zlib and delta compression is not an inherient part of | |
| 162 | +Note that the zlib and delta compression is not an inherent part of the | |
| 163 | 163 | Fossil file format; it is just an optimization. |
| 164 | 164 | The enduring file format for Fossil is the unordered |
| 165 | -set of artifacts and the compression techniques are just a detail of | |
| 165 | +set of artifacts. The compression techniques are just a detail of | |
| 166 | 166 | how the current implementation of Fossil happens to store these artifacts |
| 167 | 167 | efficiently on disk. |
| 168 | 168 | |
| 169 | 169 | All of the original uncompressed and undeltaed artifacts can be extracted |
| 170 | 170 | from a Fossil repository database using |
| 171 | 171 |
| --- www/tech_overview.wiki | |
| +++ www/tech_overview.wiki | |
| @@ -33,11 +33,11 @@ | |
| 33 | [http://www.sqlite.org/ | SQLite] database files. |
| 34 | SQLite keeps an entire relational database, including multiple tables and |
| 35 | indices, in a single disk file. The SQLite library allows the database |
| 36 | files to be efficiently queried and updated using the industry-standard |
| 37 | SQL language. And SQLite makes updates to these database files atomic, |
| 38 | even if a system crashe or power failure occurs in the middle of the |
| 39 | update, meaning that repository content is protected even during severe |
| 40 | malfunctions. |
| 41 | |
| 42 | Fossil uses three separate classes of SQLite databases: |
| 43 | |
| @@ -53,11 +53,11 @@ | |
| 53 | file that people are normally referring to when they say |
| 54 | "a Fossil repository". The checkout database is found in the working |
| 55 | checkout for a project and contains state information that is unique |
| 56 | to that working checkout. |
| 57 | |
| 58 | Fossil does not always use all three databaes files. The web interface, |
| 59 | for example, typically only uses the repository database. And the |
| 60 | [/help/all | fossil setting] command only opens the configuration database |
| 61 | when the --global option is used. But other commands use all three |
| 62 | databases at once. For example, the [/help/status | fossil status] |
| 63 | command will first locate the checkout database, then use the checkout |
| @@ -119,11 +119,11 @@ | |
| 119 | apply to a single repository, or they can apply globally to all repositories |
| 120 | for a user. If both a global and a repository value exists for a setting, |
| 121 | then the repository-specific value takes precedence. All of the settings |
| 122 | have reasonable defaults, and so many users will never need to change them. |
| 123 | But if changes to settings are desired, the configuration database provides |
| 124 | a why to change settings for all repositories with a single command, rather |
| 125 | than having to change the setting individually on each repository. |
| 126 | |
| 127 | The configuration database also maintains a list of respositories. This |
| 128 | list is used by the [/help/all | fossil all] command in order to run various |
| 129 | operations such as "sync" or "rebuild" on all repositories managed by a user. |
| @@ -135,12 +135,12 @@ | |
| 135 | LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. |
| 136 | |
| 137 | <h3>2.2 Repository Databases</h3> |
| 138 | |
| 139 | The repository database is the file that is commonly referred to as |
| 140 | "the repository". This is because the responsitory database contains, |
| 141 | among other than, the complete revision, ticket, and wiki history for |
| 142 | a project. It is customary to name the respository database after then |
| 143 | name of the project, with a ".fossil" suffix. For example, the respository |
| 144 | database for the self-hosting Fossil repository is called "fossil.fossil" |
| 145 | and the repository database for SQLite is called "sqlite.fossil". |
| 146 | |
| @@ -155,16 +155,16 @@ | |
| 155 | The combination of zlib and delta compression results in a considerable |
| 156 | space savings. For the SQLite project, at the time of this writing, |
| 157 | the total size of all artifacts is over 1.7 GB but thanks to the |
| 158 | combined zlib and delta compression, that content only takes up |
| 159 | 51.4 MB of space in the repository database, for a compression ratio |
| 160 | of about 33 to 1. |
| 161 | |
| 162 | Note that the zlib and delta compression is not an inherient part of |
| 163 | Fossil file format; it is just an optimization. |
| 164 | The enduring file format for Fossil is the unordered |
| 165 | set of artifacts and the compression techniques are just a detail of |
| 166 | how the current implementation of Fossil happens to store these artifacts |
| 167 | efficiently on disk. |
| 168 | |
| 169 | All of the original uncompressed and undeltaed artifacts can be extracted |
| 170 | from a Fossil repository database using |
| 171 |
| --- www/tech_overview.wiki | |
| +++ www/tech_overview.wiki | |
| @@ -33,11 +33,11 @@ | |
| 33 | [http://www.sqlite.org/ | SQLite] database files. |
| 34 | SQLite keeps an entire relational database, including multiple tables and |
| 35 | indices, in a single disk file. The SQLite library allows the database |
| 36 | files to be efficiently queried and updated using the industry-standard |
| 37 | SQL language. And SQLite makes updates to these database files atomic, |
| 38 | even if a system crashes or power failure occurs in the middle of the |
| 39 | update, meaning that repository content is protected even during severe |
| 40 | malfunctions. |
| 41 | |
| 42 | Fossil uses three separate classes of SQLite databases: |
| 43 | |
| @@ -53,11 +53,11 @@ | |
| 53 | file that people are normally referring to when they say |
| 54 | "a Fossil repository". The checkout database is found in the working |
| 55 | checkout for a project and contains state information that is unique |
| 56 | to that working checkout. |
| 57 | |
| 58 | Fossil does not always use all three database files. The web interface, |
| 59 | for example, typically only uses the repository database. And the |
| 60 | [/help/all | fossil setting] command only opens the configuration database |
| 61 | when the --global option is used. But other commands use all three |
| 62 | databases at once. For example, the [/help/status | fossil status] |
| 63 | command will first locate the checkout database, then use the checkout |
| @@ -119,11 +119,11 @@ | |
| 119 | apply to a single repository, or they can apply globally to all repositories |
| 120 | for a user. If both a global and a repository value exists for a setting, |
| 121 | then the repository-specific value takes precedence. All of the settings |
| 122 | have reasonable defaults, and so many users will never need to change them. |
| 123 | But if changes to settings are desired, the configuration database provides |
| 124 | a way to change settings for all repositories with a single command, rather |
| 125 | than having to change the setting individually on each repository. |
| 126 | |
| 127 | The configuration database also maintains a list of respositories. This |
| 128 | list is used by the [/help/all | fossil all] command in order to run various |
| 129 | operations such as "sync" or "rebuild" on all repositories managed by a user. |
| @@ -135,12 +135,12 @@ | |
| 135 | LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. |
| 136 | |
| 137 | <h3>2.2 Repository Databases</h3> |
| 138 | |
| 139 | The repository database is the file that is commonly referred to as |
| 140 | "the repository". This is because the repository database contains, |
| 141 | among other things, the complete revision, ticket, and wiki history for |
| 142 | a project. It is customary to name the respository database after then |
| 143 | name of the project, with a ".fossil" suffix. For example, the respository |
| 144 | database for the self-hosting Fossil repository is called "fossil.fossil" |
| 145 | and the repository database for SQLite is called "sqlite.fossil". |
| 146 | |
| @@ -155,16 +155,16 @@ | |
| 155 | The combination of zlib and delta compression results in a considerable |
| 156 | space savings. For the SQLite project, at the time of this writing, |
| 157 | the total size of all artifacts is over 1.7 GB but thanks to the |
| 158 | combined zlib and delta compression, that content only takes up |
| 159 | 51.4 MB of space in the repository database, for a compression ratio |
| 160 | of about 33:1. |
| 161 | |
| 162 | Note that the zlib and delta compression is not an inherent part of the |
| 163 | Fossil file format; it is just an optimization. |
| 164 | The enduring file format for Fossil is the unordered |
| 165 | set of artifacts. The compression techniques are just a detail of |
| 166 | how the current implementation of Fossil happens to store these artifacts |
| 167 | efficiently on disk. |
| 168 | |
| 169 | All of the original uncompressed and undeltaed artifacts can be extracted |
| 170 | from a Fossil repository database using |
| 171 |