Fossil SCM

Clarity pass on the new "Portable" section of fossil-v-git.wiki article.

wyoung 2019-08-08 05:44 trunk
Commit 4b574be4e58dbd509b6c7f73519a356b890f491611ce058afa8d1ea8e877fe4d
Parent e2998923418e6b6…
1 file changed +38 -21
~ www/fossil-v-git.wiki
M www/fossil-v-git.wiki
+38 -21
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -178,11 +178,11 @@
178178
 Fossil, on the other hand, parses essential information about check-ins
179179
 (parents, children, committers, comments, files changed, etc.) into a
180180
 relational database that can be easily queried using concise SQL
181181
 statements to find both ancestors and descendants of a check-in. This is
182182
 the hybrid data model mentioned above: Fossil manages your check-in and
183
-other data in NoSQL block chain structured data store, but that's backed
183
+other data in a NoSQL block chain structured data store, but that's backed
184184
 by a set of relational lookup tables for quick indexing into that
185185
 artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The
186186
 Fossil DVCS]" for more details.)
187187
188188
 Leaf check-ins in Git that lack a "ref" become "detached," making them
@@ -208,13 +208,14 @@
208208
209209
 <h3 id="portable">2.4 Portable</h3>
210210
211211
 Fossil is largely written in ISO C, almost purely conforming to the
212212
 original 1989 standard. We make very little use of
213
-[https://en.wikipedia.org/wiki/C99|C99], and even less of
213
+[https://en.wikipedia.org/wiki/C99|C99], and we do not knowingly make
214
+any use of
214215
 [https://en.wikipedia.org/wiki/C11_(C_standard_revision)|C11]. Fossil
215
-does make use of POSIX and Windows APIs where necessary, but it's about
216
+does call POSIX and Windows APIs where necessary, but it's about
216217
 as portable as you can ask given that ISO C doesn't define all of the
217218
 facilities Fossil needs to do its thing. (Network sockets, file locking,
218219
 etc.) There are certainly well-known platforms Fossil hasn't been ported
219220
 to yet, but that's most likely due to lack of interest rather than
220221
 inherent difficulties in doing the port. We believe the most stringent
@@ -221,29 +222,28 @@
221222
 limit on its portability is that it assumes at least a 32-bit CPU and
222223
 several megs of flat-addressed memory.⁴ Fossil isn't quite as
223224
 [https://www.sqlite.org/custombuild.html|portable as SQLite], but it's
224225
 close.
225226
226
-About half of the code in Fossil is actually an embedded copy of the
227
+Over half of the C code in Fossil is actually an embedded copy of the
227228
 current version of SQLite. Much of what is Fossil-specific after you set
228229
 SQLite itself aside is SQL code calling into SQLite. The number of lines
229230
 of SQL code in Fossil isn't large by percentage, but since SQL is such
230231
 an expressive, declarative language, it has an outsized contribution to
231232
 Fossil's user-visible functionality.
232233
233
-Fossil also makes good use of JavaScript for its web UI, and there's a
234
-fair bit of use of the [https://en.wikipedia.org/wiki/Tcl|Tcl] and
235
-[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md|TH1] scripting
236
-languages. These do not hamper Fossil's portability, since they are also
237
-all quite portable technologies themselves.
238
-
239
-Git is largely portable only to POSIX platforms. About half its code is
240
-POSIX C, and about a third of it is POSIX shell code. There's also
241
-quite a lot of Perl, Tcl, and Python code in Git. Although these
242
-technologies are quite portable within the sphere of POSIX OSes, they're
243
-quite foreign to Windows, which is why the so-called "Git for Windows"
244
-distributions (both [https://git-scm.com/download/win|first-party] and
234
+Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
235
+necessary.⁵ The server-side
236
+UI scripting usse a custom minimal
237
+[https://en.wikipedia.org/wiki/Tcl|Tcl] dialect called
238
+[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md|TH1], which is
239
+embedeed into Fossil itself. Fossil's build system and test suite are
240
+largely based on Tcl.⁶ All of this is quite portable.
241
+
242
+About half of Git's code is POSIX C, and about a third is POSIX shell
243
+code. This is largely why the so-called "Git for Windows" distributions
244
+(both [https://git-scm.com/download/win|first-party] and
245245
 [https://gitforwindows.org/|third-party]) are actually an
246246
 [http://mingw.org/wiki/msys|MSYS POSIX portability environment] bundled
247247
 with all of the Git stuff, because it would be too painful to port Git
248248
 natively to Windows. Git is a foreign citizen on Windows, speaking to it
249249
 only through a translator.
@@ -253,11 +253,12 @@
253253
 — the Windows build of Fossil is truly native.
254254
255255
 The third-party extensions to Git tend to follow this same pattern.
256256
 [http://mingw.org/wiki/msys|GitLab isn't portable to Windows at all],
257257
 for example. For that matter, GitLab isn't even officially supported on
258
-macOS, the BSDs, or uncommon Linuxes!
258
+macOS, the BSDs, or uncommon Linuxes! We have many users who regularly
259
+build and run Fossil on all of these systems.
259260
260261
261262
 <h3 id="vs-linux">2.5 Linux vs. SQLite</h3>
262263
263264
 Fossil and Git promote different development styles because each one was
@@ -333,11 +334,11 @@
333334
 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
334335
 a low-friction path to accepting
335336
 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
336337
 contributions]. Fossil's closest equivalent is its unique
337338
 [/help?cmd=bundle|bundle] feature, which requires higher engagement
338
- than firing off a PR.⁵ This difference comes directly from the
339
+ than firing off a PR.⁷ This difference comes directly from the
339340
 initial designed purpose for each tool: the SQLite project doesn't
340341
 accept outside contributions from previously-unknown developers, but
341342
 the Linux kernel does.</p></li>
342343
343344
 <li><p><b>No rebasing:</b> When your local repo clone syncs changes
@@ -687,13 +688,29 @@
687688
 mid-2019: Fossil will run just fine on the smallest instance they
688689
 offer, at US $5/month, but the closest match to GitLab's minimum
689690
 requirements among Digital Ocean's offerings currently costs
690691
 $40/month.
691692
692
- <li><p>We have yet to hear from someone who has ported Fossil to
693
- [https://en.wikipedia.org/wiki/Z/OS|z/OS], for example, though it
694
- should be quite possible.
693
+ <li><p>This means you can give up waiting for Fossil to be ported to
694
+ the PDP-11, but we remain hopeful that someone may eventually port
695
+ it to [https://en.wikipedia.org/wiki/Z/OS|z/OS].
696
+
697
+ <li><p>We try to keep use of Javascript to a minimum in the web UI,
698
+ and we always try to provide sensible fallbacks for those that run
699
+ their browsers with Javascript disabled. Some features of the web UI
700
+ simply won't run without Javascript, but the UI behavior does
701
+ degrade gracefully.
702
+
703
+ <li><p>"Why is there all this Tcl in and around Fossil?" you may
704
+ ask. It is because D. Richard Hipp is a long-time Tcl user and
705
+ contributor. SQLite started out as an embedded database for Tcl
706
+ specifically. ([https://sqlite.org/tclsqlite.html | [Reference]])
707
+ When he then created Fossil to manage the development of SQLite, it
708
+ was natural for him to use Tcl-based tools for its scripting, build
709
+ system, test system, etc. It came full circle in 2011 when
710
+ [https://www.reddit.com/r/programming/comments/fwrx5/tcl_and_tk_move_away_from_cvs_to_fossil/
711
+ | the Tcl and Tk projects moved from CVS to Fossil].
695712
696713
 <li><p>Both Fossil and Git support
697714
 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
698715
 files], a common way to allow drive-by contributions, but it's a
699716
 lossy contribution path for both systems. Unlike Git PRs and Fossil
700717
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -178,11 +178,11 @@
178 Fossil, on the other hand, parses essential information about check-ins
179 (parents, children, committers, comments, files changed, etc.) into a
180 relational database that can be easily queried using concise SQL
181 statements to find both ancestors and descendants of a check-in. This is
182 the hybrid data model mentioned above: Fossil manages your check-in and
183 other data in NoSQL block chain structured data store, but that's backed
184 by a set of relational lookup tables for quick indexing into that
185 artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The
186 Fossil DVCS]" for more details.)
187
188 Leaf check-ins in Git that lack a "ref" become "detached," making them
@@ -208,13 +208,14 @@
208
209 <h3 id="portable">2.4 Portable</h3>
210
211 Fossil is largely written in ISO C, almost purely conforming to the
212 original 1989 standard. We make very little use of
213 [https://en.wikipedia.org/wiki/C99|C99], and even less of
 
214 [https://en.wikipedia.org/wiki/C11_(C_standard_revision)|C11]. Fossil
215 does make use of POSIX and Windows APIs where necessary, but it's about
216 as portable as you can ask given that ISO C doesn't define all of the
217 facilities Fossil needs to do its thing. (Network sockets, file locking,
218 etc.) There are certainly well-known platforms Fossil hasn't been ported
219 to yet, but that's most likely due to lack of interest rather than
220 inherent difficulties in doing the port. We believe the most stringent
@@ -221,29 +222,28 @@
221 limit on its portability is that it assumes at least a 32-bit CPU and
222 several megs of flat-addressed memory.⁴ Fossil isn't quite as
223 [https://www.sqlite.org/custombuild.html|portable as SQLite], but it's
224 close.
225
226 About half of the code in Fossil is actually an embedded copy of the
227 current version of SQLite. Much of what is Fossil-specific after you set
228 SQLite itself aside is SQL code calling into SQLite. The number of lines
229 of SQL code in Fossil isn't large by percentage, but since SQL is such
230 an expressive, declarative language, it has an outsized contribution to
231 Fossil's user-visible functionality.
232
233 Fossil also makes good use of JavaScript for its web UI, and there's a
234 fair bit of use of the [https://en.wikipedia.org/wiki/Tcl|Tcl] and
235 [https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md|TH1] scripting
236 languages. These do not hamper Fossil's portability, since they are also
237 all quite portable technologies themselves.
238
239 Git is largely portable only to POSIX platforms. About half its code is
240 POSIX C, and about a third of it is POSIX shell code. There's also
241 quite a lot of Perl, Tcl, and Python code in Git. Although these
242 technologies are quite portable within the sphere of POSIX OSes, they're
243 quite foreign to Windows, which is why the so-called "Git for Windows"
244 distributions (both [https://git-scm.com/download/win|first-party] and
245 [https://gitforwindows.org/|third-party]) are actually an
246 [http://mingw.org/wiki/msys|MSYS POSIX portability environment] bundled
247 with all of the Git stuff, because it would be too painful to port Git
248 natively to Windows. Git is a foreign citizen on Windows, speaking to it
249 only through a translator.
@@ -253,11 +253,12 @@
253 — the Windows build of Fossil is truly native.
254
255 The third-party extensions to Git tend to follow this same pattern.
256 [http://mingw.org/wiki/msys|GitLab isn't portable to Windows at all],
257 for example. For that matter, GitLab isn't even officially supported on
258 macOS, the BSDs, or uncommon Linuxes!
 
259
260
261 <h3 id="vs-linux">2.5 Linux vs. SQLite</h3>
262
263 Fossil and Git promote different development styles because each one was
@@ -333,11 +334,11 @@
333 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
334 a low-friction path to accepting
335 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
336 contributions]. Fossil's closest equivalent is its unique
337 [/help?cmd=bundle|bundle] feature, which requires higher engagement
338 than firing off a PR.⁵ This difference comes directly from the
339 initial designed purpose for each tool: the SQLite project doesn't
340 accept outside contributions from previously-unknown developers, but
341 the Linux kernel does.</p></li>
342
343 <li><p><b>No rebasing:</b> When your local repo clone syncs changes
@@ -687,13 +688,29 @@
687 mid-2019: Fossil will run just fine on the smallest instance they
688 offer, at US $5/month, but the closest match to GitLab's minimum
689 requirements among Digital Ocean's offerings currently costs
690 $40/month.
691
692 <li><p>We have yet to hear from someone who has ported Fossil to
693 [https://en.wikipedia.org/wiki/Z/OS|z/OS], for example, though it
694 should be quite possible.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
695
696 <li><p>Both Fossil and Git support
697 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
698 files], a common way to allow drive-by contributions, but it's a
699 lossy contribution path for both systems. Unlike Git PRs and Fossil
700
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -178,11 +178,11 @@
178 Fossil, on the other hand, parses essential information about check-ins
179 (parents, children, committers, comments, files changed, etc.) into a
180 relational database that can be easily queried using concise SQL
181 statements to find both ancestors and descendants of a check-in. This is
182 the hybrid data model mentioned above: Fossil manages your check-in and
183 other data in a NoSQL block chain structured data store, but that's backed
184 by a set of relational lookup tables for quick indexing into that
185 artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The
186 Fossil DVCS]" for more details.)
187
188 Leaf check-ins in Git that lack a "ref" become "detached," making them
@@ -208,13 +208,14 @@
208
209 <h3 id="portable">2.4 Portable</h3>
210
211 Fossil is largely written in ISO C, almost purely conforming to the
212 original 1989 standard. We make very little use of
213 [https://en.wikipedia.org/wiki/C99|C99], and we do not knowingly make
214 any use of
215 [https://en.wikipedia.org/wiki/C11_(C_standard_revision)|C11]. Fossil
216 does call POSIX and Windows APIs where necessary, but it's about
217 as portable as you can ask given that ISO C doesn't define all of the
218 facilities Fossil needs to do its thing. (Network sockets, file locking,
219 etc.) There are certainly well-known platforms Fossil hasn't been ported
220 to yet, but that's most likely due to lack of interest rather than
221 inherent difficulties in doing the port. We believe the most stringent
@@ -221,29 +222,28 @@
222 limit on its portability is that it assumes at least a 32-bit CPU and
223 several megs of flat-addressed memory.⁴ Fossil isn't quite as
224 [https://www.sqlite.org/custombuild.html|portable as SQLite], but it's
225 close.
226
227 Over half of the C code in Fossil is actually an embedded copy of the
228 current version of SQLite. Much of what is Fossil-specific after you set
229 SQLite itself aside is SQL code calling into SQLite. The number of lines
230 of SQL code in Fossil isn't large by percentage, but since SQL is such
231 an expressive, declarative language, it has an outsized contribution to
232 Fossil's user-visible functionality.
233
234 Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
235 necessary.⁵ The server-side
236 UI scripting usse a custom minimal
237 [https://en.wikipedia.org/wiki/Tcl|Tcl] dialect called
238 [https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md|TH1], which is
239 embedeed into Fossil itself. Fossil's build system and test suite are
240 largely based on Tcl.⁶ All of this is quite portable.
241
242 About half of Git's code is POSIX C, and about a third is POSIX shell
243 code. This is largely why the so-called "Git for Windows" distributions
244 (both [https://git-scm.com/download/win|first-party] and
 
245 [https://gitforwindows.org/|third-party]) are actually an
246 [http://mingw.org/wiki/msys|MSYS POSIX portability environment] bundled
247 with all of the Git stuff, because it would be too painful to port Git
248 natively to Windows. Git is a foreign citizen on Windows, speaking to it
249 only through a translator.
@@ -253,11 +253,12 @@
253 — the Windows build of Fossil is truly native.
254
255 The third-party extensions to Git tend to follow this same pattern.
256 [http://mingw.org/wiki/msys|GitLab isn't portable to Windows at all],
257 for example. For that matter, GitLab isn't even officially supported on
258 macOS, the BSDs, or uncommon Linuxes! We have many users who regularly
259 build and run Fossil on all of these systems.
260
261
262 <h3 id="vs-linux">2.5 Linux vs. SQLite</h3>
263
264 Fossil and Git promote different development styles because each one was
@@ -333,11 +334,11 @@
334 [https://www.git-scm.com/docs/git-request-pull|pull requests] offer
335 a low-friction path to accepting
336 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
337 contributions]. Fossil's closest equivalent is its unique
338 [/help?cmd=bundle|bundle] feature, which requires higher engagement
339 than firing off a PR.⁷ This difference comes directly from the
340 initial designed purpose for each tool: the SQLite project doesn't
341 accept outside contributions from previously-unknown developers, but
342 the Linux kernel does.</p></li>
343
344 <li><p><b>No rebasing:</b> When your local repo clone syncs changes
@@ -687,13 +688,29 @@
688 mid-2019: Fossil will run just fine on the smallest instance they
689 offer, at US $5/month, but the closest match to GitLab's minimum
690 requirements among Digital Ocean's offerings currently costs
691 $40/month.
692
693 <li><p>This means you can give up waiting for Fossil to be ported to
694 the PDP-11, but we remain hopeful that someone may eventually port
695 it to [https://en.wikipedia.org/wiki/Z/OS|z/OS].
696
697 <li><p>We try to keep use of Javascript to a minimum in the web UI,
698 and we always try to provide sensible fallbacks for those that run
699 their browsers with Javascript disabled. Some features of the web UI
700 simply won't run without Javascript, but the UI behavior does
701 degrade gracefully.
702
703 <li><p>"Why is there all this Tcl in and around Fossil?" you may
704 ask. It is because D. Richard Hipp is a long-time Tcl user and
705 contributor. SQLite started out as an embedded database for Tcl
706 specifically. ([https://sqlite.org/tclsqlite.html | [Reference]])
707 When he then created Fossil to manage the development of SQLite, it
708 was natural for him to use Tcl-based tools for its scripting, build
709 system, test system, etc. It came full circle in 2011 when
710 [https://www.reddit.com/r/programming/comments/fwrx5/tcl_and_tk_move_away_from_cvs_to_fossil/
711 | the Tcl and Tk projects moved from CVS to Fossil].
712
713 <li><p>Both Fossil and Git support
714 [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt>
715 files], a common way to allow drive-by contributions, but it's a
716 lossy contribution path for both systems. Unlike Git PRs and Fossil
717

Keyboard Shortcuts

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