Fossil SCM
Tightened up §2.3 in that same doc
Commit
939136a7ea44b764bcb61c4991e0c2261fb5ba5c8a5f445eb06867e2e64a516b
Parent
b95abfd325f436c…
1 file changed
+20
-26
+20
-26
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -280,33 +280,34 @@ | ||
| 280 | 280 | <tt>.git</tt> folder or compressed into bespoke key/value |
| 281 | 281 | [https://git-scm.com/book/en/v2/Git-Internals-Packfiles|pack-files], |
| 282 | 282 | whereas Fossil stores its objects in a [https://www.sqlite.org/|SQLite] |
| 283 | 283 | database file which provides ACID transactions and a high-level query |
| 284 | 284 | language. |
| 285 | -This difference is more than an implementation detail. It has important | |
| 285 | + | |
| 286 | +This difference is more than an implementation detail; it has important | |
| 286 | 287 | practical consequences. |
| 287 | 288 | |
| 288 | -One notable consequence is that it is difficult to find the descendants | |
| 289 | +One notable example is that it is difficult to find the descendants | |
| 289 | 290 | of check-ins in Git. |
| 290 | 291 | One can easily locate the ancestors of a particular Git check-in |
| 291 | -by following the pointers embedded in the check-in object, but it is | |
| 292 | -difficult to go the other direction and locate the descendants of a | |
| 293 | -check-in. It is so difficult, in fact, that neither native Git nor | |
| 294 | -GitHub provide this capability short of crawling the | |
| 295 | -[https://www.git-scm.com/docs/git-log|commit log]. With Fossil, | |
| 296 | -on the other hand, finding descendants is a simple SQL query. | |
| 297 | -It is common in Fossil to ask to see | |
| 298 | -[/timeline?df=release&y=ci|all check-ins since the last release]. | |
| 299 | -Git lets you see "what came before". Fossil makes it just as | |
| 300 | -easy to also see "what came after". | |
| 292 | +by following the pointers embedded in the check-in object, but | |
| 293 | +going the other direction is difficult enough | |
| 294 | +that neither native Git nor the big "forge" facilities | |
| 295 | +like GitHub and GitLab provide this capability short of crawling the | |
| 296 | +[https://www.git-scm.com/docs/git-log|commit log]. In Fossil, | |
| 297 | +we can find descendants using a simple SQL query, which then allows | |
| 298 | +us to see [/timeline?df=release&y=ci|all check-ins since the last release], | |
| 299 | +as but one example. | |
| 300 | +Git lets you see "what came before," but Fossil makes it just as | |
| 301 | +easy to also see "what came after." | |
| 301 | 302 | |
| 302 | 303 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 303 | 304 | difficult to locate and subject to garbage collection. This |
| 304 | 305 | [https://stackoverflow.com/q/3965676 | detached head |
| 305 | 306 | state] problem has caused grief for |
| 306 | -[https://www.google.com/search?q=git+detached+head+state | many | |
| 307 | -Git users]. With | |
| 307 | +[https://www.google.com/search?q=git+detached+head+state | | |
| 308 | +untold millions of Git users]. With | |
| 308 | 309 | Fossil, detached heads are simply impossible because we can always find |
| 309 | 310 | our way back into the Merkle tree using one or more of the relations |
| 310 | 311 | in the SQL database. |
| 311 | 312 | |
| 312 | 313 | The SQL query capabilities of Fossil make it easier to track the |
| @@ -313,34 +314,27 @@ | ||
| 313 | 314 | changes for one particular file within a project. For example, |
| 314 | 315 | you can easily find |
| 315 | 316 | [/finfo/www/fossil-v-git.wiki|the complete edit history of this one document], |
| 316 | 317 | or even |
| 317 | 318 | [/finfo/www/fossil-v-git.wiki?ubg|the same history color-coded by committer], |
| 318 | -Both questions are simple SQL query in Fossil, with procedural code | |
| 319 | +Both come down to simple SQL queries in Fossil, with procedural code | |
| 319 | 320 | only being used to format the result for display. |
| 320 | 321 | The same result could be obtained from Git, but because the data is |
| 321 | 322 | in a key/value store, much more procedural code has to be written to |
| 322 | -walk the data and compute the result. And since that is a lot more | |
| 323 | -work, the question is seldom asked. | |
| 323 | +walk the data and compute the result. | |
| 324 | 324 | |
| 325 | 325 | The ease of querying Fossil data using SQL means that status or |
| 326 | 326 | history information about the project under management is easier |
| 327 | -to obtain. Being easier means that it is more likely to happen. | |
| 327 | +to obtain, hence more likely to happen, giving its developers better | |
| 328 | +situational awareness. | |
| 328 | 329 | Fossil reports tend to be more detailed and useful. |
| 329 | 330 | Compare [/timeline?c=6df7a853ec16865b|this Fossil timeline] |
| 330 | 331 | to |
| 331 | 332 | [https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34 | |
| 332 | -its closest equivalent in GitHub]. Judge for yourself: which of those | |
| 333 | +its closest equivalent in the GitHub mirror]. Judge for yourself: which of those | |
| 333 | 334 | reports is more useful to a developer trying to understand what happened? |
| 334 | 335 | |
| 335 | -The bottom line is that even though Fossil and Git are built around | |
| 336 | -the same low-level data structure, the use of SQL | |
| 337 | -to query this data makes the data more accessible in Fossil, resulting | |
| 338 | -in more detailed information being available to the user. This | |
| 339 | -improves situational awareness and makes working on the project | |
| 340 | -easier. | |
| 341 | - | |
| 342 | 336 | <h3 id="portable">2.4 Portable</h3> |
| 343 | 337 | |
| 344 | 338 | Fossil is largely written in ISO C, almost purely conforming to the |
| 345 | 339 | original 1989 standard. We make very little use of |
| 346 | 340 | [https://en.wikipedia.org/wiki/C99|C99], and we do not knowingly make |
| 347 | 341 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -280,33 +280,34 @@ | |
| 280 | <tt>.git</tt> folder or compressed into bespoke key/value |
| 281 | [https://git-scm.com/book/en/v2/Git-Internals-Packfiles|pack-files], |
| 282 | whereas Fossil stores its objects in a [https://www.sqlite.org/|SQLite] |
| 283 | database file which provides ACID transactions and a high-level query |
| 284 | language. |
| 285 | This difference is more than an implementation detail. It has important |
| 286 | practical consequences. |
| 287 | |
| 288 | One notable consequence is that it is difficult to find the descendants |
| 289 | of check-ins in Git. |
| 290 | One can easily locate the ancestors of a particular Git check-in |
| 291 | by following the pointers embedded in the check-in object, but it is |
| 292 | difficult to go the other direction and locate the descendants of a |
| 293 | check-in. It is so difficult, in fact, that neither native Git nor |
| 294 | GitHub provide this capability short of crawling the |
| 295 | [https://www.git-scm.com/docs/git-log|commit log]. With Fossil, |
| 296 | on the other hand, finding descendants is a simple SQL query. |
| 297 | It is common in Fossil to ask to see |
| 298 | [/timeline?df=release&y=ci|all check-ins since the last release]. |
| 299 | Git lets you see "what came before". Fossil makes it just as |
| 300 | easy to also see "what came after". |
| 301 | |
| 302 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 303 | difficult to locate and subject to garbage collection. This |
| 304 | [https://stackoverflow.com/q/3965676 | detached head |
| 305 | state] problem has caused grief for |
| 306 | [https://www.google.com/search?q=git+detached+head+state | many |
| 307 | Git users]. With |
| 308 | Fossil, detached heads are simply impossible because we can always find |
| 309 | our way back into the Merkle tree using one or more of the relations |
| 310 | in the SQL database. |
| 311 | |
| 312 | The SQL query capabilities of Fossil make it easier to track the |
| @@ -313,34 +314,27 @@ | |
| 313 | changes for one particular file within a project. For example, |
| 314 | you can easily find |
| 315 | [/finfo/www/fossil-v-git.wiki|the complete edit history of this one document], |
| 316 | or even |
| 317 | [/finfo/www/fossil-v-git.wiki?ubg|the same history color-coded by committer], |
| 318 | Both questions are simple SQL query in Fossil, with procedural code |
| 319 | only being used to format the result for display. |
| 320 | The same result could be obtained from Git, but because the data is |
| 321 | in a key/value store, much more procedural code has to be written to |
| 322 | walk the data and compute the result. And since that is a lot more |
| 323 | work, the question is seldom asked. |
| 324 | |
| 325 | The ease of querying Fossil data using SQL means that status or |
| 326 | history information about the project under management is easier |
| 327 | to obtain. Being easier means that it is more likely to happen. |
| 328 | Fossil reports tend to be more detailed and useful. |
| 329 | Compare [/timeline?c=6df7a853ec16865b|this Fossil timeline] |
| 330 | to |
| 331 | [https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34 | |
| 332 | its closest equivalent in GitHub]. Judge for yourself: which of those |
| 333 | reports is more useful to a developer trying to understand what happened? |
| 334 | |
| 335 | The bottom line is that even though Fossil and Git are built around |
| 336 | the same low-level data structure, the use of SQL |
| 337 | to query this data makes the data more accessible in Fossil, resulting |
| 338 | in more detailed information being available to the user. This |
| 339 | improves situational awareness and makes working on the project |
| 340 | easier. |
| 341 | |
| 342 | <h3 id="portable">2.4 Portable</h3> |
| 343 | |
| 344 | Fossil is largely written in ISO C, almost purely conforming to the |
| 345 | original 1989 standard. We make very little use of |
| 346 | [https://en.wikipedia.org/wiki/C99|C99], and we do not knowingly make |
| 347 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -280,33 +280,34 @@ | |
| 280 | <tt>.git</tt> folder or compressed into bespoke key/value |
| 281 | [https://git-scm.com/book/en/v2/Git-Internals-Packfiles|pack-files], |
| 282 | whereas Fossil stores its objects in a [https://www.sqlite.org/|SQLite] |
| 283 | database file which provides ACID transactions and a high-level query |
| 284 | language. |
| 285 | |
| 286 | This difference is more than an implementation detail; it has important |
| 287 | practical consequences. |
| 288 | |
| 289 | One notable example is that it is difficult to find the descendants |
| 290 | of check-ins in Git. |
| 291 | One can easily locate the ancestors of a particular Git check-in |
| 292 | by following the pointers embedded in the check-in object, but |
| 293 | going the other direction is difficult enough |
| 294 | that neither native Git nor the big "forge" facilities |
| 295 | like GitHub and GitLab provide this capability short of crawling the |
| 296 | [https://www.git-scm.com/docs/git-log|commit log]. In Fossil, |
| 297 | we can find descendants using a simple SQL query, which then allows |
| 298 | us to see [/timeline?df=release&y=ci|all check-ins since the last release], |
| 299 | as but one example. |
| 300 | Git lets you see "what came before," but Fossil makes it just as |
| 301 | easy to also see "what came after." |
| 302 | |
| 303 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 304 | difficult to locate and subject to garbage collection. This |
| 305 | [https://stackoverflow.com/q/3965676 | detached head |
| 306 | state] problem has caused grief for |
| 307 | [https://www.google.com/search?q=git+detached+head+state | |
| 308 | untold millions of Git users]. With |
| 309 | Fossil, detached heads are simply impossible because we can always find |
| 310 | our way back into the Merkle tree using one or more of the relations |
| 311 | in the SQL database. |
| 312 | |
| 313 | The SQL query capabilities of Fossil make it easier to track the |
| @@ -313,34 +314,27 @@ | |
| 314 | changes for one particular file within a project. For example, |
| 315 | you can easily find |
| 316 | [/finfo/www/fossil-v-git.wiki|the complete edit history of this one document], |
| 317 | or even |
| 318 | [/finfo/www/fossil-v-git.wiki?ubg|the same history color-coded by committer], |
| 319 | Both come down to simple SQL queries in Fossil, with procedural code |
| 320 | only being used to format the result for display. |
| 321 | The same result could be obtained from Git, but because the data is |
| 322 | in a key/value store, much more procedural code has to be written to |
| 323 | walk the data and compute the result. |
| 324 | |
| 325 | The ease of querying Fossil data using SQL means that status or |
| 326 | history information about the project under management is easier |
| 327 | to obtain, hence more likely to happen, giving its developers better |
| 328 | situational awareness. |
| 329 | Fossil reports tend to be more detailed and useful. |
| 330 | Compare [/timeline?c=6df7a853ec16865b|this Fossil timeline] |
| 331 | to |
| 332 | [https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34 | |
| 333 | its closest equivalent in the GitHub mirror]. Judge for yourself: which of those |
| 334 | reports is more useful to a developer trying to understand what happened? |
| 335 | |
| 336 | <h3 id="portable">2.4 Portable</h3> |
| 337 | |
| 338 | Fossil is largely written in ISO C, almost purely conforming to the |
| 339 | original 1989 standard. We make very little use of |
| 340 | [https://en.wikipedia.org/wiki/C99|C99], and we do not knowingly make |
| 341 |