Fossil

<tr><td>File versioning only</td>
    <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr>
<tr><td>Ad-hoc pile-of-files key/value database</td>
    <td>Relational SQL database</td></tr>
<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
<tr><td>Designed for Linux kernel development</td>
    <td>Designed for SQLite development</td></tr>
<tr><td>GPLv2</td>
    <td>2-clause BSD + CLA</td></tr>
<tr><td>Focus on individual branches</td>
    <td>Focus on the entire tree of changes</td></tr>
<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
<tr><td>One check-out per repository</td>
    <td>Many check-outs per repository</td></tr>
<tr><td>Remembers what you should have done</td>
    <td>Remembers what you actually did</td></tr>
................................................................................
software configuration management problems or D. Richard Hipp scale
problems when choosing your DVCS. An
[https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
not the best way to hang a picture on the living room wall.


<h4 id="license">2.3.3 License</h4>

Git is covered by
[https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the
GPLv2]. Fossil is covered by
[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD
style license]. Neither license affects the managed repository contents,
and it is not our purpose here to try to persuade you to make the same
choice of license that we did. However, we do believe the choice of
license affects the way each tool was developed, which may affect your
choice of which one to use.

The GPL allows a project to do without a
[https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor
license agreement] (CLA) because by the very act of distributing
binaries produced from GPL'd source code, you are bound by the license
to also distribute that source code under a compatible license. Some
GPL-based projects do require a CLA, but usually only to further
................................................................................
[https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an
implicit CLA], but contributors agree to both passively.
[http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil
project's contribution process] requires active steps and processing
time: the printing, signing, mailing, reception, and processing of the
CLA.


We think there's an upside to this difference, in Fossil's favor: it
improves contributor community cohesion, because everyone who pushed
past that legal friction made an affirmative, active step to get commit
capability on the Fossil project repository. We think it makes for a

better, more carefully-designed, simpler DVCS.













<h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3>

Both Fossil and Git store history as a directed acyclic graph (DAG)
of changes, but Git tends to focus more on individual branches of
the DAG, whereas Fossil puts more emphasis on the entire DAG.

<tr><td>File versioning only</td>
    <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr>
<tr><td>Ad-hoc pile-of-files key/value database</td>
    <td>Relational SQL database</td></tr>
<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
<tr><td>Designed for Linux kernel development</td>
    <td>Designed for SQLite development</td></tr>
<tr><td>Many contributors</td>
    <td>Select contributors</td></tr>
<tr><td>Focus on individual branches</td>
    <td>Focus on the entire tree of changes</td></tr>
<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
<tr><td>One check-out per repository</td>
    <td>Many check-outs per repository</td></tr>
<tr><td>Remembers what you should have done</td>
    <td>Remembers what you actually did</td></tr>
................................................................................
software configuration management problems or D. Richard Hipp scale
problems when choosing your DVCS. An
[https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
not the best way to hang a picture on the living room wall.


<h4 id="license">2.3.3 Accepting Contributions</h4>

Git is covered by
[https://en.wikipedia.org/wiki/GNU_General_Public_License#Version_2|the
GPLv2]. Fossil is covered by
[https://fossil-scm.org/fossil/file/COPYRIGHT-BSD2.txt|a two-clause BSD
style license]. Neither license affects the managed repository contents,
and it is not our purpose here to try to persuade you to make the same
choice of license that we did, but we believe the choice of license has
an effect on the actual use of each DVCS. If you don't want to read
about licensing, you can skip to [#whylicmat|our point at the end].

The GPL allows a project to do without a
[https://en.wikipedia.org/wiki/Contributor_License_Agreement|contributor
license agreement] (CLA) because by the very act of distributing
binaries produced from GPL'd source code, you are bound by the license
to also distribute that source code under a compatible license. Some
GPL-based projects do require a CLA, but usually only to further
................................................................................
[https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L306|an
implicit CLA], but contributors agree to both passively.
[http://fossil-scm.org/home/doc/trunk/www/contribute.wiki|The Fossil
project's contribution process] requires active steps and processing
time: the printing, signing, mailing, reception, and processing of the
CLA.

<a name="whylicmat"></a>
We think there's an upside to this difference in licensing, in Fossil's favor: it
improves contributor community cohesion, because everyone who pushed
past that legal friction made an affirmative, active step to get commit
capability on the Fossil project repository. We believe discouraging
[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
contributions] makes for a better, more carefully-designed, simpler
DVCS.

It's so easy to add features to Git that its command interface has
become truly arcane. Masters of the arcane are able to do wizardly
things, but only by studying their art deeply for years. This does not
strike us as a good use of the user's time. We believe it's better to
have a simpler tool with a more easily internalized behavior set, which
you can use quickly then set aside in order to get back to your main
task of producing the content that you manage in the DVCS. We achieve
that by carefully choosing which users to give commit bits to, and which
of their feature branches get merged down to trunk.


<h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3>

Both Fossil and Git store history as a directed acyclic graph (DAG)
of changes, but Git tends to focus more on individual branches of
the DAG, whereas Fossil puts more emphasis on the entire DAG.