Fossil SCM

Reworked several sections of the fossil-v-git.wiki doc as sub-sections of "Linux vs. SQLite", which now acts as a frame for those sections. Some of these sections are expanded while others disappear entirely, most especially the "BSD vs GPL" argument that we started off on the now-merged branch to try and refine. We replace a discussion of licensing with one of community structure and our approach to patch acceptance, which is more of what the old licensing discussion was trying to get at without getting into the details of software licensing per se.

wyoung 2019-07-17 02:37 trunk merge
Commit 69ec89b5914a34dd47bdadc8015e29bca5f596570c65ba09df5559422c314f3d
Parent 70a94d09720fc8a…
1 file changed +208 -108
~ www/fossil-v-git.wiki
M www/fossil-v-git.wiki
+208 -108
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -34,21 +34,22 @@
3434
 <tr><td>Ad-hoc pile-of-files key/value database</td>
3535
 <td>Relational SQL database</td></tr>
3636
 <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
3737
 <tr><td>Designed for Linux kernel development</td>
3838
 <td>Designed for SQLite development</td></tr>
39
+<tr><td>Many contributors</td>
40
+ <td>Select contributors</td></tr>
3941
 <tr><td>Focus on individual branches</td>
4042
 <td>Focus on the entire tree of changes</td></tr>
4143
 <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
4244
 <tr><td>One check-out per repository</td>
4345
 <td>Many check-outs per repository</td></tr>
4446
 <tr><td>Remembers what you should have done</td>
4547
 <td>Remembers what you actually did</td></tr>
46
-<tr><td>GPL</td><td>BSD</td></tr>
4748
 </table></blockquote>
4849
49
-<h3>2.1 Feature Set</h3>
50
+<h3 id="features">2.1 Feature Set</h3>
5051
5152
 Git provides file versioning services only, whereas Fossil adds
5253
 integrated [./wikitheory.wiki | wiki],
5354
 [./bugtheory.wiki | ticketing &amp; bug tracking],
5455
 [./embeddeddoc.wiki | embedded documentation],
@@ -72,11 +73,11 @@
7273
 the same using Git requires locating, installing, configuring, integrating,
7374
 and managing a wide assortment of separate tools. Standing up a developer
7475
 website using Fossil can be done in minutes, whereas doing the same using
7576
 Git requires hours or days.
7677
77
-<h3>2.2 Database</h3>
78
+<h3 id="database">2.2 Database</h3>
7879
7980
 The baseline data structures for Fossil and Git are the same, modulo
8081
 formatting details. Both systems store check-ins as immutable
8182
 objects referencing their immediate ancestors and named by a
8283
 cryptographic hash of the check-in content.
@@ -116,74 +117,205 @@
116117
 ([./webpage-ex.md|examples]) that show project state
117118
 in ways that help developers
118119
 maintain enhanced awareness and comprehension
119120
 and avoid errors.
120121
121
-<h3>2.3 Cathedral vs. Bazaar</h3>
122
-
123
-Fossil and Git promote different development styles. Git promotes a
124
-"[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|bazaar]"
125
-development style in which numerous anonymous developers make
126
-small and sometimes haphazard contributions. Fossil
127
-promotes a "cathedral" development model in which the project is
128
-closely supervised by an highly engaged architect and implemented by
129
-a clique of developers.
130
-
131
-Nota Bene: This is not to say that Git cannot be used for cathedral-style
132
-development or that Fossil cannot be used for bazaar-style development.
133
-They can be. But those modes are not their design intent nor their
134
-low-friction path.
135
-
136
-Git encourages a style in which individual developers work in relative
137
-isolation, maintaining their
138
-own branches and occasionally rebasing and pushing selected changes up
139
-to the main repository. Developers using Git often have their own
140
-private branches that nobody else ever sees. Work becomes siloed.
141
-This is exactly what one wants when doing bazaar-style development.
142
-
143
-Fossil, in contrast, strives to keep all changes from all contributors
144
-mirrored in the main repository (in separate branches) at all times.
145
-Work in progress from one developer is readily visible to all other
146
-developers and to the project leader, well before the code is ready
147
-to integrate. Fossil places a lot of emphasis on reporting the state
148
-of the project, and the changes underway by all developers, so that
149
-all developers and especially the project leader can maintain a better
150
-mental picture of what is happening, and better situational awareness.
151
-
152
-<h3>2.4 Linux vs. SQLite</h3>
153
-
154
-Git was specifically designed to support the development of the Linux kernel.
155
-Fossil was specifically designed to support the development of SQLite.
156
-
122
+
123
+<h3 id="vs-linux">2.3 Linux vs. SQLite</h3>
124
+
125
+Fossil and Git promote different development styles because each one was
126
+specifically designed to support the primary authors' main software
127
+development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
128
+Torvalds] designed Git to support development of
129
+[https://www.kernel.org/|the Linux kernel], and
130
+[https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] designed
131
+Fossil to support the development of [https://sqlite.org/|SQLite].
157132
 SQLite is much more widely deployed than the Linux kernel, but for
158133
 Linux-based systems, the kernel is the more fundamental component.
159
-Although both projects must rank high on any objective list of "most
160
-important FOSS projects," the two projects are almost entirely unlike
161
-one another, and this shows up in the design choices of the tools
162
-created to support them.
163
-
164
-The Linux kernel uses a bazaar-style development model. There are thousands and
165
-thousands of contributors, most of whom do not know each others names.
166
-These thousands are responsible for producing roughly 89⨉ more code than
167
-is in SQLite. (10.7
168
-[https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC
169
-according to [https://dwheeler.com/sloccount/|SLOCCount].) Git is
170
-designed for this scenario.
171
-
172
-SQLite uses cathedral-style development. 95% of the code in SQLite
173
-comes from just four programmers, and 64% of it is from the lead developer alone.
174
-The SQLite developers know each other well and interact daily.
175
-Fossil is designed for this development model.
176
-
177
-We think you should ask yourself whether you have
178
-[https://en.wikipedia.org/wiki/Linus_Torvalds|Linus Torvalds] scale
179
-software configuration management problems or
180
-[https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] scale
181
-problems when choosing your DVCS. You don't use a pneumatic ratchet
182
-wrench to hang a picture on the living room wall.
183
-
184
-<h3>2.5 Individual Branches vs. The Entire Change History</h3>
134
+Both projects must rank high on any objective list of "most
135
+important FOSS projects," yet these two projects are almost entirely unlike
136
+one another.
137
+
138
+In the following sections, we will explain how three key differences
139
+between Linux and SQLite dictated the design of each DVCS's low-friction
140
+usage path.
141
+
142
+When deciding between these two DVCSes, you should ask yourself, "Is my
143
+project more like Linux or more like SQLite?"
144
+
145
+
146
+<h4 id="devorg">2.3.1 Development Organization</h4>
147
+
148
+Eric S. Raymond's seminal essay-turned-book
149
+"[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
150
+Cathedral and the Bazaar]" details the two major development
151
+organization styles found in
152
+[https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS]
153
+projects. As it happens, Linux and SQLite fall on opposite sides of this
154
+dichotomy. Differing development organization styles dictate a different
155
+design and low-friction usage path in the tools created to support each
156
+project.
157
+
158
+Git promotes the Linux kernel's bazaar development style, in which a
159
+loosely-associated mass of developers contribute their work through
160
+[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow|a
161
+hierarchy of lieutenants] who manage and clean up these contributions
162
+for consideration by Linus Torvalds, who has the power to cherrypick
163
+individual contributions into his version of the Linux kernel. Git
164
+allows an anonymous developer to rebase and push specific locally-named
165
+private branches, so that a Git repo clone often isn't really a clone at
166
+all: it may have an arbitrary number of differences relative to the
167
+repository it originally cloned from. Git encourages siloed development.
168
+Select work in a developer's local repository may remain private
169
+indefinitely.
170
+
171
+All of this is exactly what one wants when doing bazaar-style
172
+development.
173
+
174
+Fossil's normal mode of operation differs on every one of these points,
175
+with the specific designed-in goal of promoting SQLite's cathedral
176
+development model:
177
+
178
+<ul>
179
+ <li><p><b>Personal engagement:</b> SQLite's developers know each
180
+ other by name and work together daily on the project.</p></li>
181
+
182
+ <li><p><b>Trust over hierarchy:</b> Fossil supports developers given
183
+ direct commit capability on the repository rather than support a
184
+ hierarchical "dictator and lieutenants" contribution style. D.
185
+ Richard Hipp rarely overrides decisions made by those he has trusted
186
+ with commit access on his repositories.
187
+ [/doc/trunk/www/admin-v-setup.md|Some users] have more power over
188
+ what they can do with the repository, but Fossil does not otherwise
189
+ directly support the enforcement of a development organization's
190
+ social hierarchy. Fossil is a great fit for
191
+ [https://en.wikipedia.org/wiki/Flat_organization|flat
192
+ organizations].</p></li>
193
+
194
+ <li><p><b>Anonymous contribution discouraged:</b> Anonymous
195
+ contribution is possible in a Fossil project, but there is no
196
+ low-friction path to it, as in Git. Fossil's closest equivalent to
197
+ Git pull requests is the [/help?cmd=bundle|bundle], which requires
198
+ higher engagement than firing off a PR. Both Fossil and Git also
199
+ support <tt>patch(1)</tt> files, but that's a lossy contribution
200
+ path in both systems.</p></li>
201
+
202
+ <li><p><b>No rebasing:</b> When a remote clone syncs changes up to
203
+ its parent repository, the changes are sent exactly as they were
204
+ committed to the local repository. [#history|There is no rebasing
205
+ mechanism, on purpose.]</p></li>
206
+
207
+ <li><p><b>Sync over push:</b> Explicit pushes are uncommon in
208
+ Fossil-based projects; the default is to rely on
209
+ [/help?cmd=autosync|autosync mode] instead, in which each commit
210
+ normally syncs immediately to its parent repository, so that
211
+ explicit pushes are not needed.</p></li>
212
+
213
+ <li><p><b>Branch names sync:</b> Unlike in Git, branch names are not
214
+ purely local labels. They sync along with everything else, so
215
+ everyone everyone sees the same set of branch names.</p></li>
216
+
217
+ <li><p><b>Private branches are rare:</b>
218
+ [/doc/trunk/www/private.wiki|Private branches exist in Fossil], but
219
+ they're normally used to handle rare exception cases, whereas in
220
+ many Git projects, they're part of the straight-line development
221
+ process.</p></li>
222
+
223
+ <li><p><b>Identical clones:</b> Fossil's autosync system tries to
224
+ keep local clones identical to the repository it cloned
225
+ from.</p></li>
226
+</ul>
227
+
228
+Where Git encourages siloed development, Fossil fights against it.
229
+[https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] put
230
+it well in his book on software project management,
231
+[https://www.amazon.com/dp/0735623198/|Dynamics of Software
232
+Development]: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware of a
233
+guy in a room]." Fossil places a lot of emphasis on synchronizing
234
+everyone's work and on reporting on the state of the project and the
235
+work of its developers, so that everyone — especially the project leader
236
+— can maintain a better mental picture of what is happening, leading to
237
+better situational awareness.
238
+
239
+Each DVCS can be used in the opposite style, but doing so works against
240
+their low-friction paths.
241
+
242
+
243
+<h4 id="scale">2.3.2 Scale</h4>
244
+
245
+The Linux kernel has a far bigger developer community than that of
246
+SQLite: there are thousands and thousands of contributors to Linux, most
247
+of whom do not know each others names. These thousands are responsible
248
+for producing roughly 89⨉ more code than is in SQLite. (10.7
249
+[https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC
250
+according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux
251
+kernel and its development process were already uncommonly large back in
252
+2005 when Git was designed, specifically to support the consequences of
253
+having such a large set of developers working on such a large code base.
254
+
255
+95% of the code in SQLite comes from just four programmers, and 64% of
256
+it is from the lead developer alone. The SQLite developers know each
257
+other well and interact daily. Fossil was designed for this development
258
+model. As well, we think the fact of Fossil's birth a year later
259
+than Git allowed it to learn from some of the key design mistakes in
260
+Git.
261
+
262
+We think you should ask yourself whether you have Linus Torvalds scale
263
+software configuration management problems or D. Richard Hipp scale
264
+problems when choosing your DVCS. An
265
+[https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
266
+wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
267
+not the best way to hang a picture on the living room wall.
268
+
269
+
270
+<h4 id="contrib">2.3.3 Accepting Contributions</h4>
271
+
272
+As of this writing, Git has received about 4.5⨉ as many commits as
273
+Fossil resulting in about 2.5⨉ as many lines of source code. The line
274
+count excludes tests and in-tree third-party dependencies. It does not
275
+exclude the default GUI for each, since it's integral for Fossil, so we
276
+count the size of <tt>gitk</tt> in this.
277
+
278
+It is obvious that Git is bigger in part because of its first-mover
279
+advantage, which resulted in a larger user community, which results in
280
+more contributions. But is that the <i>only</i> reason? We believe there
281
+are other relevant differences that also play into this which fall out
282
+of the "Linux vs. SQLite" framing: licensing, community structure, and
283
+how we react to
284
+[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
285
+contributions]. In brief, it's harder to get a new feature into Fossil
286
+than into Git.
287
+
288
+A larger feature set size is not necessarily a good thing. Git's command line
289
+interface is famously arcane. Masters of the arcane are able to do
290
+wizardly things, but only by studying their art deeply for years. This
291
+strikes us as a good thing only in cases where use of the tool itself is
292
+the primary point of that user's work.
293
+
294
+Most DVCS users are not using a DVCS for its own sake, so we do not want
295
+the DVCS with the most features, we want the one with a more easily
296
+internalized behavior set, which we can pick up, use quickly, and then
297
+set aside in order to get back to our
298
+actual job as quickly as possible. There is some minimal set of features
299
+required to achieve that, but there is a level beyond which more
300
+features only slow us down while we're learning about the DVCS, as we
301
+must plow through documentation on features we're not likely to ever
302
+use. When the number of features grows
303
+to the point where people of normal motivation cannot spend the time to
304
+master them all, you make the tool <i>less</i> productive to use.
305
+
306
+We achieve this balance between feature set size and ease of use by
307
+carefully choosing which users to give commit bits to, then in being
308
+choosy about which of the contributed feature branches to merge down to
309
+trunk.
310
+
311
+The end result is that Fossil more closely adheres to
312
+[https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
313
+principle of least astonishment] than Git does.
314
+
315
+
316
+<h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3>
185317
186318
 Both Fossil and Git store history as a directed acyclic graph (DAG)
187319
 of changes, but Git tends to focus more on individual branches of
188320
 the DAG, whereas Fossil puts more emphasis on the entire DAG.
189321
@@ -207,11 +339,12 @@
207339
 with just a handful of active committers. Seeing all
208340
 changes on all branches all at once helps keep the whole team
209341
 up-to-date with what everybody else is doing, resulting in a more
210342
 tightly focused and cohesive implementation.
211343
212
-<h3>2.6 Lots of little tools vs. Self-contained system</h3>
344
+
345
+<h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3>
213346
214347
 Git consists of many small tools, each doing one small part of the job,
215348
 which can be recombined (by experts) to perform powerful operations.
216349
 Git has a lot of complexity and many dependencies and requires an "installer"
217350
 script or program to get it running.
@@ -225,11 +358,12 @@
225358
 small tools that collaborate to get the job done. The designer of
226359
 Fossil says that the Unix philosophy is "It just works." Both
227360
 individuals have written their DVCSes to reflect their own view
228361
 of the "Unix philosophy."
229362
230
-<h3>2.7 One vs. Many Check-outs per Repository</h3>
363
+
364
+<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
231365
232366
 A "repository" in Git is a pile-of-files in the ".git" subdirectory
233367
 of a single check-out. The check-out and the repository are located
234368
 together in the filesystem.
235369
@@ -256,11 +390,12 @@
256390
 Fossil to have a check-out tree for each major working branch so that
257391
 you can switch branches with a "cd" command rather than replace the
258392
 current working file set with a different file set by updating in place,
259393
 as Git prefers.
260394
261
-<h3>2.8 What you should have done vs. What you actually did</h3>
395
+
396
+<h3 id="history">2.7 What you should have done vs. What you actually did</h3>
262397
263398
 Git puts a lot of emphasis on maintaining
264399
 a "clean" check-in history. Extraneous and experimental branches by
265400
 individual developers often never make it into the main repository. And
266401
 branches are often rebased before being pushed, to make
@@ -277,48 +412,12 @@
277412
 is not a factor.
278413
279414
 One commentator has mused that Git records history according to
280415
 the victors, whereas Fossil records history as it actually happened.
281416
282
-<h3>2.9 GPL vs. BSD</h3>
283
-
284
-Git is covered by the GPL license whereas Fossil is covered by
285
-[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD
286
-style license].
287
-
288
-Consider the difference between GPL and BSD licenses: GPL is designed
289
-to make writing easier at the expense of making reading harder. BSD is
290
-designed to make reading easier at the expense of making writing harder.
291
-
292
-To a first approximation, the GPL license grants the right to read
293
-source code to anyone who promises to give back enhancements. In other
294
-words, the act of reading GPL source code (a prerequiste for making changes)
295
-implies acceptance of the license which requires updates to be contributed
296
-back under the same license. (The details are more complex, but the
297
-foregoing captures the essence of the idea.) A big advantage of the GPL
298
-is that anybody can contribute to the code without having to sign additional
299
-legal documentation because they have implied their acceptance of the GPL
300
-license by the very act of reading the source code. This means that a GPL
301
-project can legally accept anonymous and drive-by patches.
302
-
303
-The BSD licenses, on the other hand, make reading much easier than the GPL,
304
-because the reader need not surrender proprietary interest
305
-in their own enhancements. On the flip side, BSD and similarly licensed
306
-projects must obtain legal affidavits from authors before
307
-new content can be added into the project. Anonymous and drive-by
308
-patches cannot be accepted. This makes signing up new contributors for
309
-BSD licensed projects harder.
310
-
311
-The licenses on the implementations of Git and Fossil only apply to the
312
-implementations themselves, not to the projects which the systems store.
313
-Nevertheless, one can see a more GPL-oriented world-view in Git and a
314
-more BSD-oriented world-view in Fossil. Git encourages anonymous contributions
315
-and siloed development, which are hallmarks of the GPL/bazaar approach to
316
-software, whereas Fossil encourages a more tightly collaborative,
317
-cliquish, cathedral-style approach more typical of BSD-licensed projects.
318
-
319
-<h2>3.0 Missing Features</h2>
417
+
418
+<h2 id="missing">3.0 Missing Features</h2>
320419
321420
 Most of the capabilities found in Git are also available in Fossil and
322421
 the other way around. For example, both systems have local check-outs,
323422
 remote repositories, push/pull/sync, bisect capabilities, and a "stash."
324423
 Both systems store project history as a directed acyclic graph (DAG)
@@ -325,11 +424,12 @@
325424
 of immutable check-in objects.
326425
327426
 But there are a few capabilities in one system that are missing from the
328427
 other.
329428
330
-<h3>3.1 Features found in Fossil but missing from Git</h3>
429
+
430
+<h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3>
331431
332432
 * <b>The ability to show descendents of a check-in.</b>
333433
334434
 Both Git and Fossil can easily find the ancestors of a check-in. But
335435
 only Fossil shows the descendents. (It is possible to find the
@@ -364,11 +464,11 @@
364464
 Fossil supports an integrated web interface. Some of the same features
365465
 are available using third-party add-ons for Git, but they do not provide
366466
 nearly as many features and they are not nearly as convenient to use.
367467
368468
369
-<h3>3.2 Features found in Git but missing from Fossil</h3>
469
+<h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3>
370470
371471
 * <b>Rebase</b>
372472
373473
 Because of its emphasis on recording history exactly as it happened,
374474
 rather than as we would have liked it to happen, Fossil deliberately
375475
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -34,21 +34,22 @@
34 <tr><td>Ad-hoc pile-of-files key/value database</td>
35 <td>Relational SQL database</td></tr>
36 <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
37 <tr><td>Designed for Linux kernel development</td>
38 <td>Designed for SQLite development</td></tr>
 
 
39 <tr><td>Focus on individual branches</td>
40 <td>Focus on the entire tree of changes</td></tr>
41 <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
42 <tr><td>One check-out per repository</td>
43 <td>Many check-outs per repository</td></tr>
44 <tr><td>Remembers what you should have done</td>
45 <td>Remembers what you actually did</td></tr>
46 <tr><td>GPL</td><td>BSD</td></tr>
47 </table></blockquote>
48
49 <h3>2.1 Feature Set</h3>
50
51 Git provides file versioning services only, whereas Fossil adds
52 integrated [./wikitheory.wiki | wiki],
53 [./bugtheory.wiki | ticketing &amp; bug tracking],
54 [./embeddeddoc.wiki | embedded documentation],
@@ -72,11 +73,11 @@
72 the same using Git requires locating, installing, configuring, integrating,
73 and managing a wide assortment of separate tools. Standing up a developer
74 website using Fossil can be done in minutes, whereas doing the same using
75 Git requires hours or days.
76
77 <h3>2.2 Database</h3>
78
79 The baseline data structures for Fossil and Git are the same, modulo
80 formatting details. Both systems store check-ins as immutable
81 objects referencing their immediate ancestors and named by a
82 cryptographic hash of the check-in content.
@@ -116,74 +117,205 @@
116 ([./webpage-ex.md|examples]) that show project state
117 in ways that help developers
118 maintain enhanced awareness and comprehension
119 and avoid errors.
120
121 <h3>2.3 Cathedral vs. Bazaar</h3>
122
123 Fossil and Git promote different development styles. Git promotes a
124 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|bazaar]"
125 development style in which numerous anonymous developers make
126 small and sometimes haphazard contributions. Fossil
127 promotes a "cathedral" development model in which the project is
128 closely supervised by an highly engaged architect and implemented by
129 a clique of developers.
130
131 Nota Bene: This is not to say that Git cannot be used for cathedral-style
132 development or that Fossil cannot be used for bazaar-style development.
133 They can be. But those modes are not their design intent nor their
134 low-friction path.
135
136 Git encourages a style in which individual developers work in relative
137 isolation, maintaining their
138 own branches and occasionally rebasing and pushing selected changes up
139 to the main repository. Developers using Git often have their own
140 private branches that nobody else ever sees. Work becomes siloed.
141 This is exactly what one wants when doing bazaar-style development.
142
143 Fossil, in contrast, strives to keep all changes from all contributors
144 mirrored in the main repository (in separate branches) at all times.
145 Work in progress from one developer is readily visible to all other
146 developers and to the project leader, well before the code is ready
147 to integrate. Fossil places a lot of emphasis on reporting the state
148 of the project, and the changes underway by all developers, so that
149 all developers and especially the project leader can maintain a better
150 mental picture of what is happening, and better situational awareness.
151
152 <h3>2.4 Linux vs. SQLite</h3>
153
154 Git was specifically designed to support the development of the Linux kernel.
155 Fossil was specifically designed to support the development of SQLite.
156
157 SQLite is much more widely deployed than the Linux kernel, but for
158 Linux-based systems, the kernel is the more fundamental component.
159 Although both projects must rank high on any objective list of "most
160 important FOSS projects," the two projects are almost entirely unlike
161 one another, and this shows up in the design choices of the tools
162 created to support them.
163
164 The Linux kernel uses a bazaar-style development model. There are thousands and
165 thousands of contributors, most of whom do not know each others names.
166 These thousands are responsible for producing roughly 89⨉ more code than
167 is in SQLite. (10.7
168 [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC
169 according to [https://dwheeler.com/sloccount/|SLOCCount].) Git is
170 designed for this scenario.
171
172 SQLite uses cathedral-style development. 95% of the code in SQLite
173 comes from just four programmers, and 64% of it is from the lead developer alone.
174 The SQLite developers know each other well and interact daily.
175 Fossil is designed for this development model.
176
177 We think you should ask yourself whether you have
178 [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus Torvalds] scale
179 software configuration management problems or
180 [https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] scale
181 problems when choosing your DVCS. You don't use a pneumatic ratchet
182 wrench to hang a picture on the living room wall.
183
184 <h3>2.5 Individual Branches vs. The Entire Change History</h3>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
185
186 Both Fossil and Git store history as a directed acyclic graph (DAG)
187 of changes, but Git tends to focus more on individual branches of
188 the DAG, whereas Fossil puts more emphasis on the entire DAG.
189
@@ -207,11 +339,12 @@
207 with just a handful of active committers. Seeing all
208 changes on all branches all at once helps keep the whole team
209 up-to-date with what everybody else is doing, resulting in a more
210 tightly focused and cohesive implementation.
211
212 <h3>2.6 Lots of little tools vs. Self-contained system</h3>
 
213
214 Git consists of many small tools, each doing one small part of the job,
215 which can be recombined (by experts) to perform powerful operations.
216 Git has a lot of complexity and many dependencies and requires an "installer"
217 script or program to get it running.
@@ -225,11 +358,12 @@
225 small tools that collaborate to get the job done. The designer of
226 Fossil says that the Unix philosophy is "It just works." Both
227 individuals have written their DVCSes to reflect their own view
228 of the "Unix philosophy."
229
230 <h3>2.7 One vs. Many Check-outs per Repository</h3>
 
231
232 A "repository" in Git is a pile-of-files in the ".git" subdirectory
233 of a single check-out. The check-out and the repository are located
234 together in the filesystem.
235
@@ -256,11 +390,12 @@
256 Fossil to have a check-out tree for each major working branch so that
257 you can switch branches with a "cd" command rather than replace the
258 current working file set with a different file set by updating in place,
259 as Git prefers.
260
261 <h3>2.8 What you should have done vs. What you actually did</h3>
 
262
263 Git puts a lot of emphasis on maintaining
264 a "clean" check-in history. Extraneous and experimental branches by
265 individual developers often never make it into the main repository. And
266 branches are often rebased before being pushed, to make
@@ -277,48 +412,12 @@
277 is not a factor.
278
279 One commentator has mused that Git records history according to
280 the victors, whereas Fossil records history as it actually happened.
281
282 <h3>2.9 GPL vs. BSD</h3>
283
284 Git is covered by the GPL license whereas Fossil is covered by
285 [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD
286 style license].
287
288 Consider the difference between GPL and BSD licenses: GPL is designed
289 to make writing easier at the expense of making reading harder. BSD is
290 designed to make reading easier at the expense of making writing harder.
291
292 To a first approximation, the GPL license grants the right to read
293 source code to anyone who promises to give back enhancements. In other
294 words, the act of reading GPL source code (a prerequiste for making changes)
295 implies acceptance of the license which requires updates to be contributed
296 back under the same license. (The details are more complex, but the
297 foregoing captures the essence of the idea.) A big advantage of the GPL
298 is that anybody can contribute to the code without having to sign additional
299 legal documentation because they have implied their acceptance of the GPL
300 license by the very act of reading the source code. This means that a GPL
301 project can legally accept anonymous and drive-by patches.
302
303 The BSD licenses, on the other hand, make reading much easier than the GPL,
304 because the reader need not surrender proprietary interest
305 in their own enhancements. On the flip side, BSD and similarly licensed
306 projects must obtain legal affidavits from authors before
307 new content can be added into the project. Anonymous and drive-by
308 patches cannot be accepted. This makes signing up new contributors for
309 BSD licensed projects harder.
310
311 The licenses on the implementations of Git and Fossil only apply to the
312 implementations themselves, not to the projects which the systems store.
313 Nevertheless, one can see a more GPL-oriented world-view in Git and a
314 more BSD-oriented world-view in Fossil. Git encourages anonymous contributions
315 and siloed development, which are hallmarks of the GPL/bazaar approach to
316 software, whereas Fossil encourages a more tightly collaborative,
317 cliquish, cathedral-style approach more typical of BSD-licensed projects.
318
319 <h2>3.0 Missing Features</h2>
320
321 Most of the capabilities found in Git are also available in Fossil and
322 the other way around. For example, both systems have local check-outs,
323 remote repositories, push/pull/sync, bisect capabilities, and a "stash."
324 Both systems store project history as a directed acyclic graph (DAG)
@@ -325,11 +424,12 @@
325 of immutable check-in objects.
326
327 But there are a few capabilities in one system that are missing from the
328 other.
329
330 <h3>3.1 Features found in Fossil but missing from Git</h3>
 
331
332 * <b>The ability to show descendents of a check-in.</b>
333
334 Both Git and Fossil can easily find the ancestors of a check-in. But
335 only Fossil shows the descendents. (It is possible to find the
@@ -364,11 +464,11 @@
364 Fossil supports an integrated web interface. Some of the same features
365 are available using third-party add-ons for Git, but they do not provide
366 nearly as many features and they are not nearly as convenient to use.
367
368
369 <h3>3.2 Features found in Git but missing from Fossil</h3>
370
371 * <b>Rebase</b>
372
373 Because of its emphasis on recording history exactly as it happened,
374 rather than as we would have liked it to happen, Fossil deliberately
375
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -34,21 +34,22 @@
34 <tr><td>Ad-hoc pile-of-files key/value database</td>
35 <td>Relational SQL database</td></tr>
36 <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
37 <tr><td>Designed for Linux kernel development</td>
38 <td>Designed for SQLite development</td></tr>
39 <tr><td>Many contributors</td>
40 <td>Select contributors</td></tr>
41 <tr><td>Focus on individual branches</td>
42 <td>Focus on the entire tree of changes</td></tr>
43 <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
44 <tr><td>One check-out per repository</td>
45 <td>Many check-outs per repository</td></tr>
46 <tr><td>Remembers what you should have done</td>
47 <td>Remembers what you actually did</td></tr>
 
48 </table></blockquote>
49
50 <h3 id="features">2.1 Feature Set</h3>
51
52 Git provides file versioning services only, whereas Fossil adds
53 integrated [./wikitheory.wiki | wiki],
54 [./bugtheory.wiki | ticketing &amp; bug tracking],
55 [./embeddeddoc.wiki | embedded documentation],
@@ -72,11 +73,11 @@
73 the same using Git requires locating, installing, configuring, integrating,
74 and managing a wide assortment of separate tools. Standing up a developer
75 website using Fossil can be done in minutes, whereas doing the same using
76 Git requires hours or days.
77
78 <h3 id="database">2.2 Database</h3>
79
80 The baseline data structures for Fossil and Git are the same, modulo
81 formatting details. Both systems store check-ins as immutable
82 objects referencing their immediate ancestors and named by a
83 cryptographic hash of the check-in content.
@@ -116,74 +117,205 @@
117 ([./webpage-ex.md|examples]) that show project state
118 in ways that help developers
119 maintain enhanced awareness and comprehension
120 and avoid errors.
121
122
123 <h3 id="vs-linux">2.3 Linux vs. SQLite</h3>
124
125 Fossil and Git promote different development styles because each one was
126 specifically designed to support the primary authors' main software
127 development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
128 Torvalds] designed Git to support development of
129 [https://www.kernel.org/|the Linux kernel], and
130 [https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] designed
131 Fossil to support the development of [https://sqlite.org/|SQLite].
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
132 SQLite is much more widely deployed than the Linux kernel, but for
133 Linux-based systems, the kernel is the more fundamental component.
134 Both projects must rank high on any objective list of "most
135 important FOSS projects," yet these two projects are almost entirely unlike
136 one another.
137
138 In the following sections, we will explain how three key differences
139 between Linux and SQLite dictated the design of each DVCS's low-friction
140 usage path.
141
142 When deciding between these two DVCSes, you should ask yourself, "Is my
143 project more like Linux or more like SQLite?"
144
145
146 <h4 id="devorg">2.3.1 Development Organization</h4>
147
148 Eric S. Raymond's seminal essay-turned-book
149 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
150 Cathedral and the Bazaar]" details the two major development
151 organization styles found in
152 [https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS]
153 projects. As it happens, Linux and SQLite fall on opposite sides of this
154 dichotomy. Differing development organization styles dictate a different
155 design and low-friction usage path in the tools created to support each
156 project.
157
158 Git promotes the Linux kernel's bazaar development style, in which a
159 loosely-associated mass of developers contribute their work through
160 [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow|a
161 hierarchy of lieutenants] who manage and clean up these contributions
162 for consideration by Linus Torvalds, who has the power to cherrypick
163 individual contributions into his version of the Linux kernel. Git
164 allows an anonymous developer to rebase and push specific locally-named
165 private branches, so that a Git repo clone often isn't really a clone at
166 all: it may have an arbitrary number of differences relative to the
167 repository it originally cloned from. Git encourages siloed development.
168 Select work in a developer's local repository may remain private
169 indefinitely.
170
171 All of this is exactly what one wants when doing bazaar-style
172 development.
173
174 Fossil's normal mode of operation differs on every one of these points,
175 with the specific designed-in goal of promoting SQLite's cathedral
176 development model:
177
178 <ul>
179 <li><p><b>Personal engagement:</b> SQLite's developers know each
180 other by name and work together daily on the project.</p></li>
181
182 <li><p><b>Trust over hierarchy:</b> Fossil supports developers given
183 direct commit capability on the repository rather than support a
184 hierarchical "dictator and lieutenants" contribution style. D.
185 Richard Hipp rarely overrides decisions made by those he has trusted
186 with commit access on his repositories.
187 [/doc/trunk/www/admin-v-setup.md|Some users] have more power over
188 what they can do with the repository, but Fossil does not otherwise
189 directly support the enforcement of a development organization's
190 social hierarchy. Fossil is a great fit for
191 [https://en.wikipedia.org/wiki/Flat_organization|flat
192 organizations].</p></li>
193
194 <li><p><b>Anonymous contribution discouraged:</b> Anonymous
195 contribution is possible in a Fossil project, but there is no
196 low-friction path to it, as in Git. Fossil's closest equivalent to
197 Git pull requests is the [/help?cmd=bundle|bundle], which requires
198 higher engagement than firing off a PR. Both Fossil and Git also
199 support <tt>patch(1)</tt> files, but that's a lossy contribution
200 path in both systems.</p></li>
201
202 <li><p><b>No rebasing:</b> When a remote clone syncs changes up to
203 its parent repository, the changes are sent exactly as they were
204 committed to the local repository. [#history|There is no rebasing
205 mechanism, on purpose.]</p></li>
206
207 <li><p><b>Sync over push:</b> Explicit pushes are uncommon in
208 Fossil-based projects; the default is to rely on
209 [/help?cmd=autosync|autosync mode] instead, in which each commit
210 normally syncs immediately to its parent repository, so that
211 explicit pushes are not needed.</p></li>
212
213 <li><p><b>Branch names sync:</b> Unlike in Git, branch names are not
214 purely local labels. They sync along with everything else, so
215 everyone everyone sees the same set of branch names.</p></li>
216
217 <li><p><b>Private branches are rare:</b>
218 [/doc/trunk/www/private.wiki|Private branches exist in Fossil], but
219 they're normally used to handle rare exception cases, whereas in
220 many Git projects, they're part of the straight-line development
221 process.</p></li>
222
223 <li><p><b>Identical clones:</b> Fossil's autosync system tries to
224 keep local clones identical to the repository it cloned
225 from.</p></li>
226 </ul>
227
228 Where Git encourages siloed development, Fossil fights against it.
229 [https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] put
230 it well in his book on software project management,
231 [https://www.amazon.com/dp/0735623198/|Dynamics of Software
232 Development]: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware of a
233 guy in a room]." Fossil places a lot of emphasis on synchronizing
234 everyone's work and on reporting on the state of the project and the
235 work of its developers, so that everyone — especially the project leader
236 — can maintain a better mental picture of what is happening, leading to
237 better situational awareness.
238
239 Each DVCS can be used in the opposite style, but doing so works against
240 their low-friction paths.
241
242
243 <h4 id="scale">2.3.2 Scale</h4>
244
245 The Linux kernel has a far bigger developer community than that of
246 SQLite: there are thousands and thousands of contributors to Linux, most
247 of whom do not know each others names. These thousands are responsible
248 for producing roughly 89⨉ more code than is in SQLite. (10.7
249 [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC
250 according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux
251 kernel and its development process were already uncommonly large back in
252 2005 when Git was designed, specifically to support the consequences of
253 having such a large set of developers working on such a large code base.
254
255 95% of the code in SQLite comes from just four programmers, and 64% of
256 it is from the lead developer alone. The SQLite developers know each
257 other well and interact daily. Fossil was designed for this development
258 model. As well, we think the fact of Fossil's birth a year later
259 than Git allowed it to learn from some of the key design mistakes in
260 Git.
261
262 We think you should ask yourself whether you have Linus Torvalds scale
263 software configuration management problems or D. Richard Hipp scale
264 problems when choosing your DVCS. An
265 [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
266 wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
267 not the best way to hang a picture on the living room wall.
268
269
270 <h4 id="contrib">2.3.3 Accepting Contributions</h4>
271
272 As of this writing, Git has received about 4.5⨉ as many commits as
273 Fossil resulting in about 2.5⨉ as many lines of source code. The line
274 count excludes tests and in-tree third-party dependencies. It does not
275 exclude the default GUI for each, since it's integral for Fossil, so we
276 count the size of <tt>gitk</tt> in this.
277
278 It is obvious that Git is bigger in part because of its first-mover
279 advantage, which resulted in a larger user community, which results in
280 more contributions. But is that the <i>only</i> reason? We believe there
281 are other relevant differences that also play into this which fall out
282 of the "Linux vs. SQLite" framing: licensing, community structure, and
283 how we react to
284 [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
285 contributions]. In brief, it's harder to get a new feature into Fossil
286 than into Git.
287
288 A larger feature set size is not necessarily a good thing. Git's command line
289 interface is famously arcane. Masters of the arcane are able to do
290 wizardly things, but only by studying their art deeply for years. This
291 strikes us as a good thing only in cases where use of the tool itself is
292 the primary point of that user's work.
293
294 Most DVCS users are not using a DVCS for its own sake, so we do not want
295 the DVCS with the most features, we want the one with a more easily
296 internalized behavior set, which we can pick up, use quickly, and then
297 set aside in order to get back to our
298 actual job as quickly as possible. There is some minimal set of features
299 required to achieve that, but there is a level beyond which more
300 features only slow us down while we're learning about the DVCS, as we
301 must plow through documentation on features we're not likely to ever
302 use. When the number of features grows
303 to the point where people of normal motivation cannot spend the time to
304 master them all, you make the tool <i>less</i> productive to use.
305
306 We achieve this balance between feature set size and ease of use by
307 carefully choosing which users to give commit bits to, then in being
308 choosy about which of the contributed feature branches to merge down to
309 trunk.
310
311 The end result is that Fossil more closely adheres to
312 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
313 principle of least astonishment] than Git does.
314
315
316 <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3>
317
318 Both Fossil and Git store history as a directed acyclic graph (DAG)
319 of changes, but Git tends to focus more on individual branches of
320 the DAG, whereas Fossil puts more emphasis on the entire DAG.
321
@@ -207,11 +339,12 @@
339 with just a handful of active committers. Seeing all
340 changes on all branches all at once helps keep the whole team
341 up-to-date with what everybody else is doing, resulting in a more
342 tightly focused and cohesive implementation.
343
344
345 <h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3>
346
347 Git consists of many small tools, each doing one small part of the job,
348 which can be recombined (by experts) to perform powerful operations.
349 Git has a lot of complexity and many dependencies and requires an "installer"
350 script or program to get it running.
@@ -225,11 +358,12 @@
358 small tools that collaborate to get the job done. The designer of
359 Fossil says that the Unix philosophy is "It just works." Both
360 individuals have written their DVCSes to reflect their own view
361 of the "Unix philosophy."
362
363
364 <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
365
366 A "repository" in Git is a pile-of-files in the ".git" subdirectory
367 of a single check-out. The check-out and the repository are located
368 together in the filesystem.
369
@@ -256,11 +390,12 @@
390 Fossil to have a check-out tree for each major working branch so that
391 you can switch branches with a "cd" command rather than replace the
392 current working file set with a different file set by updating in place,
393 as Git prefers.
394
395
396 <h3 id="history">2.7 What you should have done vs. What you actually did</h3>
397
398 Git puts a lot of emphasis on maintaining
399 a "clean" check-in history. Extraneous and experimental branches by
400 individual developers often never make it into the main repository. And
401 branches are often rebased before being pushed, to make
@@ -277,48 +412,12 @@
412 is not a factor.
413
414 One commentator has mused that Git records history according to
415 the victors, whereas Fossil records history as it actually happened.
416
417
418 <h2 id="missing">3.0 Missing Features</h2>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
419
420 Most of the capabilities found in Git are also available in Fossil and
421 the other way around. For example, both systems have local check-outs,
422 remote repositories, push/pull/sync, bisect capabilities, and a "stash."
423 Both systems store project history as a directed acyclic graph (DAG)
@@ -325,11 +424,12 @@
424 of immutable check-in objects.
425
426 But there are a few capabilities in one system that are missing from the
427 other.
428
429
430 <h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3>
431
432 * <b>The ability to show descendents of a check-in.</b>
433
434 Both Git and Fossil can easily find the ancestors of a check-in. But
435 only Fossil shows the descendents. (It is possible to find the
@@ -364,11 +464,11 @@
464 Fossil supports an integrated web interface. Some of the same features
465 are available using third-party add-ons for Git, but they do not provide
466 nearly as many features and they are not nearly as convenient to use.
467
468
469 <h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3>
470
471 * <b>Rebase</b>
472
473 Because of its emphasis on recording history exactly as it happened,
474 rather than as we would have liked it to happen, Fossil deliberately
475

Keyboard Shortcuts

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