Fossil SCM

Added a new section to fossil-v-git.wiki, "2.4 Portable" covering how much more portable Fossil is than Git and its common third-party extensions.

wyoung 2019-08-07 09:45 trunk
Commit 64a33a643ff3ea6d9347352100d7011a18964b848e278eb52e86899678bb3613
Parent 5866461ef0feb19…
1 file changed +75 -24
~ www/fossil-v-git.wiki
M www/fossil-v-git.wiki
+75 -24
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -28,10 +28,11 @@
2828
 [https://en.wikipedia.org/wiki/Role-based_access_control|RBAC]</td></tr>
2929
 <tr><td>Sprawling, incoherent, and inefficient</td>
3030
 <td>Self-contained and efficient</td></tr>
3131
 <tr><td>Ad-hoc pile-of-files key/value database</td>
3232
 <td>Relational SQL database</td></tr>
33
+<tr><td>Portable to POSIX systems only</td><td>Runs just about anywhere</td></tr>
3334
 <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
3435
 <tr><td>Designed for Linux kernel development</td>
3536
 <td>Designed for SQLite development</td></tr>
3637
 <tr><td>Many contributors</td>
3738
 <td>Select contributors</td></tr>
@@ -78,30 +79,24 @@
7879
 history, and so forth.² That means you get a copy of this very article
7980
 and all of its historical versions, plus the same for all of the other
8081
 public content on this site.
8182
8283
83
-<h3 id="efficient" name="effective">2.2 Efficient and Effective</h3>
84
+<h3 id="efficient" name="effective">2.2 Efficient</h3>
8485
8586
 Git is actually a collection of many small tools, each doing one small
8687
 part of the job, which can be recombined (by experts) to perform
8788
 powerful operations. Git has a lot of complexity and many dependencies,
8889
 so that most people end up installing it via some kind of package
8990
 manager, simply because these problems are best delegated to people
9091
 skilled in the creation of binary softare packages.
9192
9293
 Fossil is a single self-contained stand-alone executable with hardly any
93
-dependencies. Fossil can be (and often is) run inside a minimally
94
-configured [https://en.wikipedia.org/wiki/Chroot|chroot jail]. To
95
-install Fossil, one merely puts the executable somewhere in the
96
-<tt>$PATH</tt>.
97
-
98
-This difference is especially stark on Windows: you need to drag along a
99
-Cygwin or MSYS environment to get Git running on Windows due to all of
100
-its third-party dependencies. Installing Fossil on Windows is the same
101
-as installing it on every other OS: download the executable and drop it
102
-in the <tt>%PATH%</tt> somewhere.
94
+dependencies. Fossil can be run inside a minimally configured
95
+[https://en.wikipedia.org/wiki/Chroot|chroot jail], from a Windows
96
+memory stick, off a Raspberry Pi with a tiny SD card, etc. To install
97
+Fossil, one merely puts the executable somewhere in the <tt>$PATH</tt>.
10398
10499
 Some say that Git more closely adheres to the Unix philosophy,
105100
 summarized as "many small tools, loosely joined," but we have many
106101
 examples of other successful Unix software that violates that principle
107102
 to good effect, from Apache to Python to ZFS. We can infer from that
@@ -110,19 +105,19 @@
110105
 matters is effectiveness and efficiency. We believe Fossil achieves
111106
 this.
112107
113108
 Git fails on efficiency once you add to it all of the third-party
114109
 software needed to give it a Fossil-equivalent feature set. Consider
115
-[https://about.gitlab.com/|Gitlab], a third-party extension to Git
116
-wrapping it in many features, making int roughly Fossil-equivalent,
110
+[https://about.gitlab.com/|GitLab], a third-party extension to Git
111
+wrapping it in many features, making it roughly Fossil-equivalent,
117112
 though [https://docs.gitlab.com/ee/install/requirements.html|much more
118113
 resource hungry] and hence more costly to run than the equivalent
119
-Fossil setup. Gitlab's requirements are tolerable when you're dedicating
114
+Fossil setup. GitLab's requirements are tolerable when you're dedicating
120115
 a local rack server or blade to it, since that's about the smallest
121116
 thing you could call a "server" these days, but when you go to host that
122117
 in the cloud, you can expect to pay about 8⨉ as much to comfortably host
123
-Gitlab as for Fossil. This difference is largely due to basic
118
+GitLab as for Fossil. This difference is largely due to basic
124119
 technology choices: Ruby and PostgreSQL vs C and SQLite.
125120
126121
 The Fossil project itself is [./selfhost.wiki|hosted on a very small
127122
 VPS], and we've received many reports on the Fossil forum about people
128123
 successfully hosting Fossil service on bare-bones $5/month VPS hosts,
@@ -173,11 +168,63 @@
173168
 in ways that help developers
174169
 maintain enhanced awareness and comprehension
175170
 and avoid errors.
176171
177172
178
-<h3 id="vs-linux">2.4 Linux vs. SQLite</h3>
173
+<h3 id="portable">2.4 Portable</h3>
174
+
175
+Fossil is largely written in ISO C, almost purely conforming to the
176
+original 1989 standard. We make very little use of
177
+[https://en.wikipedia.org/wiki/C99|C99], and even less of
178
+[https://en.wikipedia.org/wiki/C11_(C_standard_revision)|C11]. Fossil
179
+does make use of POSIX and Windows APIs where necessary, but it's about
180
+as portable as you can ask given that ISO C doesn't define all of the
181
+facilities Fossil needs to do its thing. (Network sockets, file locking,
182
+etc.) There are certainly well-known platforms Fossil hasn't been ported
183
+to yet, but that's most likely due to lack of interest rather than
184
+inherent difficulties in doing the port. We believe the most stringent
185
+limit on its portability is that it assumes at least a 32-bit CPU and
186
+several megs of flat-addressed memory.³ Fossil isn't quite as
187
+[https://www.sqlite.org/custombuild.html|portable as SQLite], but it's
188
+close.
189
+
190
+About half of the code in Fossil is actually an embedded copy of the
191
+current version of SQLite. Much of what is Fossil-specific after you set
192
+SQLite itself aside is SQL code calling into SQLite. The number of lines
193
+of SQL code in Fossil isn't large by percentage, but since SQL is such
194
+an expressive, declarative language, it has an outsized contribution to
195
+Fossil's user-visible functionality.
196
+
197
+Fossil also makes good use of JavaScript for its web UI, and there's a
198
+fair bit of use of the [https://en.wikipedia.org/wiki/Tcl|Tcl] and
199
+[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md|TH1] scripting
200
+languages. These do not hamper Fossil's portability, since they are also
201
+all quite portable technologies themselves.
202
+
203
+Git is largely portable only to POSIX platforms. About half its code is
204
+POSIX C, and about a third of it is POSIX shell code. There's also
205
+quite a lot of Perl, Tcl, and Python code in Git. Although these
206
+technologies are quite portable within the sphere of POSIX OSes, they're
207
+quite foreign to Windows, which is why the so-called "Git for Windows"
208
+distributions (both [https://git-scm.com/download/win|first-party] and
209
+[https://gitforwindows.org/|third-party]) are actually an
210
+[http://mingw.org/wiki/msys|MSYS POSIX portability environment] bundled
211
+with all of the Git stuff, because it would be too painful to port Git
212
+natively to Windows. Git is a foreign citizen on Windows, speaking to it
213
+only through a translator.
214
+
215
+While Fossil does lean toward POSIX norms when given a choice — LF-only
216
+line endings are treated as first-class citizens over CR+LF, for example
217
+— the Windows build of Fossil is truly native.
218
+
219
+The third-party extensions to Git tend to follow this same pattern.
220
+[http://mingw.org/wiki/msys|GitLab isn't portable to Windows at all],
221
+for example. For that matter, GitLab isn't even officially supported on
222
+macOS, the BSDs, or uncommon Linuxes!
223
+
224
+
225
+<h3 id="vs-linux">2.5 Linux vs. SQLite</h3>
179226
180227
 Fossil and Git promote different development styles because each one was
181228
 specifically designed to support the creator's main software
182229
 development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
183230
 Torvalds] designed Git to support development of
@@ -194,11 +241,11 @@
194241
195242
 When deciding between these two DVCSes, you should ask yourself, "Is my
196243
 project more like Linux or more like SQLite?"
197244
198245
199
-<h4 id="devorg">2.4.1 Development Organization</h4>
246
+<h4 id="devorg">2.5.1 Development Organization</h4>
200247
201248
 Eric S. Raymond's seminal essay-turned-book
202249
 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
203250
 Cathedral and the Bazaar]" details the two major development
204251
 organization styles found in
@@ -250,11 +297,11 @@
250297
 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
251298
 a low-friction path to accepting
252299
 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
253300
 contributions]. Fossil's closest equivalent is its unique
254301
 [/help?cmd=bundle|bundle] feature, which requires higher engagement
255
- than firing off a PR.³ This difference comes directly from the
302
+ than firing off a PR.⁴ This difference comes directly from the
256303
 initial designed purpose for each tool: the SQLite project doesn't
257304
 accept outside contributions from previously-unknown developers, but
258305
 the Linux kernel does.</p></li>
259306
260307
 <li><p><b>No rebasing:</b> When your local repo clone syncs changes
@@ -310,11 +357,11 @@
310357
311358
 Each DVCS can be used in the opposite style, but doing so works against
312359
 their low-friction paths.
313360
314361
315
-<h4 id="scale">2.4.2 Scale</h4>
362
+<h4 id="scale">2.5.2 Scale</h4>
316363
317364
 The Linux kernel has a far bigger developer community than that of
318365
 SQLite: there are thousands and thousands of contributors to Linux, most
319366
 of whom do not know each others names. These thousands are responsible
320367
 for producing roughly 89⨉ more code than is in SQLite. (10.7
@@ -337,11 +384,11 @@
337384
 [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
338385
 wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
339386
 not the best way to hang a picture on the living room wall.
340387
341388
342
-<h4 id="contrib">2.4.3 Accepting Contributions</h4>
389
+<h4 id="contrib">2.5.3 Accepting Contributions</h4>
343390
344391
 As of this writing, Git has received about 4.5⨉ as many commits as
345392
 Fossil resulting in about 2.5⨉ as many lines of source code. The line
346393
 count excludes tests and in-tree third-party dependencies. It does not
347394
 exclude the default GUI for each, since it's integral for Fossil, so we
@@ -383,11 +430,11 @@
383430
 The end result is that Fossil more closely adheres to
384431
 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
385432
 principle of least astonishment] than Git does.
386433
387434
388
-<h4 id="branches">2.4.4 Individual Branches vs. The Entire Change History</h4>
435
+<h4 id="branches">2.5.4 Individual Branches vs. The Entire Change History</h4>
389436
390437
 Both Fossil and Git store history as a directed acyclic graph (DAG)
391438
 of changes, but Git tends to focus more on individual branches of
392439
 the DAG, whereas Fossil puts more emphasis on the entire DAG.
393440
@@ -412,11 +459,11 @@
412459
 changes on all branches all at once helps keep the whole team
413460
 up-to-date with what everybody else is doing, resulting in a more
414461
 tightly focused and cohesive implementation.
415462
416463
417
-<h3 id="checkouts">2.5 One vs. Many Check-outs per Repository</h3>
464
+<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
418465
419466
 A "repository" in Git is a pile-of-files in the ".git" subdirectory
420467
 of a single check-out. The check-out and the repository are located
421468
 together in the filesystem.
422469
@@ -444,11 +491,11 @@
444491
 you can switch branches with a "cd" command rather than replace the
445492
 current working file set with a different file set by updating in place,
446493
 as Git prefers.
447494
448495
449
-<h3 id="history">2.6 What you should have done vs. What you actually did</h3>
496
+<h3 id="history">2.7 What you should have done vs. What you actually did</h3>
450497
451498
 Git puts a lot of emphasis on maintaining
452499
 a "clean" check-in history. Extraneous and experimental branches by
453500
 individual developers often never make it into the main repository. And
454501
 branches are often rebased before being pushed, to make
@@ -475,11 +522,11 @@
475522
476523
 One commentator characterized Git as recording history according to
477524
 the victors, whereas Fossil records history as it actually happened.
478525
479526
480
-<h3 id="hash">2.7 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3>
527
+<h3 id="hash">2.8 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3>
481528
482529
 Fossil started out using 160-bit SHA-1 hashes to identify check-ins,
483530
 just as in Git. That changed in early 2017 when news of the
484531
 [https://shattered.io/|SHAttered attack] broke, demonstrating that SHA-1
485532
 collisions were now practical to create. Two weeks later, the creator of
@@ -609,10 +656,14 @@
609656
 static elements of the web site served via D. Richard Hipp's own
610657
 lightweight web server,
611658
 <tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md|althttpd]</tt>,
612659
 which is configured as a front end to Fossil running in CGI mode on
613660
 these sites.
661
+
662
+ <li><p>We have yet to hear from someone who has ported Fossil to
663
+ [https://en.wikipedia.org/wiki/Z/OS|z/OS], for example, though it
664
+ should be quite possible.
614665
615666
 <li><p>Both Fossil and Git support
616667
 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
617668
 files], a common way to allow drive-by contributions, but it's a
618669
 lossy contribution path for both systems. Unlike Git PRs and Fossil
619670
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -28,10 +28,11 @@
28 [https://en.wikipedia.org/wiki/Role-based_access_control|RBAC]</td></tr>
29 <tr><td>Sprawling, incoherent, and inefficient</td>
30 <td>Self-contained and efficient</td></tr>
31 <tr><td>Ad-hoc pile-of-files key/value database</td>
32 <td>Relational SQL database</td></tr>
 
33 <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
34 <tr><td>Designed for Linux kernel development</td>
35 <td>Designed for SQLite development</td></tr>
36 <tr><td>Many contributors</td>
37 <td>Select contributors</td></tr>
@@ -78,30 +79,24 @@
78 history, and so forth.² That means you get a copy of this very article
79 and all of its historical versions, plus the same for all of the other
80 public content on this site.
81
82
83 <h3 id="efficient" name="effective">2.2 Efficient and Effective</h3>
84
85 Git is actually a collection of many small tools, each doing one small
86 part of the job, which can be recombined (by experts) to perform
87 powerful operations. Git has a lot of complexity and many dependencies,
88 so that most people end up installing it via some kind of package
89 manager, simply because these problems are best delegated to people
90 skilled in the creation of binary softare packages.
91
92 Fossil is a single self-contained stand-alone executable with hardly any
93 dependencies. Fossil can be (and often is) run inside a minimally
94 configured [https://en.wikipedia.org/wiki/Chroot|chroot jail]. To
95 install Fossil, one merely puts the executable somewhere in the
96 <tt>$PATH</tt>.
97
98 This difference is especially stark on Windows: you need to drag along a
99 Cygwin or MSYS environment to get Git running on Windows due to all of
100 its third-party dependencies. Installing Fossil on Windows is the same
101 as installing it on every other OS: download the executable and drop it
102 in the <tt>%PATH%</tt> somewhere.
103
104 Some say that Git more closely adheres to the Unix philosophy,
105 summarized as "many small tools, loosely joined," but we have many
106 examples of other successful Unix software that violates that principle
107 to good effect, from Apache to Python to ZFS. We can infer from that
@@ -110,19 +105,19 @@
110 matters is effectiveness and efficiency. We believe Fossil achieves
111 this.
112
113 Git fails on efficiency once you add to it all of the third-party
114 software needed to give it a Fossil-equivalent feature set. Consider
115 [https://about.gitlab.com/|Gitlab], a third-party extension to Git
116 wrapping it in many features, making int roughly Fossil-equivalent,
117 though [https://docs.gitlab.com/ee/install/requirements.html|much more
118 resource hungry] and hence more costly to run than the equivalent
119 Fossil setup. Gitlab's requirements are tolerable when you're dedicating
120 a local rack server or blade to it, since that's about the smallest
121 thing you could call a "server" these days, but when you go to host that
122 in the cloud, you can expect to pay about 8⨉ as much to comfortably host
123 Gitlab as for Fossil. This difference is largely due to basic
124 technology choices: Ruby and PostgreSQL vs C and SQLite.
125
126 The Fossil project itself is [./selfhost.wiki|hosted on a very small
127 VPS], and we've received many reports on the Fossil forum about people
128 successfully hosting Fossil service on bare-bones $5/month VPS hosts,
@@ -173,11 +168,63 @@
173 in ways that help developers
174 maintain enhanced awareness and comprehension
175 and avoid errors.
176
177
178 <h3 id="vs-linux">2.4 Linux vs. SQLite</h3>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
179
180 Fossil and Git promote different development styles because each one was
181 specifically designed to support the creator's main software
182 development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
183 Torvalds] designed Git to support development of
@@ -194,11 +241,11 @@
194
195 When deciding between these two DVCSes, you should ask yourself, "Is my
196 project more like Linux or more like SQLite?"
197
198
199 <h4 id="devorg">2.4.1 Development Organization</h4>
200
201 Eric S. Raymond's seminal essay-turned-book
202 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
203 Cathedral and the Bazaar]" details the two major development
204 organization styles found in
@@ -250,11 +297,11 @@
250 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
251 a low-friction path to accepting
252 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
253 contributions]. Fossil's closest equivalent is its unique
254 [/help?cmd=bundle|bundle] feature, which requires higher engagement
255 than firing off a PR.³ This difference comes directly from the
256 initial designed purpose for each tool: the SQLite project doesn't
257 accept outside contributions from previously-unknown developers, but
258 the Linux kernel does.</p></li>
259
260 <li><p><b>No rebasing:</b> When your local repo clone syncs changes
@@ -310,11 +357,11 @@
310
311 Each DVCS can be used in the opposite style, but doing so works against
312 their low-friction paths.
313
314
315 <h4 id="scale">2.4.2 Scale</h4>
316
317 The Linux kernel has a far bigger developer community than that of
318 SQLite: there are thousands and thousands of contributors to Linux, most
319 of whom do not know each others names. These thousands are responsible
320 for producing roughly 89⨉ more code than is in SQLite. (10.7
@@ -337,11 +384,11 @@
337 [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
338 wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
339 not the best way to hang a picture on the living room wall.
340
341
342 <h4 id="contrib">2.4.3 Accepting Contributions</h4>
343
344 As of this writing, Git has received about 4.5⨉ as many commits as
345 Fossil resulting in about 2.5⨉ as many lines of source code. The line
346 count excludes tests and in-tree third-party dependencies. It does not
347 exclude the default GUI for each, since it's integral for Fossil, so we
@@ -383,11 +430,11 @@
383 The end result is that Fossil more closely adheres to
384 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
385 principle of least astonishment] than Git does.
386
387
388 <h4 id="branches">2.4.4 Individual Branches vs. The Entire Change History</h4>
389
390 Both Fossil and Git store history as a directed acyclic graph (DAG)
391 of changes, but Git tends to focus more on individual branches of
392 the DAG, whereas Fossil puts more emphasis on the entire DAG.
393
@@ -412,11 +459,11 @@
412 changes on all branches all at once helps keep the whole team
413 up-to-date with what everybody else is doing, resulting in a more
414 tightly focused and cohesive implementation.
415
416
417 <h3 id="checkouts">2.5 One vs. Many Check-outs per Repository</h3>
418
419 A "repository" in Git is a pile-of-files in the ".git" subdirectory
420 of a single check-out. The check-out and the repository are located
421 together in the filesystem.
422
@@ -444,11 +491,11 @@
444 you can switch branches with a "cd" command rather than replace the
445 current working file set with a different file set by updating in place,
446 as Git prefers.
447
448
449 <h3 id="history">2.6 What you should have done vs. What you actually did</h3>
450
451 Git puts a lot of emphasis on maintaining
452 a "clean" check-in history. Extraneous and experimental branches by
453 individual developers often never make it into the main repository. And
454 branches are often rebased before being pushed, to make
@@ -475,11 +522,11 @@
475
476 One commentator characterized Git as recording history according to
477 the victors, whereas Fossil records history as it actually happened.
478
479
480 <h3 id="hash">2.7 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3>
481
482 Fossil started out using 160-bit SHA-1 hashes to identify check-ins,
483 just as in Git. That changed in early 2017 when news of the
484 [https://shattered.io/|SHAttered attack] broke, demonstrating that SHA-1
485 collisions were now practical to create. Two weeks later, the creator of
@@ -609,10 +656,14 @@
609 static elements of the web site served via D. Richard Hipp's own
610 lightweight web server,
611 <tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md|althttpd]</tt>,
612 which is configured as a front end to Fossil running in CGI mode on
613 these sites.
 
 
 
 
614
615 <li><p>Both Fossil and Git support
616 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
617 files], a common way to allow drive-by contributions, but it's a
618 lossy contribution path for both systems. Unlike Git PRs and Fossil
619
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -28,10 +28,11 @@
28 [https://en.wikipedia.org/wiki/Role-based_access_control|RBAC]</td></tr>
29 <tr><td>Sprawling, incoherent, and inefficient</td>
30 <td>Self-contained and efficient</td></tr>
31 <tr><td>Ad-hoc pile-of-files key/value database</td>
32 <td>Relational SQL database</td></tr>
33 <tr><td>Portable to POSIX systems only</td><td>Runs just about anywhere</td></tr>
34 <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
35 <tr><td>Designed for Linux kernel development</td>
36 <td>Designed for SQLite development</td></tr>
37 <tr><td>Many contributors</td>
38 <td>Select contributors</td></tr>
@@ -78,30 +79,24 @@
79 history, and so forth.² That means you get a copy of this very article
80 and all of its historical versions, plus the same for all of the other
81 public content on this site.
82
83
84 <h3 id="efficient" name="effective">2.2 Efficient</h3>
85
86 Git is actually a collection of many small tools, each doing one small
87 part of the job, which can be recombined (by experts) to perform
88 powerful operations. Git has a lot of complexity and many dependencies,
89 so that most people end up installing it via some kind of package
90 manager, simply because these problems are best delegated to people
91 skilled in the creation of binary softare packages.
92
93 Fossil is a single self-contained stand-alone executable with hardly any
94 dependencies. Fossil can be run inside a minimally configured
95 [https://en.wikipedia.org/wiki/Chroot|chroot jail], from a Windows
96 memory stick, off a Raspberry Pi with a tiny SD card, etc. To install
97 Fossil, one merely puts the executable somewhere in the <tt>$PATH</tt>.
 
 
 
 
 
 
98
99 Some say that Git more closely adheres to the Unix philosophy,
100 summarized as "many small tools, loosely joined," but we have many
101 examples of other successful Unix software that violates that principle
102 to good effect, from Apache to Python to ZFS. We can infer from that
@@ -110,19 +105,19 @@
105 matters is effectiveness and efficiency. We believe Fossil achieves
106 this.
107
108 Git fails on efficiency once you add to it all of the third-party
109 software needed to give it a Fossil-equivalent feature set. Consider
110 [https://about.gitlab.com/|GitLab], a third-party extension to Git
111 wrapping it in many features, making it roughly Fossil-equivalent,
112 though [https://docs.gitlab.com/ee/install/requirements.html|much more
113 resource hungry] and hence more costly to run than the equivalent
114 Fossil setup. GitLab's requirements are tolerable when you're dedicating
115 a local rack server or blade to it, since that's about the smallest
116 thing you could call a "server" these days, but when you go to host that
117 in the cloud, you can expect to pay about 8⨉ as much to comfortably host
118 GitLab as for Fossil. This difference is largely due to basic
119 technology choices: Ruby and PostgreSQL vs C and SQLite.
120
121 The Fossil project itself is [./selfhost.wiki|hosted on a very small
122 VPS], and we've received many reports on the Fossil forum about people
123 successfully hosting Fossil service on bare-bones $5/month VPS hosts,
@@ -173,11 +168,63 @@
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
176 original 1989 standard. We make very little use of
177 [https://en.wikipedia.org/wiki/C99|C99], and even less of
178 [https://en.wikipedia.org/wiki/C11_(C_standard_revision)|C11]. Fossil
179 does make use of POSIX and Windows APIs where necessary, but it's about
180 as portable as you can ask given that ISO C doesn't define all of the
181 facilities Fossil needs to do its thing. (Network sockets, file locking,
182 etc.) There are certainly well-known platforms Fossil hasn't been ported
183 to yet, but that's most likely due to lack of interest rather than
184 inherent difficulties in doing the port. We believe the most stringent
185 limit on its portability is that it assumes at least a 32-bit CPU and
186 several megs of flat-addressed memory.³ Fossil isn't quite as
187 [https://www.sqlite.org/custombuild.html|portable as SQLite], but it's
188 close.
189
190 About half of the code in Fossil is actually an embedded copy of the
191 current version of SQLite. Much of what is Fossil-specific after you set
192 SQLite itself aside is SQL code calling into SQLite. The number of lines
193 of SQL code in Fossil isn't large by percentage, but since SQL is such
194 an expressive, declarative language, it has an outsized contribution to
195 Fossil's user-visible functionality.
196
197 Fossil also makes good use of JavaScript for its web UI, and there's a
198 fair bit of use of the [https://en.wikipedia.org/wiki/Tcl|Tcl] and
199 [https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md|TH1] scripting
200 languages. These do not hamper Fossil's portability, since they are also
201 all quite portable technologies themselves.
202
203 Git is largely portable only to POSIX platforms. About half its code is
204 POSIX C, and about a third of it is POSIX shell code. There's also
205 quite a lot of Perl, Tcl, and Python code in Git. Although these
206 technologies are quite portable within the sphere of POSIX OSes, they're
207 quite foreign to Windows, which is why the so-called "Git for Windows"
208 distributions (both [https://git-scm.com/download/win|first-party] and
209 [https://gitforwindows.org/|third-party]) are actually an
210 [http://mingw.org/wiki/msys|MSYS POSIX portability environment] bundled
211 with all of the Git stuff, because it would be too painful to port Git
212 natively to Windows. Git is a foreign citizen on Windows, speaking to it
213 only through a translator.
214
215 While Fossil does lean toward POSIX norms when given a choice — LF-only
216 line endings are treated as first-class citizens over CR+LF, for example
217 — the Windows build of Fossil is truly native.
218
219 The third-party extensions to Git tend to follow this same pattern.
220 [http://mingw.org/wiki/msys|GitLab isn't portable to Windows at all],
221 for example. For that matter, GitLab isn't even officially supported on
222 macOS, the BSDs, or uncommon Linuxes!
223
224
225 <h3 id="vs-linux">2.5 Linux vs. SQLite</h3>
226
227 Fossil and Git promote different development styles because each one was
228 specifically designed to support the creator's main software
229 development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
230 Torvalds] designed Git to support development of
@@ -194,11 +241,11 @@
241
242 When deciding between these two DVCSes, you should ask yourself, "Is my
243 project more like Linux or more like SQLite?"
244
245
246 <h4 id="devorg">2.5.1 Development Organization</h4>
247
248 Eric S. Raymond's seminal essay-turned-book
249 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
250 Cathedral and the Bazaar]" details the two major development
251 organization styles found in
@@ -250,11 +297,11 @@
297 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
298 a low-friction path to accepting
299 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
300 contributions]. Fossil's closest equivalent is its unique
301 [/help?cmd=bundle|bundle] feature, which requires higher engagement
302 than firing off a PR.⁴ This difference comes directly from the
303 initial designed purpose for each tool: the SQLite project doesn't
304 accept outside contributions from previously-unknown developers, but
305 the Linux kernel does.</p></li>
306
307 <li><p><b>No rebasing:</b> When your local repo clone syncs changes
@@ -310,11 +357,11 @@
357
358 Each DVCS can be used in the opposite style, but doing so works against
359 their low-friction paths.
360
361
362 <h4 id="scale">2.5.2 Scale</h4>
363
364 The Linux kernel has a far bigger developer community than that of
365 SQLite: there are thousands and thousands of contributors to Linux, most
366 of whom do not know each others names. These thousands are responsible
367 for producing roughly 89⨉ more code than is in SQLite. (10.7
@@ -337,11 +384,11 @@
384 [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
385 wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
386 not the best way to hang a picture on the living room wall.
387
388
389 <h4 id="contrib">2.5.3 Accepting Contributions</h4>
390
391 As of this writing, Git has received about 4.5⨉ as many commits as
392 Fossil resulting in about 2.5⨉ as many lines of source code. The line
393 count excludes tests and in-tree third-party dependencies. It does not
394 exclude the default GUI for each, since it's integral for Fossil, so we
@@ -383,11 +430,11 @@
430 The end result is that Fossil more closely adheres to
431 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
432 principle of least astonishment] than Git does.
433
434
435 <h4 id="branches">2.5.4 Individual Branches vs. The Entire Change History</h4>
436
437 Both Fossil and Git store history as a directed acyclic graph (DAG)
438 of changes, but Git tends to focus more on individual branches of
439 the DAG, whereas Fossil puts more emphasis on the entire DAG.
440
@@ -412,11 +459,11 @@
459 changes on all branches all at once helps keep the whole team
460 up-to-date with what everybody else is doing, resulting in a more
461 tightly focused and cohesive implementation.
462
463
464 <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
465
466 A "repository" in Git is a pile-of-files in the ".git" subdirectory
467 of a single check-out. The check-out and the repository are located
468 together in the filesystem.
469
@@ -444,11 +491,11 @@
491 you can switch branches with a "cd" command rather than replace the
492 current working file set with a different file set by updating in place,
493 as Git prefers.
494
495
496 <h3 id="history">2.7 What you should have done vs. What you actually did</h3>
497
498 Git puts a lot of emphasis on maintaining
499 a "clean" check-in history. Extraneous and experimental branches by
500 individual developers often never make it into the main repository. And
501 branches are often rebased before being pushed, to make
@@ -475,11 +522,11 @@
522
523 One commentator characterized Git as recording history according to
524 the victors, whereas Fossil records history as it actually happened.
525
526
527 <h3 id="hash">2.8 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3>
528
529 Fossil started out using 160-bit SHA-1 hashes to identify check-ins,
530 just as in Git. That changed in early 2017 when news of the
531 [https://shattered.io/|SHAttered attack] broke, demonstrating that SHA-1
532 collisions were now practical to create. Two weeks later, the creator of
@@ -609,10 +656,14 @@
656 static elements of the web site served via D. Richard Hipp's own
657 lightweight web server,
658 <tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md|althttpd]</tt>,
659 which is configured as a front end to Fossil running in CGI mode on
660 these sites.
661
662 <li><p>We have yet to hear from someone who has ported Fossil to
663 [https://en.wikipedia.org/wiki/Z/OS|z/OS], for example, though it
664 should be quite possible.
665
666 <li><p>Both Fossil and Git support
667 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
668 files], a common way to allow drive-by contributions, but it's a
669 lossy contribution path for both systems. Unlike Git PRs and Fossil
670

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button