Fossil SCM

Clarified point 2.2 of fossil-v-git.wiki, adding more info about the sizes of Fossil vs Git in response to comments on this Hacker News posting: https://news.ycombinator.com/item?id=21974942

wyoung 2020-01-08 19:18 trunk
Commit 9dcb3de471d35e7df777001f9f3f3ebe7f055c5e2ac06d5688b89255e1eef1aa
1 file changed +32 -9
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -161,19 +161,39 @@
161161
so that most people end up installing it via some kind of package
162162
manager, simply because the creation of complicated binary packages is
163163
best delegated to people skilled in their creation. Normal Git users are
164164
not expected to build Git from source and install it themselves.
165165
166
-Fossil is a single self-contained stand-alone executable with hardly any
167
-dependencies. Fossil can be run inside a minimally configured
168
-[https://en.wikipedia.org/wiki/Chroot|chroot jail], from a Windows
169
-memory stick, off a Raspberry Pi with a tiny SD card, etc. To install
170
-Fossil, one merely puts the executable somewhere in the <tt>$PATH</tt>.
171
-Fossil is
166
+Fossil is a single self-contained stand-alone executable which by default
167
+depends only on common platform libraries. If your platform allows static
168
+linking &mdash; not all do these days! &mdash; you can even get it down to
169
+a single executable with no external dependencies at all. Most notably,
170
+we deliver the official Windows builds of Fossil this way: the Zip file
171
+contains only <tt>fossil.exe</tt>, a self-contained Fossil executable;
172
+it is not a <tt>setup.exe</tt> style installer, it is the whole enchilada.
173
+
174
+A typical Fossil executable is about 5&nbsp;MiB, not counting system
175
+libraries it shares in common with Git such as OpenSSL and zlib, which
176
+we can factor out of the discussion.
177
+
178
+These properties allow Fossil to easily run inside a minimally configured
179
+[https://en.wikipedia.org/wiki/Chroot|chroot jail], from a Windows memory
180
+stick, off a Raspberry Pi with a tiny SD card, etc. To install Fossil,
181
+one merely puts the executable somewhere in the <tt>$PATH</tt>. Fossil is
172182
[https://fossil-scm.org/fossil/doc/trunk/www/build.wiki|straightforward
173183
to build and install], so that many Fossil users do in fact build and
174184
install "trunk" versions to get new features between formal releases.
185
+
186
+Contrast a basic installation of Git, which takes up about
187
+15&nbsp;MiB on Debian 10 across 230 files, not counting the contents of
188
+<tt>/usr/share/doc</tt> or <tt>/usr/share/locale</tt>. If you need to
189
+deploy to any platform where you cannot count facilities like the POSIX
190
+shell, Perl interpreter, and Tcl/Tk platform needed to fully use Git
191
+as part of the base platform, the full footprint of a Git installation
192
+extends to more like 45&nbsp;MiB and thousands of files. This complicates
193
+several common scenarios: Git for Windows, chrooted Git servers,
194
+Docker images...
175195
176196
Some say that Git more closely adheres to the Unix philosophy,
177197
summarized as "many small tools, loosely joined," but we have many
178198
examples of other successful Unix software that violates that principle
179199
to good effect, from Apache to Python to ZFS. We can infer from that
@@ -180,21 +200,24 @@
180200
that this is not an absolute principle of good software design.
181201
Sometimes "many features, tightly-coupled" works better. What actually
182202
matters is effectiveness and efficiency. We believe Fossil achieves
183203
this.
184204
185
-Git fails on efficiency once you add to it all of the third-party
186
-software needed to give it a Fossil-equivalent feature set. Consider
205
+The above size comparisons aren't apples-to-apples anyway. We've
206
+compared the size of Fossil with all of its [#features | many built-in
207
+features] to a fairly minimal Git installation. You must add a lot
208
+of third-party
209
+software to Git to give it a Fossil-equivalent feature set. Consider
187210
[https://about.gitlab.com/|GitLab], a third-party extension to Git
188211
wrapping it in many features, making it roughly Fossil-equivalent,
189212
though [https://docs.gitlab.com/ee/install/requirements.html|much more
190213
resource hungry] and hence more costly to run than the equivalent
191214
Fossil setup. GitLab's basic requirements are easy to accept when you're dedicating
192215
a local rack server or blade to it, since its minimum requirements are
193216
more or less a description of the smallest
194217
thing you could call a "server" these days, but when you go to host that
195
-in the cloud, you can expect to pay about 8⨉ as much to comfortably host
218
+in the cloud, you can expect to pay about 8× as much to comfortably host
196219
GitLab as for Fossil.³ This difference is largely due to basic
197220
technology choices: Ruby and PostgreSQL vs C and SQLite.
198221
199222
The Fossil project itself is [./selfhost.wiki|hosted on a very small
200223
VPS], and we've received many reports on the Fossil forum about people
201224
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -161,19 +161,39 @@
161 so that most people end up installing it via some kind of package
162 manager, simply because the creation of complicated binary packages is
163 best delegated to people skilled in their creation. Normal Git users are
164 not expected to build Git from source and install it themselves.
165
166 Fossil is a single self-contained stand-alone executable with hardly any
167 dependencies. Fossil can be run inside a minimally configured
168 [https://en.wikipedia.org/wiki/Chroot|chroot jail], from a Windows
169 memory stick, off a Raspberry Pi with a tiny SD card, etc. To install
170 Fossil, one merely puts the executable somewhere in the <tt>$PATH</tt>.
171 Fossil is
 
 
 
 
 
 
 
 
 
 
172 [https://fossil-scm.org/fossil/doc/trunk/www/build.wiki|straightforward
173 to build and install], so that many Fossil users do in fact build and
174 install "trunk" versions to get new features between formal releases.
 
 
 
 
 
 
 
 
 
 
175
176 Some say that Git more closely adheres to the Unix philosophy,
177 summarized as "many small tools, loosely joined," but we have many
178 examples of other successful Unix software that violates that principle
179 to good effect, from Apache to Python to ZFS. We can infer from that
@@ -180,21 +200,24 @@
180 that this is not an absolute principle of good software design.
181 Sometimes "many features, tightly-coupled" works better. What actually
182 matters is effectiveness and efficiency. We believe Fossil achieves
183 this.
184
185 Git fails on efficiency once you add to it all of the third-party
186 software needed to give it a Fossil-equivalent feature set. Consider
 
 
 
187 [https://about.gitlab.com/|GitLab], a third-party extension to Git
188 wrapping it in many features, making it roughly Fossil-equivalent,
189 though [https://docs.gitlab.com/ee/install/requirements.html|much more
190 resource hungry] and hence more costly to run than the equivalent
191 Fossil setup. GitLab's basic requirements are easy to accept when you're dedicating
192 a local rack server or blade to it, since its minimum requirements are
193 more or less a description of the smallest
194 thing you could call a "server" these days, but when you go to host that
195 in the cloud, you can expect to pay about 8⨉ as much to comfortably host
196 GitLab as for Fossil.³ This difference is largely due to basic
197 technology choices: Ruby and PostgreSQL vs C and SQLite.
198
199 The Fossil project itself is [./selfhost.wiki|hosted on a very small
200 VPS], and we've received many reports on the Fossil forum about people
201
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -161,19 +161,39 @@
161 so that most people end up installing it via some kind of package
162 manager, simply because the creation of complicated binary packages is
163 best delegated to people skilled in their creation. Normal Git users are
164 not expected to build Git from source and install it themselves.
165
166 Fossil is a single self-contained stand-alone executable which by default
167 depends only on common platform libraries. If your platform allows static
168 linking &mdash; not all do these days! &mdash; you can even get it down to
169 a single executable with no external dependencies at all. Most notably,
170 we deliver the official Windows builds of Fossil this way: the Zip file
171 contains only <tt>fossil.exe</tt>, a self-contained Fossil executable;
172 it is not a <tt>setup.exe</tt> style installer, it is the whole enchilada.
173
174 A typical Fossil executable is about 5&nbsp;MiB, not counting system
175 libraries it shares in common with Git such as OpenSSL and zlib, which
176 we can factor out of the discussion.
177
178 These properties allow Fossil to easily run inside a minimally configured
179 [https://en.wikipedia.org/wiki/Chroot|chroot jail], from a Windows memory
180 stick, off a Raspberry Pi with a tiny SD card, etc. To install Fossil,
181 one merely puts the executable somewhere in the <tt>$PATH</tt>. Fossil is
182 [https://fossil-scm.org/fossil/doc/trunk/www/build.wiki|straightforward
183 to build and install], so that many Fossil users do in fact build and
184 install "trunk" versions to get new features between formal releases.
185
186 Contrast a basic installation of Git, which takes up about
187 15&nbsp;MiB on Debian 10 across 230 files, not counting the contents of
188 <tt>/usr/share/doc</tt> or <tt>/usr/share/locale</tt>. If you need to
189 deploy to any platform where you cannot count facilities like the POSIX
190 shell, Perl interpreter, and Tcl/Tk platform needed to fully use Git
191 as part of the base platform, the full footprint of a Git installation
192 extends to more like 45&nbsp;MiB and thousands of files. This complicates
193 several common scenarios: Git for Windows, chrooted Git servers,
194 Docker images...
195
196 Some say that Git more closely adheres to the Unix philosophy,
197 summarized as "many small tools, loosely joined," but we have many
198 examples of other successful Unix software that violates that principle
199 to good effect, from Apache to Python to ZFS. We can infer from that
@@ -180,21 +200,24 @@
200 that this is not an absolute principle of good software design.
201 Sometimes "many features, tightly-coupled" works better. What actually
202 matters is effectiveness and efficiency. We believe Fossil achieves
203 this.
204
205 The above size comparisons aren't apples-to-apples anyway. We've
206 compared the size of Fossil with all of its [#features | many built-in
207 features] to a fairly minimal Git installation. You must add a lot
208 of third-party
209 software to Git to give it a Fossil-equivalent feature set. Consider
210 [https://about.gitlab.com/|GitLab], a third-party extension to Git
211 wrapping it in many features, making it roughly Fossil-equivalent,
212 though [https://docs.gitlab.com/ee/install/requirements.html|much more
213 resource hungry] and hence more costly to run than the equivalent
214 Fossil setup. GitLab's basic requirements are easy to accept when you're dedicating
215 a local rack server or blade to it, since its minimum requirements are
216 more or less a description of the smallest
217 thing you could call a "server" these days, but when you go to host that
218 in the cloud, you can expect to pay about 8× as much to comfortably host
219 GitLab as for Fossil.³ This difference is largely due to basic
220 technology choices: Ruby and PostgreSQL vs C and SQLite.
221
222 The Fossil project itself is [./selfhost.wiki|hosted on a very small
223 VPS], and we've received many reports on the Fossil forum about people
224

Keyboard Shortcuts

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