Fossil SCM
Reverted 'a SQLite' to 'an SQLite' on advice.
Commit
b0d7fb4ad40d6cc3eab8a0cf60a29bf9110914bde87030f67342398c3c347bf0
Parent
b9079597a41d6fe…
10 files changed
+2
-2
+1
-1
+1
-1
+1
-1
+2
-2
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+2
-2
| --- www/alerts.md | ||
| +++ www/alerts.md | ||
| @@ -311,11 +311,11 @@ | ||
| 311 | 311 | ## Advanced Email Setups |
| 312 | 312 | |
| 313 | 313 | Fossil offers several methods of sending email: |
| 314 | 314 | |
| 315 | 315 | 1. Pipe the email message text into a command. |
| 316 | - 2. Store email messages as entries in a SQLite database. | |
| 316 | + 2. Store email messages as entries in an SQLite database. | |
| 317 | 317 | 3. Store email messages as individual files in a directory. |
| 318 | 318 | 4. Send emails to an SMTP relay. |
| 319 | 319 | 5. Send emails directly to the recipients via SMTP. |
| 320 | 320 | |
| 321 | 321 | This wide range of options allows Fossil to talk to pretty much any |
| @@ -390,11 +390,11 @@ | ||
| 390 | 390 | currently uses this method rather than [the pipe method](#pipe) because |
| 391 | 391 | it is running inside of a restrictive [chroot jail][cj] which is unable |
| 392 | 392 | to hand off messages to the local MTA directly. |
| 393 | 393 | |
| 394 | 394 | When you configure a Fossil server this way, it adds outgoing email |
| 395 | -messages to a SQLite database file. A separate daemon process can then | |
| 395 | +messages to an SQLite database file. A separate daemon process can then | |
| 396 | 396 | extract those messages for further disposition. |
| 397 | 397 | |
| 398 | 398 | Fossil includes a copy of [the daemon](/file/tools/email-sender.tcl) |
| 399 | 399 | used on `fossil-scm.org`: it is just a short Tcl script that |
| 400 | 400 | continuously monitors this database for new messages and hands any that |
| 401 | 401 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -311,11 +311,11 @@ | |
| 311 | ## Advanced Email Setups |
| 312 | |
| 313 | Fossil offers several methods of sending email: |
| 314 | |
| 315 | 1. Pipe the email message text into a command. |
| 316 | 2. Store email messages as entries in a SQLite database. |
| 317 | 3. Store email messages as individual files in a directory. |
| 318 | 4. Send emails to an SMTP relay. |
| 319 | 5. Send emails directly to the recipients via SMTP. |
| 320 | |
| 321 | This wide range of options allows Fossil to talk to pretty much any |
| @@ -390,11 +390,11 @@ | |
| 390 | currently uses this method rather than [the pipe method](#pipe) because |
| 391 | it is running inside of a restrictive [chroot jail][cj] which is unable |
| 392 | to hand off messages to the local MTA directly. |
| 393 | |
| 394 | When you configure a Fossil server this way, it adds outgoing email |
| 395 | messages to a SQLite database file. A separate daemon process can then |
| 396 | extract those messages for further disposition. |
| 397 | |
| 398 | Fossil includes a copy of [the daemon](/file/tools/email-sender.tcl) |
| 399 | used on `fossil-scm.org`: it is just a short Tcl script that |
| 400 | continuously monitors this database for new messages and hands any that |
| 401 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -311,11 +311,11 @@ | |
| 311 | ## Advanced Email Setups |
| 312 | |
| 313 | Fossil offers several methods of sending email: |
| 314 | |
| 315 | 1. Pipe the email message text into a command. |
| 316 | 2. Store email messages as entries in an SQLite database. |
| 317 | 3. Store email messages as individual files in a directory. |
| 318 | 4. Send emails to an SMTP relay. |
| 319 | 5. Send emails directly to the recipients via SMTP. |
| 320 | |
| 321 | This wide range of options allows Fossil to talk to pretty much any |
| @@ -390,11 +390,11 @@ | |
| 390 | currently uses this method rather than [the pipe method](#pipe) because |
| 391 | it is running inside of a restrictive [chroot jail][cj] which is unable |
| 392 | to hand off messages to the local MTA directly. |
| 393 | |
| 394 | When you configure a Fossil server this way, it adds outgoing email |
| 395 | messages to an SQLite database file. A separate daemon process can then |
| 396 | extract those messages for further disposition. |
| 397 | |
| 398 | Fossil includes a copy of [the daemon](/file/tools/email-sender.tcl) |
| 399 | used on `fossil-scm.org`: it is just a short Tcl script that |
| 400 | continuously monitors this database for new messages and hands any that |
| 401 |
+1
-1
| --- www/caps/ref.html | ||
| +++ www/caps/ref.html | ||
| @@ -252,11 +252,11 @@ | ||
| 252 | 252 | Create new ticket report formats. Note that although this allows |
| 253 | 253 | the user to provide SQL code to be run in the server’s context, |
| 254 | 254 | and this capability is given to the untrusted “anonymous” user |
| 255 | 255 | category by default, this is a safe capability to give to users |
| 256 | 256 | because it is internally restricted to read-only queries on the |
| 257 | - tickets table only. (This restriction is done with a SQLite | |
| 257 | + tickets table only. (This restriction is done with an SQLite | |
| 258 | 258 | authorization hook, not by any method so weak as SQL text |
| 259 | 259 | filtering.) Mnemonic: new <b>t</b>icket report. |
| 260 | 260 | </td> |
| 261 | 261 | </tr> |
| 262 | 262 | |
| 263 | 263 |
| --- www/caps/ref.html | |
| +++ www/caps/ref.html | |
| @@ -252,11 +252,11 @@ | |
| 252 | Create new ticket report formats. Note that although this allows |
| 253 | the user to provide SQL code to be run in the server’s context, |
| 254 | and this capability is given to the untrusted “anonymous” user |
| 255 | category by default, this is a safe capability to give to users |
| 256 | because it is internally restricted to read-only queries on the |
| 257 | tickets table only. (This restriction is done with a SQLite |
| 258 | authorization hook, not by any method so weak as SQL text |
| 259 | filtering.) Mnemonic: new <b>t</b>icket report. |
| 260 | </td> |
| 261 | </tr> |
| 262 | |
| 263 |
| --- www/caps/ref.html | |
| +++ www/caps/ref.html | |
| @@ -252,11 +252,11 @@ | |
| 252 | Create new ticket report formats. Note that although this allows |
| 253 | the user to provide SQL code to be run in the server’s context, |
| 254 | and this capability is given to the untrusted “anonymous” user |
| 255 | category by default, this is a safe capability to give to users |
| 256 | because it is internally restricted to read-only queries on the |
| 257 | tickets table only. (This restriction is done with an SQLite |
| 258 | authorization hook, not by any method so weak as SQL text |
| 259 | filtering.) Mnemonic: new <b>t</b>icket report. |
| 260 | </td> |
| 261 | </tr> |
| 262 | |
| 263 |
+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 a SQLite database, one record per distinct hash, in | |
| 136 | + stores them in an 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 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 |
| --- 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 |
+1
-1
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -596,11 +596,11 @@ | ||
| 596 | 596 | |
| 597 | 597 | Because Git commingles the repository data with the initial checkout of |
| 598 | 598 | that repository, the default mode of operation in Git is to stick to that |
| 599 | 599 | single work/repo tree, even when that's a shortsighted way of working. |
| 600 | 600 | |
| 601 | -Fossil doesn't work that way. A Fossil repository is a SQLite database | |
| 601 | +Fossil doesn't work that way. A Fossil repository is an SQLite database | |
| 602 | 602 | file which is normally stored outside the working checkout directory. You can |
| 603 | 603 | [/help?cmd=open | open] a Fossil repository any number of times into |
| 604 | 604 | any number of working directories. A common usage pattern is to have one |
| 605 | 605 | working directory per active working branch, so that switching branches |
| 606 | 606 | is done with a <tt>cd</tt> command rather than by checking out the |
| 607 | 607 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -596,11 +596,11 @@ | |
| 596 | |
| 597 | Because Git commingles the repository data with the initial checkout of |
| 598 | that repository, the default mode of operation in Git is to stick to that |
| 599 | single work/repo tree, even when that's a shortsighted way of working. |
| 600 | |
| 601 | Fossil doesn't work that way. A Fossil repository is a SQLite database |
| 602 | file which is normally stored outside the working checkout directory. You can |
| 603 | [/help?cmd=open | open] a Fossil repository any number of times into |
| 604 | any number of working directories. A common usage pattern is to have one |
| 605 | working directory per active working branch, so that switching branches |
| 606 | is done with a <tt>cd</tt> command rather than by checking out the |
| 607 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -596,11 +596,11 @@ | |
| 596 | |
| 597 | Because Git commingles the repository data with the initial checkout of |
| 598 | that repository, the default mode of operation in Git is to stick to that |
| 599 | single work/repo tree, even when that's a shortsighted way of working. |
| 600 | |
| 601 | Fossil doesn't work that way. A Fossil repository is an SQLite database |
| 602 | file which is normally stored outside the working checkout directory. You can |
| 603 | [/help?cmd=open | open] a Fossil repository any number of times into |
| 604 | any number of working directories. A common usage pattern is to have one |
| 605 | working directory per active working branch, so that switching branches |
| 606 | is done with a <tt>cd</tt> command rather than by checking out the |
| 607 |
+2
-2
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -56,11 +56,11 @@ | ||
| 56 | 56 | |
| 57 | 57 | |
| 58 | 58 | |
| 59 | 59 | #### <a id="cwork" name="scw"></a> Checkout Workflows |
| 60 | 60 | |
| 61 | -A Fossil repository is a SQLite database storing the entire history of a | |
| 61 | +A Fossil repository is an SQLite database storing the entire history of a | |
| 62 | 62 | project. It is not normally stored inside the working tree. |
| 63 | 63 | A Fossil working tree — [also called a check-out](./glossary.md#check-out) — is a directory |
| 64 | 64 | that contains a snapshot of your project that you are currently working |
| 65 | 65 | on, extracted for you from the repository database file by the `fossil` |
| 66 | 66 | program. |
| @@ -148,11 +148,11 @@ | ||
| 148 | 148 | option, it won’t let you close the check-out with uncommitted changes to |
| 149 | 149 | those managed files. |
| 150 | 150 | |
| 151 | 151 | The `close` command also refuses to run without `--force` when you have |
| 152 | 152 | certain other precious per-checkout data that Fossil stores in the |
| 153 | -`.fslckout` file at the root of a check-out directory. This is a SQLite | |
| 153 | +`.fslckout` file at the root of a check-out directory. This is an SQLite | |
| 154 | 154 | database that keeps track of local state such as what version you have |
| 155 | 155 | checked out, the contents of the [stash] for that working directory, the |
| 156 | 156 | [undo] buffers, per-checkout [settings][set], and so forth. The stash |
| 157 | 157 | and undo buffers are considered precious uncommitted changes, |
| 158 | 158 | so you have to force Fossil to discard these as part of closing the |
| 159 | 159 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -56,11 +56,11 @@ | |
| 56 | |
| 57 | |
| 58 | |
| 59 | #### <a id="cwork" name="scw"></a> Checkout Workflows |
| 60 | |
| 61 | A Fossil repository is a SQLite database storing the entire history of a |
| 62 | project. It is not normally stored inside the working tree. |
| 63 | A Fossil working tree — [also called a check-out](./glossary.md#check-out) — is a directory |
| 64 | that contains a snapshot of your project that you are currently working |
| 65 | on, extracted for you from the repository database file by the `fossil` |
| 66 | program. |
| @@ -148,11 +148,11 @@ | |
| 148 | option, it won’t let you close the check-out with uncommitted changes to |
| 149 | those managed files. |
| 150 | |
| 151 | The `close` command also refuses to run without `--force` when you have |
| 152 | certain other precious per-checkout data that Fossil stores in the |
| 153 | `.fslckout` file at the root of a check-out directory. This is a SQLite |
| 154 | database that keeps track of local state such as what version you have |
| 155 | checked out, the contents of the [stash] for that working directory, the |
| 156 | [undo] buffers, per-checkout [settings][set], and so forth. The stash |
| 157 | and undo buffers are considered precious uncommitted changes, |
| 158 | so you have to force Fossil to discard these as part of closing the |
| 159 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -56,11 +56,11 @@ | |
| 56 | |
| 57 | |
| 58 | |
| 59 | #### <a id="cwork" name="scw"></a> Checkout Workflows |
| 60 | |
| 61 | A Fossil repository is an SQLite database storing the entire history of a |
| 62 | project. It is not normally stored inside the working tree. |
| 63 | A Fossil working tree — [also called a check-out](./glossary.md#check-out) — is a directory |
| 64 | that contains a snapshot of your project that you are currently working |
| 65 | on, extracted for you from the repository database file by the `fossil` |
| 66 | program. |
| @@ -148,11 +148,11 @@ | |
| 148 | option, it won’t let you close the check-out with uncommitted changes to |
| 149 | those managed files. |
| 150 | |
| 151 | The `close` command also refuses to run without `--force` when you have |
| 152 | certain other precious per-checkout data that Fossil stores in the |
| 153 | `.fslckout` file at the root of a check-out directory. This is an SQLite |
| 154 | database that keeps track of local state such as what version you have |
| 155 | checked out, the contents of the [stash] for that working directory, the |
| 156 | [undo] buffers, per-checkout [settings][set], and so forth. The stash |
| 157 | and undo buffers are considered precious uncommitted changes, |
| 158 | so you have to force Fossil to discard these as part of closing the |
| 159 |
+1
-1
| --- www/glossary.md | ||
| +++ www/glossary.md | ||
| @@ -348,11 +348,11 @@ | ||
| 348 | 348 | |
| 349 | 349 | * In the same way that one cannot extract files from a zip archive |
| 350 | 350 | without having a copy of that zip file, one cannot make check-outs |
| 351 | 351 | without access to the repository file or a clone thereof. |
| 352 | 352 | |
| 353 | -* Because a Fossil repository is a SQLite database file, the same | |
| 353 | +* Because a Fossil repository is an SQLite database file, the same | |
| 354 | 354 | rules for avoiding data corruption apply to it. In particular, it is |
| 355 | 355 | [nearly a hard requirement][h2cflp] that the repository clone be on |
| 356 | 356 | the same machine as the one where you make check-outs and the |
| 357 | 357 | subsequent check-ins. |
| 358 | 358 | |
| 359 | 359 |
| --- www/glossary.md | |
| +++ www/glossary.md | |
| @@ -348,11 +348,11 @@ | |
| 348 | |
| 349 | * In the same way that one cannot extract files from a zip archive |
| 350 | without having a copy of that zip file, one cannot make check-outs |
| 351 | without access to the repository file or a clone thereof. |
| 352 | |
| 353 | * Because a Fossil repository is a SQLite database file, the same |
| 354 | rules for avoiding data corruption apply to it. In particular, it is |
| 355 | [nearly a hard requirement][h2cflp] that the repository clone be on |
| 356 | the same machine as the one where you make check-outs and the |
| 357 | subsequent check-ins. |
| 358 | |
| 359 |
| --- www/glossary.md | |
| +++ www/glossary.md | |
| @@ -348,11 +348,11 @@ | |
| 348 | |
| 349 | * In the same way that one cannot extract files from a zip archive |
| 350 | without having a copy of that zip file, one cannot make check-outs |
| 351 | without access to the repository file or a clone thereof. |
| 352 | |
| 353 | * Because a Fossil repository is an SQLite database file, the same |
| 354 | rules for avoiding data corruption apply to it. In particular, it is |
| 355 | [nearly a hard requirement][h2cflp] that the repository clone be on |
| 356 | the same machine as the one where you make check-outs and the |
| 357 | subsequent check-ins. |
| 358 | |
| 359 |
+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 a SQLite | |
| 58 | +SHA1 to identify artifacts. Monotone stored its content in an 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 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 |
| --- 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 |
+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 a SQLite database so that transactions are | |
| 81 | + in an 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 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 |
| --- 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 |
+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 a SQLite database file. If the argument to "fossil patch create" | |
| 86 | +changes in an 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 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 |
| --- 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 |
+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 a SQLite | |
| 50 | +implementation of Fossil stores each artifact as a BLOB in an 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 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 |
| --- 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 |