150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
mental picture of what is happening, and better situational awareness.
<h3>2.4 Linux vs. SQLite</h3>
Git was specifically designed to support the development of the Linux kernel.
Fossil was specifically designed to support the development of SQLite.
Both SQLite and the Linux kernel are important pieces of software.
SQLite is found on far more systems than Linux. Almost every Linux
system uses SQLite, but there are many non-Linux systems such as
iPhones, PlayStations, and Windows PCs that use SQLite. On the other
hand, for those systems that do use Linux, Linux is a far more important
component.
The Linux kernel uses a bazaar-style development model. There are thousands and
thousands of contributors, most of whom do not know each others names.
Git is designed for this scenario.
comes from just three programmers, 64% from just the lead developer.
And all SQLite developers know each other well and interact daily.
Fossil is designed for this development model.
<h3>2.5 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.
|
|
|
|
<
|
>
|
>
>
>
>
|
|
|
>
>
>
>
>
>
>
|
150
151
152
153
154
155
156
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
185
186
187
188
189
|
mental picture of what is happening, and better situational awareness.
<h3>2.4 Linux vs. SQLite</h3>
Git was specifically designed to support the development of the Linux kernel.
Fossil was specifically designed to support the development of SQLite.
SQLite is much more widely deployed than the Linux kernel, but for
Linux-based systems, the kernel is the more fundamental component.
Although both projects must rank high on any objective list of "most
important FOSS projects," the two projects are almost entirely unlike
one another, and this shows up in the design choices of the tools
created to support them.
The Linux kernel uses a bazaar-style development model. There are thousands and
thousands of contributors, most of whom do not know each others names.
These thousands are responsible for producing roughly 89⨉ more code than
is in SQLite. (10.7
[https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs 0.12 MLOC
according to [https://dwheeler.com/sloccount/|SLOCCount].) Git is
designed for this scenario.
SQLite uses cathedral-style development. 95% of the code in SQLite
comes from just four programmers, and 64% of it is from the lead developer alone.
The SQLite developers know each other well and interact daily.
Fossil is designed for this development model.
We think you should ask yourself whether you have
[https://en.wikipedia.org/wiki/Linus_Torvalds|Linus Torvalds] scale
software configuration management problems or
[https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] scale
problems when choosing your DVCS. You don't use a pneumatic ratchet
wrench to hang a picture on the living room wall.
<h3>2.5 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.
|