Fossil SCM
Moved the "BSD vs GPL" section up in the fossil-v-git doc and made it a sub-section of a new "Linux vs SQLite" section which has two other sub-sections: "Development Organization," which contains an expanded version of what used to be called "Cathedral vs. Bazaar" and "Scale," which contains what is left of the prior version's "Linux vs. SQLite" section. These are sub-sections of a common parent because they were mutually repetitive, and they're all aspects of the "Linux vs. SQLite" comparison, not separate things at all.
Commit
bab2656d1c92b7e35849296b9238f2e413fcbd3b28b08a861ee2209b5e7c0109
Parent
bd0b86e97d5c883…
1 file changed
+202
-116
+202
-116
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -34,21 +34,22 @@ | ||
| 34 | 34 | <tr><td>Ad-hoc pile-of-files key/value database</td> |
| 35 | 35 | <td>Relational SQL database</td></tr> |
| 36 | 36 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 37 | 37 | <tr><td>Designed for Linux kernel development</td> |
| 38 | 38 | <td>Designed for SQLite development</td></tr> |
| 39 | +<tr><td>GPLv2</td> | |
| 40 | + <td>2-clause BSD + CLA</td></tr> | |
| 39 | 41 | <tr><td>Focus on individual branches</td> |
| 40 | 42 | <td>Focus on the entire tree of changes</td></tr> |
| 41 | 43 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 42 | 44 | <tr><td>One check-out per repository</td> |
| 43 | 45 | <td>Many check-outs per repository</td></tr> |
| 44 | 46 | <tr><td>Remembers what you should have done</td> |
| 45 | 47 | <td>Remembers what you actually did</td></tr> |
| 46 | -<tr><td>GPL</td><td>BSD</td></tr> | |
| 47 | 48 | </table></blockquote> |
| 48 | 49 | |
| 49 | -<h3>2.1 Feature Set</h3> | |
| 50 | +<h3 id="features">2.1 Feature Set</h3> | |
| 50 | 51 | |
| 51 | 52 | Git provides file versioning services only, whereas Fossil adds |
| 52 | 53 | integrated [./wikitheory.wiki | wiki], |
| 53 | 54 | [./bugtheory.wiki | ticketing & bug tracking], |
| 54 | 55 | [./embeddeddoc.wiki | embedded documentation], |
| @@ -72,11 +73,11 @@ | ||
| 72 | 73 | the same using Git requires locating, installing, configuring, integrating, |
| 73 | 74 | and managing a wide assortment of separate tools. Standing up a developer |
| 74 | 75 | website using Fossil can be done in minutes, whereas doing the same using |
| 75 | 76 | Git requires hours or days. |
| 76 | 77 | |
| 77 | -<h3>2.2 Database</h3> | |
| 78 | +<h3 id="database">2.2 Database</h3> | |
| 78 | 79 | |
| 79 | 80 | The baseline data structures for Fossil and Git are the same, modulo |
| 80 | 81 | formatting details. Both systems store check-ins as immutable |
| 81 | 82 | objects referencing their immediate ancestors and named by a |
| 82 | 83 | cryptographic hash of the check-in content. |
| @@ -116,76 +117,203 @@ | ||
| 116 | 117 | ([./webpage-ex.md|examples]) that show project state |
| 117 | 118 | in ways that help developers |
| 118 | 119 | maintain enhanced awareness and comprehension |
| 119 | 120 | and avoid errors. |
| 120 | 121 | |
| 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]. | |
| 157 | 132 | SQLite is much more widely deployed than the Linux kernel, but for |
| 158 | 133 | Linux-based systems, the kernel is the more fundamental component. |
| 159 | 134 | Although both projects must rank high on any objective list of "most |
| 160 | -important [https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] | |
| 161 | -projects," the two projects are almost entirely unlike | |
| 162 | -one another, and this shows up in the design choices of the tools | |
| 163 | -created to support them. | |
| 164 | - | |
| 165 | -The Linux kernel uses a bazaar-style development model. There are thousands and | |
| 166 | -thousands of contributors, most of whom do not know each others names. | |
| 167 | -These thousands are responsible for producing roughly 89⨉ more code than | |
| 168 | -is in SQLite. (10.7 | |
| 135 | +important FOSS projects," the two projects are almost entirely unlike | |
| 136 | +one another. | |
| 137 | + | |
| 138 | +In the following three sections, we will explain the key differences in | |
| 139 | +Linux vs. SQLite which affected the designed-in low-friction usage path | |
| 140 | +for the DVCSes created to support each one's development. | |
| 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 | |
| 169 | 249 | [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC |
| 170 | -according to [https://dwheeler.com/sloccount/|SLOCCount].) Git is | |
| 171 | -designed for this scenario. | |
| 172 | - | |
| 173 | -SQLite uses cathedral-style development. 95% of the code in SQLite | |
| 174 | -comes from just four programmers, and 64% of it is from the lead developer alone. | |
| 175 | -The SQLite developers know each other well and interact daily. | |
| 176 | -Fossil is designed for this development model. | |
| 177 | - | |
| 178 | -We think you should ask yourself whether you have | |
| 179 | -[https://en.wikipedia.org/wiki/Linus_Torvalds|Linus Torvalds] scale | |
| 180 | -software configuration management problems or | |
| 181 | -[https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] scale | |
| 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, so Git was designed specifically with this | |
| 253 | +scenario in mind. | |
| 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. | |
| 259 | + | |
| 260 | +We think you should ask yourself whether you have Linus Torvalds scale | |
| 261 | +software configuration management problems or D. Richard Hipp scale | |
| 182 | 262 | problems when choosing your DVCS. An |
| 183 | -[https://en.wikipedia.org/wiki/Impact_wrench|impact wrench] | |
| 184 | -is not the best tool for hanging a picture on the living room wall. | |
| 263 | +[https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact | |
| 264 | +wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is | |
| 265 | +not the best way to hang a picture on the living room wall. | |
| 266 | + | |
| 267 | + | |
| 268 | +<h4 id="license">2.3.3 License</h4> | |
| 269 | + | |
| 270 | +Git is covered by | |
| 271 | +[https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the | |
| 272 | +GPLv2]. Fossil is covered by | |
| 273 | +[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD | |
| 274 | +style license]. Neither license affects the managed repository contents, | |
| 275 | +and it is not our purpose here to try to persuade you to make the same | |
| 276 | +choice of license that we did. However, we do believe the choice of | |
| 277 | +license affects the way each tool was developed, which may affect your | |
| 278 | +choice of which one to use. | |
| 279 | + | |
| 280 | +The GPL allows a project to do without a | |
| 281 | +[https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor | |
| 282 | +license agreement] (CLA) because by the very act of distributing | |
| 283 | +binaries produced from GPL'd source code, you are bound by the license | |
| 284 | +to also distribute that source code under a compatible license. Some | |
| 285 | +GPL-based projects do require a CLA, but usually only to further | |
| 286 | +commercial interests rather than to maintain the legal integrity of the | |
| 287 | +[https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] | |
| 288 | +project itself. | |
| 289 | + | |
| 290 | +Contrast a BSD-style project, where contributions are not automatically | |
| 291 | +relicensed merely by being distributed along with the preexisting BSD | |
| 292 | +code. Such projects often require a CLA even when there are no corporate | |
| 293 | +interests, to ensure that all contributions are compatibly licensed with | |
| 294 | +the existing body of code. It's a way to add a "no takebacks" clause to | |
| 295 | +the basic BSD license. | |
| 296 | + | |
| 297 | +A CLA makes signing up new contributors harder. It's an extra | |
| 298 | +gatekeeping step, so it discourages low-engagement contributors. The | |
| 299 | +stock GPL requires some of the same relinquishment of rights as Fossil's | |
| 300 | +CLA, and the Git project adds to this | |
| 301 | +[https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an | |
| 302 | +implicit CLA], but contributors agree to both passively. | |
| 303 | +[http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil | |
| 304 | +project's contribution process] requires active steps and processing | |
| 305 | +time: the printing, signing, mailing, reception, and processing of the | |
| 306 | +CLA. | |
| 307 | + | |
| 308 | +We think this additional friction has an upside: it improves contributor | |
| 309 | +community cohesion, because everyone who pushed past that legal friction | |
| 310 | +made an affirmative, active step to get into the community. We think it | |
| 311 | +makes for a better, more carefully-designed, simpler DVCS. | |
| 312 | + | |
| 185 | 313 | |
| 186 | -<h3>2.5 Individual Branches vs. The Entire Change History</h3> | |
| 314 | +<h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> | |
| 187 | 315 | |
| 188 | 316 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 189 | 317 | of changes, but Git tends to focus more on individual branches of |
| 190 | 318 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 191 | 319 | |
| @@ -209,11 +337,12 @@ | ||
| 209 | 337 | with just a handful of active committers. Seeing all |
| 210 | 338 | changes on all branches all at once helps keep the whole team |
| 211 | 339 | up-to-date with what everybody else is doing, resulting in a more |
| 212 | 340 | tightly focused and cohesive implementation. |
| 213 | 341 | |
| 214 | -<h3>2.6 Lots of little tools vs. Self-contained system</h3> | |
| 342 | + | |
| 343 | +<h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3> | |
| 215 | 344 | |
| 216 | 345 | Git consists of many small tools, each doing one small part of the job, |
| 217 | 346 | which can be recombined (by experts) to perform powerful operations. |
| 218 | 347 | Git has a lot of complexity and many dependencies and requires an "installer" |
| 219 | 348 | script or program to get it running. |
| @@ -227,11 +356,12 @@ | ||
| 227 | 356 | small tools that collaborate to get the job done. The designer of |
| 228 | 357 | Fossil says that the Unix philosophy is "It just works." Both |
| 229 | 358 | individuals have written their DVCSes to reflect their own view |
| 230 | 359 | of the "Unix philosophy." |
| 231 | 360 | |
| 232 | -<h3>2.7 One vs. Many Check-outs per Repository</h3> | |
| 361 | + | |
| 362 | +<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> | |
| 233 | 363 | |
| 234 | 364 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 235 | 365 | of a single check-out. The check-out and the repository are located |
| 236 | 366 | together in the filesystem. |
| 237 | 367 | |
| @@ -258,11 +388,12 @@ | ||
| 258 | 388 | Fossil to have a check-out tree for each major working branch so that |
| 259 | 389 | you can switch branches with a "cd" command rather than replace the |
| 260 | 390 | current working file set with a different file set by updating in place, |
| 261 | 391 | as Git prefers. |
| 262 | 392 | |
| 263 | -<h3>2.8 What you should have done vs. What you actually did</h3> | |
| 393 | + | |
| 394 | +<h3 id="history">2.7 What you should have done vs. What you actually did</h3> | |
| 264 | 395 | |
| 265 | 396 | Git puts a lot of emphasis on maintaining |
| 266 | 397 | a "clean" check-in history. Extraneous and experimental branches by |
| 267 | 398 | individual developers often never make it into the main repository. And |
| 268 | 399 | branches are often rebased before being pushed, to make |
| @@ -279,58 +410,12 @@ | ||
| 279 | 410 | is not a factor. |
| 280 | 411 | |
| 281 | 412 | One commentator has mused that Git records history according to |
| 282 | 413 | the victors, whereas Fossil records history as it actually happened. |
| 283 | 414 | |
| 284 | -<h3>2.9 GPL vs. BSD</h3> | |
| 285 | - | |
| 286 | -Git is covered by the GPL license, whereas Fossil is covered by | |
| 287 | -[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD | |
| 288 | -style license]. It is not our purpose here to try to persuade you to make | |
| 289 | -the same choice of license that we did. Neither license affects the | |
| 290 | -managed repository contents. However, we do believe the choice of | |
| 291 | -license affected the design and implementation of these two DVCSes, | |
| 292 | -which may affect your choice when deciding which one you'd rather use. | |
| 293 | - | |
| 294 | -The GPL allows a project to do without a | |
| 295 | -[https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor | |
| 296 | -license agreement] (CLA) because by the very act of distributing | |
| 297 | -binaries, you are bound to also distribute the source under a compatible | |
| 298 | -license. There are GPL-based projects that do require a CLA, but this is | |
| 299 | -usually done to further commercial interests rather than to maintain | |
| 300 | -the legal integrity of the | |
| 301 | -[https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] | |
| 302 | -project itself. | |
| 303 | - | |
| 304 | -Contrast a BSD-style project, where contributions are not automatically | |
| 305 | -relicensed merely by being distributed with the preexisting BSD code. | |
| 306 | -Such projects often require a CLA even when there are no corporate | |
| 307 | -interests, to ensure | |
| 308 | -that all contributions are compatibly licensed with the existing body of | |
| 309 | -code. It's a way to add a "no takebacks" clause to the basic BSD | |
| 310 | -license. | |
| 311 | - | |
| 312 | -A CLA makes signing up new contributors harder. It's an extra | |
| 313 | -gatekeeping step, so it discourages low-engagement contributors. A CLA | |
| 314 | -also drives off those unable to accept the CLA's restrictions on their | |
| 315 | -rights, which are otherwise quite minimal under a BSD-style license. The | |
| 316 | -GPL requires much the same sort of relinquishment of rights without this | |
| 317 | -up-front gatekeeping. | |
| 318 | - | |
| 319 | -We think this additional friction is not an entirely bad thing. We think | |
| 320 | -it improves contributor community cohesion, because everyone who | |
| 321 | -pushed past that legal friction made an affirmative, active step to get | |
| 322 | -into the community. | |
| 323 | - | |
| 324 | -These differences in world-view show up in the design, implementation | |
| 325 | -and use of these two DVCSes. | |
| 326 | -Git encourages anonymous contributions | |
| 327 | -and siloed development, which are hallmarks of the GPL/bazaar approach to | |
| 328 | -software, whereas Fossil encourages a more tightly collaborative | |
| 329 | -cathedral-style approach more typical of BSD-licensed projects. | |
| 330 | - | |
| 331 | -<h2>3.0 Missing Features</h2> | |
| 415 | + | |
| 416 | +<h2 id="missing">3.0 Missing Features</h2> | |
| 332 | 417 | |
| 333 | 418 | Most of the capabilities found in Git are also available in Fossil and |
| 334 | 419 | the other way around. For example, both systems have local check-outs, |
| 335 | 420 | remote repositories, push/pull/sync, bisect capabilities, and a "stash." |
| 336 | 421 | Both systems store project history as a directed acyclic graph (DAG) |
| @@ -337,11 +422,12 @@ | ||
| 337 | 422 | of immutable check-in objects. |
| 338 | 423 | |
| 339 | 424 | But there are a few capabilities in one system that are missing from the |
| 340 | 425 | other. |
| 341 | 426 | |
| 342 | -<h3>3.1 Features found in Fossil but missing from Git</h3> | |
| 427 | + | |
| 428 | +<h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3> | |
| 343 | 429 | |
| 344 | 430 | * <b>The ability to show descendents of a check-in.</b> |
| 345 | 431 | |
| 346 | 432 | Both Git and Fossil can easily find the ancestors of a check-in. But |
| 347 | 433 | only Fossil shows the descendents. (It is possible to find the |
| @@ -376,11 +462,11 @@ | ||
| 376 | 462 | Fossil supports an integrated web interface. Some of the same features |
| 377 | 463 | are available using third-party add-ons for Git, but they do not provide |
| 378 | 464 | nearly as many features and they are not nearly as convenient to use. |
| 379 | 465 | |
| 380 | 466 | |
| 381 | -<h3>3.2 Features found in Git but missing from Fossil</h3> | |
| 467 | +<h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3> | |
| 382 | 468 | |
| 383 | 469 | * <b>Rebase</b> |
| 384 | 470 | |
| 385 | 471 | Because of its emphasis on recording history exactly as it happened, |
| 386 | 472 | rather than as we would have liked it to happen, Fossil deliberately |
| 387 | 473 |
| --- 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 & 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,76 +117,203 @@ | |
| 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 [https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] |
| 161 | projects," the two projects are almost entirely unlike |
| 162 | one another, and this shows up in the design choices of the tools |
| 163 | created to support them. |
| 164 | |
| 165 | The Linux kernel uses a bazaar-style development model. There are thousands and |
| 166 | thousands of contributors, most of whom do not know each others names. |
| 167 | These thousands are responsible for producing roughly 89⨉ more code than |
| 168 | is in SQLite. (10.7 |
| 169 | [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC |
| 170 | according to [https://dwheeler.com/sloccount/|SLOCCount].) Git is |
| 171 | designed for this scenario. |
| 172 | |
| 173 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 174 | comes from just four programmers, and 64% of it is from the lead developer alone. |
| 175 | The SQLite developers know each other well and interact daily. |
| 176 | Fossil is designed for this development model. |
| 177 | |
| 178 | We think you should ask yourself whether you have |
| 179 | [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus Torvalds] scale |
| 180 | software configuration management problems or |
| 181 | [https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] scale |
| 182 | problems when choosing your DVCS. An |
| 183 | [https://en.wikipedia.org/wiki/Impact_wrench|impact wrench] |
| 184 | is not the best tool for hanging a picture on the living room wall. |
| 185 | |
| 186 | <h3>2.5 Individual Branches vs. The Entire Change History</h3> |
| 187 | |
| 188 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 189 | of changes, but Git tends to focus more on individual branches of |
| 190 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 191 | |
| @@ -209,11 +337,12 @@ | |
| 209 | with just a handful of active committers. Seeing all |
| 210 | changes on all branches all at once helps keep the whole team |
| 211 | up-to-date with what everybody else is doing, resulting in a more |
| 212 | tightly focused and cohesive implementation. |
| 213 | |
| 214 | <h3>2.6 Lots of little tools vs. Self-contained system</h3> |
| 215 | |
| 216 | Git consists of many small tools, each doing one small part of the job, |
| 217 | which can be recombined (by experts) to perform powerful operations. |
| 218 | Git has a lot of complexity and many dependencies and requires an "installer" |
| 219 | script or program to get it running. |
| @@ -227,11 +356,12 @@ | |
| 227 | small tools that collaborate to get the job done. The designer of |
| 228 | Fossil says that the Unix philosophy is "It just works." Both |
| 229 | individuals have written their DVCSes to reflect their own view |
| 230 | of the "Unix philosophy." |
| 231 | |
| 232 | <h3>2.7 One vs. Many Check-outs per Repository</h3> |
| 233 | |
| 234 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 235 | of a single check-out. The check-out and the repository are located |
| 236 | together in the filesystem. |
| 237 | |
| @@ -258,11 +388,12 @@ | |
| 258 | Fossil to have a check-out tree for each major working branch so that |
| 259 | you can switch branches with a "cd" command rather than replace the |
| 260 | current working file set with a different file set by updating in place, |
| 261 | as Git prefers. |
| 262 | |
| 263 | <h3>2.8 What you should have done vs. What you actually did</h3> |
| 264 | |
| 265 | Git puts a lot of emphasis on maintaining |
| 266 | a "clean" check-in history. Extraneous and experimental branches by |
| 267 | individual developers often never make it into the main repository. And |
| 268 | branches are often rebased before being pushed, to make |
| @@ -279,58 +410,12 @@ | |
| 279 | is not a factor. |
| 280 | |
| 281 | One commentator has mused that Git records history according to |
| 282 | the victors, whereas Fossil records history as it actually happened. |
| 283 | |
| 284 | <h3>2.9 GPL vs. BSD</h3> |
| 285 | |
| 286 | Git is covered by the GPL license, whereas Fossil is covered by |
| 287 | [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD |
| 288 | style license]. It is not our purpose here to try to persuade you to make |
| 289 | the same choice of license that we did. Neither license affects the |
| 290 | managed repository contents. However, we do believe the choice of |
| 291 | license affected the design and implementation of these two DVCSes, |
| 292 | which may affect your choice when deciding which one you'd rather use. |
| 293 | |
| 294 | The GPL allows a project to do without a |
| 295 | [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor |
| 296 | license agreement] (CLA) because by the very act of distributing |
| 297 | binaries, you are bound to also distribute the source under a compatible |
| 298 | license. There are GPL-based projects that do require a CLA, but this is |
| 299 | usually done to further commercial interests rather than to maintain |
| 300 | the legal integrity of the |
| 301 | [https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] |
| 302 | project itself. |
| 303 | |
| 304 | Contrast a BSD-style project, where contributions are not automatically |
| 305 | relicensed merely by being distributed with the preexisting BSD code. |
| 306 | Such projects often require a CLA even when there are no corporate |
| 307 | interests, to ensure |
| 308 | that all contributions are compatibly licensed with the existing body of |
| 309 | code. It's a way to add a "no takebacks" clause to the basic BSD |
| 310 | license. |
| 311 | |
| 312 | A CLA makes signing up new contributors harder. It's an extra |
| 313 | gatekeeping step, so it discourages low-engagement contributors. A CLA |
| 314 | also drives off those unable to accept the CLA's restrictions on their |
| 315 | rights, which are otherwise quite minimal under a BSD-style license. The |
| 316 | GPL requires much the same sort of relinquishment of rights without this |
| 317 | up-front gatekeeping. |
| 318 | |
| 319 | We think this additional friction is not an entirely bad thing. We think |
| 320 | it improves contributor community cohesion, because everyone who |
| 321 | pushed past that legal friction made an affirmative, active step to get |
| 322 | into the community. |
| 323 | |
| 324 | These differences in world-view show up in the design, implementation |
| 325 | and use of these two DVCSes. |
| 326 | Git encourages anonymous contributions |
| 327 | and siloed development, which are hallmarks of the GPL/bazaar approach to |
| 328 | software, whereas Fossil encourages a more tightly collaborative |
| 329 | cathedral-style approach more typical of BSD-licensed projects. |
| 330 | |
| 331 | <h2>3.0 Missing Features</h2> |
| 332 | |
| 333 | Most of the capabilities found in Git are also available in Fossil and |
| 334 | the other way around. For example, both systems have local check-outs, |
| 335 | remote repositories, push/pull/sync, bisect capabilities, and a "stash." |
| 336 | Both systems store project history as a directed acyclic graph (DAG) |
| @@ -337,11 +422,12 @@ | |
| 337 | of immutable check-in objects. |
| 338 | |
| 339 | But there are a few capabilities in one system that are missing from the |
| 340 | other. |
| 341 | |
| 342 | <h3>3.1 Features found in Fossil but missing from Git</h3> |
| 343 | |
| 344 | * <b>The ability to show descendents of a check-in.</b> |
| 345 | |
| 346 | Both Git and Fossil can easily find the ancestors of a check-in. But |
| 347 | only Fossil shows the descendents. (It is possible to find the |
| @@ -376,11 +462,11 @@ | |
| 376 | Fossil supports an integrated web interface. Some of the same features |
| 377 | are available using third-party add-ons for Git, but they do not provide |
| 378 | nearly as many features and they are not nearly as convenient to use. |
| 379 | |
| 380 | |
| 381 | <h3>3.2 Features found in Git but missing from Fossil</h3> |
| 382 | |
| 383 | * <b>Rebase</b> |
| 384 | |
| 385 | Because of its emphasis on recording history exactly as it happened, |
| 386 | rather than as we would have liked it to happen, Fossil deliberately |
| 387 |
| --- 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>GPLv2</td> |
| 40 | <td>2-clause BSD + CLA</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 & 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,76 +117,203 @@ | |
| 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 | Although both projects must rank high on any objective list of "most |
| 135 | important FOSS projects," the two projects are almost entirely unlike |
| 136 | one another. |
| 137 | |
| 138 | In the following three sections, we will explain the key differences in |
| 139 | Linux vs. SQLite which affected the designed-in low-friction usage path |
| 140 | for the DVCSes created to support each one's development. |
| 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, so Git was designed specifically with this |
| 253 | scenario in mind. |
| 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. |
| 259 | |
| 260 | We think you should ask yourself whether you have Linus Torvalds scale |
| 261 | software configuration management problems or D. Richard Hipp scale |
| 262 | problems when choosing your DVCS. An |
| 263 | [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact |
| 264 | wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is |
| 265 | not the best way to hang a picture on the living room wall. |
| 266 | |
| 267 | |
| 268 | <h4 id="license">2.3.3 License</h4> |
| 269 | |
| 270 | Git is covered by |
| 271 | [https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the |
| 272 | GPLv2]. Fossil is covered by |
| 273 | [https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD |
| 274 | style license]. Neither license affects the managed repository contents, |
| 275 | and it is not our purpose here to try to persuade you to make the same |
| 276 | choice of license that we did. However, we do believe the choice of |
| 277 | license affects the way each tool was developed, which may affect your |
| 278 | choice of which one to use. |
| 279 | |
| 280 | The GPL allows a project to do without a |
| 281 | [https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor |
| 282 | license agreement] (CLA) because by the very act of distributing |
| 283 | binaries produced from GPL'd source code, you are bound by the license |
| 284 | to also distribute that source code under a compatible license. Some |
| 285 | GPL-based projects do require a CLA, but usually only to further |
| 286 | commercial interests rather than to maintain the legal integrity of the |
| 287 | [https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] |
| 288 | project itself. |
| 289 | |
| 290 | Contrast a BSD-style project, where contributions are not automatically |
| 291 | relicensed merely by being distributed along with the preexisting BSD |
| 292 | code. Such projects often require a CLA even when there are no corporate |
| 293 | interests, to ensure that all contributions are compatibly licensed with |
| 294 | the existing body of code. It's a way to add a "no takebacks" clause to |
| 295 | the basic BSD license. |
| 296 | |
| 297 | A CLA makes signing up new contributors harder. It's an extra |
| 298 | gatekeeping step, so it discourages low-engagement contributors. The |
| 299 | stock GPL requires some of the same relinquishment of rights as Fossil's |
| 300 | CLA, and the Git project adds to this |
| 301 | [https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an |
| 302 | implicit CLA], but contributors agree to both passively. |
| 303 | [http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil |
| 304 | project's contribution process] requires active steps and processing |
| 305 | time: the printing, signing, mailing, reception, and processing of the |
| 306 | CLA. |
| 307 | |
| 308 | We think this additional friction has an upside: it improves contributor |
| 309 | community cohesion, because everyone who pushed past that legal friction |
| 310 | made an affirmative, active step to get into the community. We think it |
| 311 | makes for a better, more carefully-designed, simpler DVCS. |
| 312 | |
| 313 | |
| 314 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 315 | |
| 316 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 317 | of changes, but Git tends to focus more on individual branches of |
| 318 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 319 | |
| @@ -209,11 +337,12 @@ | |
| 337 | with just a handful of active committers. Seeing all |
| 338 | changes on all branches all at once helps keep the whole team |
| 339 | up-to-date with what everybody else is doing, resulting in a more |
| 340 | tightly focused and cohesive implementation. |
| 341 | |
| 342 | |
| 343 | <h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3> |
| 344 | |
| 345 | Git consists of many small tools, each doing one small part of the job, |
| 346 | which can be recombined (by experts) to perform powerful operations. |
| 347 | Git has a lot of complexity and many dependencies and requires an "installer" |
| 348 | script or program to get it running. |
| @@ -227,11 +356,12 @@ | |
| 356 | small tools that collaborate to get the job done. The designer of |
| 357 | Fossil says that the Unix philosophy is "It just works." Both |
| 358 | individuals have written their DVCSes to reflect their own view |
| 359 | of the "Unix philosophy." |
| 360 | |
| 361 | |
| 362 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 363 | |
| 364 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 365 | of a single check-out. The check-out and the repository are located |
| 366 | together in the filesystem. |
| 367 | |
| @@ -258,11 +388,12 @@ | |
| 388 | Fossil to have a check-out tree for each major working branch so that |
| 389 | you can switch branches with a "cd" command rather than replace the |
| 390 | current working file set with a different file set by updating in place, |
| 391 | as Git prefers. |
| 392 | |
| 393 | |
| 394 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 395 | |
| 396 | Git puts a lot of emphasis on maintaining |
| 397 | a "clean" check-in history. Extraneous and experimental branches by |
| 398 | individual developers often never make it into the main repository. And |
| 399 | branches are often rebased before being pushed, to make |
| @@ -279,58 +410,12 @@ | |
| 410 | is not a factor. |
| 411 | |
| 412 | One commentator has mused that Git records history according to |
| 413 | the victors, whereas Fossil records history as it actually happened. |
| 414 | |
| 415 | |
| 416 | <h2 id="missing">3.0 Missing Features</h2> |
| 417 | |
| 418 | Most of the capabilities found in Git are also available in Fossil and |
| 419 | the other way around. For example, both systems have local check-outs, |
| 420 | remote repositories, push/pull/sync, bisect capabilities, and a "stash." |
| 421 | Both systems store project history as a directed acyclic graph (DAG) |
| @@ -337,11 +422,12 @@ | |
| 422 | of immutable check-in objects. |
| 423 | |
| 424 | But there are a few capabilities in one system that are missing from the |
| 425 | other. |
| 426 | |
| 427 | |
| 428 | <h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3> |
| 429 | |
| 430 | * <b>The ability to show descendents of a check-in.</b> |
| 431 | |
| 432 | Both Git and Fossil can easily find the ancestors of a check-in. But |
| 433 | only Fossil shows the descendents. (It is possible to find the |
| @@ -376,11 +462,11 @@ | |
| 462 | Fossil supports an integrated web interface. Some of the same features |
| 463 | are available using third-party add-ons for Git, but they do not provide |
| 464 | nearly as many features and they are not nearly as convenient to use. |
| 465 | |
| 466 | |
| 467 | <h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3> |
| 468 | |
| 469 | * <b>Rebase</b> |
| 470 | |
| 471 | Because of its emphasis on recording history exactly as it happened, |
| 472 | rather than as we would have liked it to happen, Fossil deliberately |
| 473 |