Fossil

Check-in [8f4d5314]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Further refinements to the Fossil-versus-Git document.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 8f4d5314ae4f0f6c0c902f7897092a8fa4ae3593
User & Date: drh 2010-11-11 20:33:31
Context
2010-11-11
21:36
Fix a minor memory leak. check-in: 3541444d user: drh tags: trunk
20:33
Further refinements to the Fossil-versus-Git document. check-in: 8f4d5314 user: drh tags: trunk
20:01
typo check-in: 71f71034 user: bch tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/fossil-v-git.wiki.

40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73









74
75
76
77
78
79
80
..
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
...
120
121
122
123
124
125
126












127
128
129
130
131
132
133
134
...
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
...
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
[./embedddeddoc.wiki | embedded documentation], and
[./event.wiki | News/Blog features].
These additional capabilities are available for Git as 3rd-party
user-installed add-ons, but with Fossil they are integrated into
the design.  One way to describe Fossil is that it is
"[https://github.com/ | github]-in-a-box".

<h3>3.2 Sharing Model</h3>

Git supports a sharded source tree, whereas Fossil wants all all
syncing repositories to carry all information.  Git allows individual
developers to maintain multiple branches on their local repository 
and then selectively push only one or two branches to higher level
developers.  Fossil also allows private local branches, but Fossil
tends to encourage sharing everything, not just one or two select
branches.  The Git model works best for large projects, like the
Linux kernel, since Linus doesn't really want to see a thousand
different branches, one for each contributor.  Git allows intermediary
"gate-keepers" to merge changes from multiple lower-level developers
into a single branch and only present Linus with a handful of branches
at a time.  Fossil encourages a tight-knit, smaller, and more closely
cooperating developer community where all participants share all
of their code all of the time.

The prototypical Git development model is that each developer maintains
their own branch and the various changes from each developer are later
merged into a master branch by an integrator.  The prototypical Fossil
development model is that multiple developers collaborate on the same
branch at the same time.

So in other words, Git promotes a model where individual developers
keep a subset of the branches of a project (sharding) whereas Fossil
promotes every developer having a complete copy of all branches
(replicating).










<h3>3.3 Community</h3>

Git has a huge user community.  If following the herd and being
like everybody else is important to you, then you should choose Git.

Fossil is clearly the "road less traveled":
................................................................................

Among the advantages of Git's huge user community are that new team
members may already be familiar with Git's operation and hence can
bypass the VCS learning curve.  Also, if you need an add-on tool or
script of some kind, a Google search will likely turn up a suitable
tool that you can just download and use.  A huge community also means
that somebody else has likely already encountered and fixed the bugs
so that for you the product will work as advertised.

Among the advantages of the "road less traveled" is that your particular
project will be bigger percentage of the total user base, and is thus
more likely to receive attention from the DVCS maintainers if you do
encounter problems.

<h3>3.4 Complexity</h3>

Git is a complex system.  It can be tricky to use and requires a fair
amount of knowledge and experience to master.  Fossil strives to be
a much simpler system that can be learned and master much more quickly.
Fossil strives to have fewer "gotchas" and quirks that can trip up a
................................................................................
most other DVCSes.  Git takes longer to learn.  And you have to spend
more time thinking about what you are doing with Git.  

Fossil strives for simplicity.  Fossil wants to be easy to learn and to
require little thinking about how to operating it.  Reports from the
field indicate that Fossil is mostly successful at this effort.













<h3>3.5 Implementation Strategy</h3>

Git consists of a collection of many little programs.  Git needs to be
"installed" using some kind of installer or package tool.  Git can be
tricky to install and get working, especially for users without
administrative privileges.

Fossil is a single self-contained executable.  To "install" Fossil one
................................................................................
somewhere on $PATH.  To uninstall Fossil, simply delete the binary.
To upgrade Fossil, replace the old binary with a new one.

Fossil is designed to be trivial to install, uninstall, and upgrade so
that developers can spend more time working on their own projects and
much less time configuring their version control system.

<h3>3.6 Repository Storage</h3>

A Git repository is a "pile-of-files" in the ".git" directory at the
root of the working checkout.  There is a one-to-one correspondence
between repositories and working checkouts.  A power-loss or system crash
in the middle of Git operation can damage or corrupt the Git repository.

A Fossil repository consists of a single disk file.  A single Fossil
repository can serve multiple simultaneous working checkouts.
A Fossil repository is an SQLite database, so it highly resistant
to damage from a power-loss or system crash - incomplete transactions
are simply rolled back after the system reboots.

<h3>3.7 Audit Trail</h3>

Git features the "rebase" command which can be used to change the
sequence of check-ins in the repository.  Rebase can be used to "clean up"
a complex sequence of check-ins to make their intent easier for others
to understand.  From another point of view, rebase can be used to
"rewrite history" - to do what
[http://en.wikipedia.org/wiki/Winston_Smith | Winston Smith] did for
................................................................................
Fossil deliberately avoids rewriting history.  Fossil strives to follow
the accounting philosophy of never erasing anything.  Mistakes are fixed
by entering a correction, with an explanation of why the correction is
needed.  This can make the history of a project messy, but it also
makes it more honest.  The lack of a "rebase" function is considered
a feature of Fossil, not a bug.

<h3>3.8 License</h3>

Both Git and Fossil are open-source.  Git is under 
[http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is
under the 
[http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license].
The difference should not be of a concern to most users.  However,
some corporate lawyers have objections to using GPL products and
are more comfortable with a BSD-style license.







|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>
>
>
>
>
>
>
>
>







 







|



|
|







 







>
>
>
>
>
>
>
>
>
>
>
>
|







 







|












|







 







|








40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
..
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
...
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
...
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
...
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
[./embedddeddoc.wiki | embedded documentation], and
[./event.wiki | News/Blog features].
These additional capabilities are available for Git as 3rd-party
user-installed add-ons, but with Fossil they are integrated into
the design.  One way to describe Fossil is that it is
"[https://github.com/ | github]-in-a-box".

<h3>3.2 Sharding versus Replicating</h3>

Git makes it easy for each repository in a project to hold a subset of
the branches for that project.  In fact, it is entirely possible and not
uncommon for no repository in the project to hold all the different code
versions for a project.  Instead the information is distributed.  
Individual developers have one or more private branches.  A hierarchy
of integrators merge changes from individual developers into collaborative
branches, until all the changes are merged together at the top-level master
branch.  And all of this can be accomplished without having to have all the
code in any one repository.  Developers or groups of developers can share
only those branches that they want to share and keep other branchs of the
project private.  This is analogous to sharding an a distributed database.

Fossil allows private branches, but its default mode is to share everything.
And so in a Fossil project, all respositories tend to contain all of the
content at all times.  This is analogous to replication in a
distributed database.

The Git model works best for large projects, like the
Linux kernel for which Git was designed.
Linus Torvalds does not need or want to see a thousand
different branches, one for each contributor.  Git allows intermediary
"gate-keepers" to merge changes from multiple lower-level developers
into a single branch and only present Linus with a handful of branches
at a time.  Git encourages a programming model where each developer
works in his or her own branch and then merges changes up the hierarchy
until they reach the master branch.

Fossil is designed for smaller and non-hierarchical teams where all
developers are operating directly on the master branch, or at most one
a small number of well defined branches.  
The [concepts.wiki#workflow | autosync] mode of Fossil makes it easy
for multiple developers to work on a single branch and maintain a
linear line of development on that branch without needless forking
and merging.

<h3>3.3 Community</h3>

Git has a huge user community.  If following the herd and being
like everybody else is important to you, then you should choose Git.

Fossil is clearly the "road less traveled":
................................................................................

Among the advantages of Git's huge user community are that new team
members may already be familiar with Git's operation and hence can
bypass the VCS learning curve.  Also, if you need an add-on tool or
script of some kind, a Google search will likely turn up a suitable
tool that you can just download and use.  A huge community also means
that somebody else has likely already encountered and fixed the bugs
so that Git will work for you and your project as advertised.

Among the advantages of the "road less traveled" is that your particular
project will be bigger percentage of the total user base, and is thus
more likely to receive personal attention from the Fossil maintainers 
if you do encounter problems.

<h3>3.4 Complexity</h3>

Git is a complex system.  It can be tricky to use and requires a fair
amount of knowledge and experience to master.  Fossil strives to be
a much simpler system that can be learned and master much more quickly.
Fossil strives to have fewer "gotchas" and quirks that can trip up a
................................................................................
most other DVCSes.  Git takes longer to learn.  And you have to spend
more time thinking about what you are doing with Git.  

Fossil strives for simplicity.  Fossil wants to be easy to learn and to
require little thinking about how to operating it.  Reports from the
field indicate that Fossil is mostly successful at this effort.

<h3>3.5 Web Interface</h3>

Git has a web interface, but it requires a fair amount of setup and an
external web server.  Fossil comes with a fully functional
[./webui.wiki | built-in web-server]
and a really simple mechanism (the "<tt>fossil ui</tt>" command) to
automatically start the web server and bring up a web browser to navigate
it.  The web interface for Fossil is not only easier to set up, it is also
more powerful and easier to use.  The web interface to Fossil is a practical
replacement to the 3rd-party "GUI Tools" that users often employ to operate
Git.

<h3>3.6 Implementation Strategy</h3>

Git consists of a collection of many little programs.  Git needs to be
"installed" using some kind of installer or package tool.  Git can be
tricky to install and get working, especially for users without
administrative privileges.

Fossil is a single self-contained executable.  To "install" Fossil one
................................................................................
somewhere on $PATH.  To uninstall Fossil, simply delete the binary.
To upgrade Fossil, replace the old binary with a new one.

Fossil is designed to be trivial to install, uninstall, and upgrade so
that developers can spend more time working on their own projects and
much less time configuring their version control system.

<h3>3.7 Repository Storage</h3>

A Git repository is a "pile-of-files" in the ".git" directory at the
root of the working checkout.  There is a one-to-one correspondence
between repositories and working checkouts.  A power-loss or system crash
in the middle of Git operation can damage or corrupt the Git repository.

A Fossil repository consists of a single disk file.  A single Fossil
repository can serve multiple simultaneous working checkouts.
A Fossil repository is an SQLite database, so it highly resistant
to damage from a power-loss or system crash - incomplete transactions
are simply rolled back after the system reboots.

<h3>3.8 Audit Trail</h3>

Git features the "rebase" command which can be used to change the
sequence of check-ins in the repository.  Rebase can be used to "clean up"
a complex sequence of check-ins to make their intent easier for others
to understand.  From another point of view, rebase can be used to
"rewrite history" - to do what
[http://en.wikipedia.org/wiki/Winston_Smith | Winston Smith] did for
................................................................................
Fossil deliberately avoids rewriting history.  Fossil strives to follow
the accounting philosophy of never erasing anything.  Mistakes are fixed
by entering a correction, with an explanation of why the correction is
needed.  This can make the history of a project messy, but it also
makes it more honest.  The lack of a "rebase" function is considered
a feature of Fossil, not a bug.

<h3>3.9 License</h3>

Both Git and Fossil are open-source.  Git is under 
[http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is
under the 
[http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license].
The difference should not be of a concern to most users.  However,
some corporate lawyers have objections to using GPL products and
are more comfortable with a BSD-style license.