Fossil SCM
Many improvements to section "2.3 Durable" in fossil-v-git.wiki, largely involving the merger of a near-repeat of the same points down in section 3.1, but also adding more information emphasizing the durability of SQLite DBs in general and Fossil repos in specific.
Commit
cd989fed408504f5aaa61f0003b933633ecd297ef116a0debb02cdd4c8a7367b
Parent
64a33a643ff3ea6…
1 file changed
+29
-35
+29
-35
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -131,45 +131,54 @@ | ||
| 131 | 131 | formatting details. Both systems store check-ins as immutable |
| 132 | 132 | objects referencing their immediate ancestors and named by a |
| 133 | 133 | cryptographic hash of the check-in content. |
| 134 | 134 | |
| 135 | 135 | The difference is that Git stores its objects as individual files |
| 136 | -in the ".git" folder or compressed into | |
| 137 | -bespoke "pack-files," whereas Fossil stores its objects in a | |
| 136 | +in the <tt>.git</tt> folder or compressed into | |
| 137 | +bespoke [https://git-scm.com/book/en/v2/Git-Internals-Packfiles|pack-files], | |
| 138 | +whereas Fossil stores its objects in a | |
| 138 | 139 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 139 | 140 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 140 | -Fossil uses a proven, general-purpose SQL database. This | |
| 141 | -difference is more than an implementation detail. It | |
| 142 | -has important consequences. | |
| 141 | +Fossil uses a proven, [https://sqlite.org/testing.html|heavily-tested], | |
| 142 | +general-purpose, [https://sqlite.org/transactional.html|durable] SQL | |
| 143 | +database. This difference is more than an implementation detail. It has | |
| 144 | +important practical consequences. | |
| 143 | 145 | |
| 144 | 146 | With Git, one can easily locate the ancestors of a particular check-in |
| 145 | 147 | by following the pointers embedded in the check-in object, but it is |
| 146 | 148 | difficult to go the other direction and locate the descendants of a |
| 147 | 149 | check-in. It is so difficult, in fact, that neither native Git nor |
| 148 | -GitHub provide this capability. With Git, if you are looking at some | |
| 149 | -historical check-in then you cannot ask | |
| 150 | -"What came next?" or "What are the children of this check-in?" | |
| 150 | +GitHub provide this capability short of | |
| 151 | +[http://catb.org/jargon/html/G/grovel.html|groveling] the | |
| 152 | +[https://www.git-scm.com/docs/git-log|commit log]. With Git, if you | |
| 153 | +are looking at some historical check-in then you cannot ask "What came | |
| 154 | +next?" or "What are the children of this check-in?" | |
| 151 | 155 | |
| 152 | 156 | Fossil, on the other hand, parses essential information about check-ins |
| 153 | 157 | (parents, children, committers, comments, files changed, etc.) |
| 154 | 158 | into a relational database that can be easily |
| 155 | 159 | queried using concise SQL statements to find both ancestors and |
| 156 | 160 | descendents of a check-in. |
| 157 | 161 | |
| 158 | 162 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 159 | -difficult to locate and subject to garbage collection. This | |
| 160 | -"detached head" problem has caused untold grief for countless | |
| 161 | -Git users. With Fossil, all check-ins are easily located using | |
| 162 | -a variety of attributes (parents, children, committer, date, full-text | |
| 163 | -search of the check-in comment) and so detached heads are simply not possible. | |
| 164 | - | |
| 165 | -The ease with which check-ins can be located and queried in Fossil | |
| 166 | -has resulted in a huge variety of reports and status screens | |
| 167 | -([./webpage-ex.md|examples]) that show project state | |
| 168 | -in ways that help developers | |
| 169 | -maintain enhanced awareness and comprehension | |
| 170 | -and avoid errors. | |
| 163 | +difficult to locate and subject to garbage collection. This | |
| 164 | +[http://gitfaq.org/articles/what-is-a-detached-head.html|detached head | |
| 165 | +state] problem has caused untold grief for countless Git users. With | |
| 166 | +Fossil, all check-ins are easily located via multiple possible paths, | |
| 167 | +so that detached heads are simply not possible in Fossil. | |
| 168 | + | |
| 169 | +This design difference shows up in several other places within each | |
| 170 | +tool. It is why Fossil's [/help?cmd=timeline|timeline] is generally more | |
| 171 | +detailed yet more clear than those available in Git front-ends. | |
| 172 | +(Contrast [/timeline?c=6df7a853ec16865b|this Fossil timeline] with | |
| 173 | +[https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34|its | |
| 174 | +closest equivalent in GitHub].) It's why there is no inverse of the | |
| 175 | +cryptic <tt>@~</tt> notation in Git, meaning "the parent of HEAD," which | |
| 176 | +Fossil simply calls "prev", but there <i>is</i> a "next" | |
| 177 | +[./checkin_names.wiki|special check-in name] in Fossil. It is why Fossil | |
| 178 | +has so many [./webpage-ex.md|built-in status reports] to help maintain | |
| 179 | +situational awareness, aid comprehension, and avoid errors. | |
| 171 | 180 | |
| 172 | 181 | |
| 173 | 182 | <h3 id="portable">2.4 Portable</h3> |
| 174 | 183 | |
| 175 | 184 | Fossil is largely written in ISO C, almost purely conforming to the |
| @@ -571,25 +580,10 @@ | ||
| 571 | 580 | are some others we haven't gotten to yet. |
| 572 | 581 | |
| 573 | 582 | |
| 574 | 583 | <h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3> |
| 575 | 584 | |
| 576 | - * <b>The ability to show descendents of a check-in.</b> | |
| 577 | - | |
| 578 | - Both Git and Fossil can easily find the ancestors of a check-in, but | |
| 579 | - Fossil can also quickly find the descendents for any check-in. To do | |
| 580 | - it in Git, you have to grovel through the commit log. | |
| 581 | - | |
| 582 | - This fact has many knock-on effects and shows up in several parts of | |
| 583 | - the design of each tool. It is why Fossil's | |
| 584 | - [/help?cmd=timeline|timeline] is generally easier and more clear than | |
| 585 | - those available in Git front-ends. It is why Fossil is immune from | |
| 586 | - Git's "detached head state." It's why Git has the cryptic <tt>@~</tt> | |
| 587 | - notation meaning "the parent of HEAD" (what Fossil simply | |
| 588 | - [./checkin_names.wiki|calls "prev"]) but there is no way to ask Git | |
| 589 | - for the child of the current checkin, as with "next" in Fossil. | |
| 590 | - | |
| 591 | 585 | * <b>The [/help?cmd=all|fossil all] command</b> |
| 592 | 586 | |
| 593 | 587 | Fossil keeps track of all repositories and check-outs and allows |
| 594 | 588 | operations over all of them with a single command. For example, in |
| 595 | 589 | Fossil is possible to request a pull of all repositories on a laptop |
| 596 | 590 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -131,45 +131,54 @@ | |
| 131 | formatting details. Both systems store check-ins as immutable |
| 132 | objects referencing their immediate ancestors and named by a |
| 133 | cryptographic hash of the check-in content. |
| 134 | |
| 135 | The difference is that Git stores its objects as individual files |
| 136 | in the ".git" folder or compressed into |
| 137 | bespoke "pack-files," whereas Fossil stores its objects in a |
| 138 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 139 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 140 | Fossil uses a proven, general-purpose SQL database. This |
| 141 | difference is more than an implementation detail. It |
| 142 | has important consequences. |
| 143 | |
| 144 | With Git, one can easily locate the ancestors of a particular check-in |
| 145 | by following the pointers embedded in the check-in object, but it is |
| 146 | difficult to go the other direction and locate the descendants of a |
| 147 | check-in. It is so difficult, in fact, that neither native Git nor |
| 148 | GitHub provide this capability. With Git, if you are looking at some |
| 149 | historical check-in then you cannot ask |
| 150 | "What came next?" or "What are the children of this check-in?" |
| 151 | |
| 152 | Fossil, on the other hand, parses essential information about check-ins |
| 153 | (parents, children, committers, comments, files changed, etc.) |
| 154 | into a relational database that can be easily |
| 155 | queried using concise SQL statements to find both ancestors and |
| 156 | descendents of a check-in. |
| 157 | |
| 158 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 159 | difficult to locate and subject to garbage collection. This |
| 160 | "detached head" problem has caused untold grief for countless |
| 161 | Git users. With Fossil, all check-ins are easily located using |
| 162 | a variety of attributes (parents, children, committer, date, full-text |
| 163 | search of the check-in comment) and so detached heads are simply not possible. |
| 164 | |
| 165 | The ease with which check-ins can be located and queried in Fossil |
| 166 | has resulted in a huge variety of reports and status screens |
| 167 | ([./webpage-ex.md|examples]) that show project state |
| 168 | in ways that help developers |
| 169 | maintain enhanced awareness and comprehension |
| 170 | and avoid errors. |
| 171 | |
| 172 | |
| 173 | <h3 id="portable">2.4 Portable</h3> |
| 174 | |
| 175 | Fossil is largely written in ISO C, almost purely conforming to the |
| @@ -571,25 +580,10 @@ | |
| 571 | are some others we haven't gotten to yet. |
| 572 | |
| 573 | |
| 574 | <h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3> |
| 575 | |
| 576 | * <b>The ability to show descendents of a check-in.</b> |
| 577 | |
| 578 | Both Git and Fossil can easily find the ancestors of a check-in, but |
| 579 | Fossil can also quickly find the descendents for any check-in. To do |
| 580 | it in Git, you have to grovel through the commit log. |
| 581 | |
| 582 | This fact has many knock-on effects and shows up in several parts of |
| 583 | the design of each tool. It is why Fossil's |
| 584 | [/help?cmd=timeline|timeline] is generally easier and more clear than |
| 585 | those available in Git front-ends. It is why Fossil is immune from |
| 586 | Git's "detached head state." It's why Git has the cryptic <tt>@~</tt> |
| 587 | notation meaning "the parent of HEAD" (what Fossil simply |
| 588 | [./checkin_names.wiki|calls "prev"]) but there is no way to ask Git |
| 589 | for the child of the current checkin, as with "next" in Fossil. |
| 590 | |
| 591 | * <b>The [/help?cmd=all|fossil all] command</b> |
| 592 | |
| 593 | Fossil keeps track of all repositories and check-outs and allows |
| 594 | operations over all of them with a single command. For example, in |
| 595 | Fossil is possible to request a pull of all repositories on a laptop |
| 596 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -131,45 +131,54 @@ | |
| 131 | formatting details. Both systems store check-ins as immutable |
| 132 | objects referencing their immediate ancestors and named by a |
| 133 | cryptographic hash of the check-in content. |
| 134 | |
| 135 | The difference is that Git stores its objects as individual files |
| 136 | in the <tt>.git</tt> folder or compressed into |
| 137 | bespoke [https://git-scm.com/book/en/v2/Git-Internals-Packfiles|pack-files], |
| 138 | whereas Fossil stores its objects in a |
| 139 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 140 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 141 | Fossil uses a proven, [https://sqlite.org/testing.html|heavily-tested], |
| 142 | general-purpose, [https://sqlite.org/transactional.html|durable] SQL |
| 143 | database. This difference is more than an implementation detail. It has |
| 144 | important practical consequences. |
| 145 | |
| 146 | With Git, one can easily locate the ancestors of a particular check-in |
| 147 | by following the pointers embedded in the check-in object, but it is |
| 148 | difficult to go the other direction and locate the descendants of a |
| 149 | check-in. It is so difficult, in fact, that neither native Git nor |
| 150 | GitHub provide this capability short of |
| 151 | [http://catb.org/jargon/html/G/grovel.html|groveling] the |
| 152 | [https://www.git-scm.com/docs/git-log|commit log]. With Git, if you |
| 153 | are looking at some historical check-in then you cannot ask "What came |
| 154 | next?" or "What are the children of this check-in?" |
| 155 | |
| 156 | Fossil, on the other hand, parses essential information about check-ins |
| 157 | (parents, children, committers, comments, files changed, etc.) |
| 158 | into a relational database that can be easily |
| 159 | queried using concise SQL statements to find both ancestors and |
| 160 | descendents of a check-in. |
| 161 | |
| 162 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 163 | difficult to locate and subject to garbage collection. This |
| 164 | [http://gitfaq.org/articles/what-is-a-detached-head.html|detached head |
| 165 | state] problem has caused untold grief for countless Git users. With |
| 166 | Fossil, all check-ins are easily located via multiple possible paths, |
| 167 | so that detached heads are simply not possible in Fossil. |
| 168 | |
| 169 | This design difference shows up in several other places within each |
| 170 | tool. It is why Fossil's [/help?cmd=timeline|timeline] is generally more |
| 171 | detailed yet more clear than those available in Git front-ends. |
| 172 | (Contrast [/timeline?c=6df7a853ec16865b|this Fossil timeline] with |
| 173 | [https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34|its |
| 174 | closest equivalent in GitHub].) It's why there is no inverse of the |
| 175 | cryptic <tt>@~</tt> notation in Git, meaning "the parent of HEAD," which |
| 176 | Fossil simply calls "prev", but there <i>is</i> a "next" |
| 177 | [./checkin_names.wiki|special check-in name] in Fossil. It is why Fossil |
| 178 | has so many [./webpage-ex.md|built-in status reports] to help maintain |
| 179 | situational awareness, aid comprehension, and avoid errors. |
| 180 | |
| 181 | |
| 182 | <h3 id="portable">2.4 Portable</h3> |
| 183 | |
| 184 | Fossil is largely written in ISO C, almost purely conforming to the |
| @@ -571,25 +580,10 @@ | |
| 580 | are some others we haven't gotten to yet. |
| 581 | |
| 582 | |
| 583 | <h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3> |
| 584 | |
| 585 | * <b>The [/help?cmd=all|fossil all] command</b> |
| 586 | |
| 587 | Fossil keeps track of all repositories and check-outs and allows |
| 588 | operations over all of them with a single command. For example, in |
| 589 | Fossil is possible to request a pull of all repositories on a laptop |
| 590 |