Fossil SCM
Minor corrections in grammar to Fossil vs Git rewrite.
Commit
0b90da304fe78337c5b27a289cfac0e1e58f0b74
Parent
61c8d418723b59b…
1 file changed
+2
-2
+2
-2
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -58,11 +58,11 @@ | ||
| 58 | 58 | |
| 59 | 59 | For developers who choose to self-host projects (rather than using a |
| 60 | 60 | 3rd-party service such as GitHub) Fossil is much easier to set up, since |
| 61 | 61 | the stand-alone Fossil executable together with a 2-line CGI script |
| 62 | 62 | suffice to instantiate a full-featured developer website. To accomplish |
| 63 | -the same using Git requires locating, installed, configuring, integrating, | |
| 63 | +the same using Git requires locating, installing, configuring, integrating, | |
| 64 | 64 | and managing a wide assortment of separate tools. Standing up a developer |
| 65 | 65 | website using Fossil can be done in minutes, whereas doing the same using |
| 66 | 66 | Git requires hours or days. |
| 67 | 67 | |
| 68 | 68 | <h3>3.2 Database</h3> |
| @@ -88,11 +88,11 @@ | ||
| 88 | 88 | historical check-in then you cannot ask |
| 89 | 89 | "what came next" or "what are the children of this check-in". |
| 90 | 90 | |
| 91 | 91 | Fossil, on the other hand, parses essential information about check-ins |
| 92 | 92 | (parents, children, committers, comments, files changed, etc.) |
| 93 | -into a relation database that can be easily | |
| 93 | +into a relational database that can be easily | |
| 94 | 94 | queried using concise SQL statements to find both ancestors and |
| 95 | 95 | descendents of a check-in. |
| 96 | 96 | |
| 97 | 97 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 98 | 98 | difficult to locate and subject to garbage collection. This |
| 99 | 99 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -58,11 +58,11 @@ | |
| 58 | |
| 59 | For developers who choose to self-host projects (rather than using a |
| 60 | 3rd-party service such as GitHub) Fossil is much easier to set up, since |
| 61 | the stand-alone Fossil executable together with a 2-line CGI script |
| 62 | suffice to instantiate a full-featured developer website. To accomplish |
| 63 | the same using Git requires locating, installed, configuring, integrating, |
| 64 | and managing a wide assortment of separate tools. Standing up a developer |
| 65 | website using Fossil can be done in minutes, whereas doing the same using |
| 66 | Git requires hours or days. |
| 67 | |
| 68 | <h3>3.2 Database</h3> |
| @@ -88,11 +88,11 @@ | |
| 88 | historical check-in then you cannot ask |
| 89 | "what came next" or "what are the children of this check-in". |
| 90 | |
| 91 | Fossil, on the other hand, parses essential information about check-ins |
| 92 | (parents, children, committers, comments, files changed, etc.) |
| 93 | into a relation database that can be easily |
| 94 | queried using concise SQL statements to find both ancestors and |
| 95 | descendents of a check-in. |
| 96 | |
| 97 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 98 | difficult to locate and subject to garbage collection. This |
| 99 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -58,11 +58,11 @@ | |
| 58 | |
| 59 | For developers who choose to self-host projects (rather than using a |
| 60 | 3rd-party service such as GitHub) Fossil is much easier to set up, since |
| 61 | the stand-alone Fossil executable together with a 2-line CGI script |
| 62 | suffice to instantiate a full-featured developer website. To accomplish |
| 63 | the same using Git requires locating, installing, configuring, integrating, |
| 64 | and managing a wide assortment of separate tools. Standing up a developer |
| 65 | website using Fossil can be done in minutes, whereas doing the same using |
| 66 | Git requires hours or days. |
| 67 | |
| 68 | <h3>3.2 Database</h3> |
| @@ -88,11 +88,11 @@ | |
| 88 | historical check-in then you cannot ask |
| 89 | "what came next" or "what are the children of this check-in". |
| 90 | |
| 91 | Fossil, on the other hand, parses essential information about check-ins |
| 92 | (parents, children, committers, comments, files changed, etc.) |
| 93 | into a relational database that can be easily |
| 94 | queried using concise SQL statements to find both ancestors and |
| 95 | descendents of a check-in. |
| 96 | |
| 97 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 98 | difficult to locate and subject to garbage collection. This |
| 99 |