Fossil SCM

Extracted part of section 2.1 and merged it with the entire prior content of section 2.5 in fossil-v-git as a new section, "2.2 Efficient and Effective". These were two partially-redundant sections covering Git's sprawl of tools, third-party dependencies, and extensions vs Fossil's self-contained single-binary nature. The new section combines all of that.

wyoung 2019-08-07 02:26 trunk
Commit 5c24bee9fd5abafad0d237edc31feab4f8a11ba36168bef7d174ae15558a7ab4
Parent 754a6a0568afe21…
2 files changed +63 -58 +2 -1
~ www/fossil-v-git.wiki ~ www/selfhost.wiki
M www/fossil-v-git.wiki
+63 -58
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -42,11 +42,11 @@
4242
 <td>Remembers what you actually did</td></tr>
4343
 <tr><td>SHA-1, SHA-256</td>
4444
 <td>256-bit SHA-3</td></tr>
4545
 </table></blockquote>
4646
47
-<h3 id="features">2.1 Feature Set</h3>
47
+<h3 id="features">2.1 Featureful</h3>
4848
4949
 Git provides file versioning services only, whereas Fossil adds
5050
 an integrated [./wikitheory.wiki | wiki],
5151
 [./bugtheory.wiki | ticketing &amp; bug tracking],
5252
 [./embeddeddoc.wiki | embedded documentation],
@@ -68,22 +68,70 @@
6868
 the same using Git requires locating, installing, configuring, integrating,
6969
 and managing a wide assortment of separate tools. Standing up a developer
7070
 website using Fossil can be done in minutes, whereas doing the same using
7171
 Git requires hours or days.
7272
73
-All of this is complete and self-contained in Fossil.
74
-If you clone [https://github.com/git/git|Git's self-hosting repository],
75
-you get just Git's source code.
76
-If you clone Fossil's self-hosting repository, you get the entire
77
-Fossil website — source code, documentation, ticket history, and so forth.
78
-That means you get a copy of this very article and all of its historical
79
-versions, plus the same for all of the other public content on this
80
-site.²
73
+Fossil is small, complete, and self-contained. If you clone
74
+[https://github.com/git/git|Git's self-hosting repository], you get just
75
+Git's source code. If you clone Fossil's self-hosting repository, you
76
+get the entire Fossil website — source code, documentation, ticket
77
+history, and so forth.² That means you get a copy of this very article
78
+and all of its historical versions, plus the same for all of the other
79
+public content on this site.
80
+
81
+
82
+<h3 id="efficient" name="effective">2.2 Efficient and Effective</h3>
83
+
84
+Git is actually a collection of many small tools, each doing one small
85
+part of the job, which can be recombined (by experts) to perform
86
+powerful operations. Git has a lot of complexity and many dependencies,
87
+so that most people end up installing it via some kind of package
88
+manager, simply because these problems are best delegated to people
89
+skilled in the creation of binary softare packages.
90
+
91
+Fossil is a single self-contained stand-alone executable with hardly any
92
+dependencies. Fossil can be (and often is) run inside a minimally
93
+configured [https://en.wikipedia.org/wiki/Chroot|chroot jail]. To
94
+install Fossil, one merely puts the executable somewhere in the
95
+<tt>$PATH</tt>.
96
+
97
+This difference is especially stark on Windows: you need to drag along a
98
+Cygwin or MSYS environment to get Git running on Windows due to all of
99
+its third-party dependencies. Installing Fossil on Windows is the same
100
+as installing it on every other OS: download the executable and drop it
101
+in the <tt>%PATH%</tt> somewhere.
102
+
103
+Some say that Git more closely adheres to the Unix philosophy,
104
+summarized as "many small tools, loosely joined," but we have many
105
+examples of other successful Unix software that violates that principle
106
+to good effect, from Apache to Python to ZFS. We can infer from that
107
+that this is not an absolute principle of good software design.
108
+Sometimes "many features, tightly-coupled" works better. What actually
109
+matters is effectiveness and efficiency. We believe Fossil achieves
110
+this.
111
+
112
+Git fails on efficiency once you add to it all of the third-party
113
+software needed to give it a Fossil-equivalent feature set. Consider
114
+[https://about.gitlab.com/|Gitlab], a third-party extension to Git
115
+wrapping it in many features, making int roughly Fossil-equivalent,
116
+though [https://docs.gitlab.com/ee/install/requirements.html|much more
117
+resource hungry] and hence more costly to run than the equivalent
118
+Fossil setup. Gitlab's requirements are tolerable when you're dedicating
119
+a local rack server or blade to it, since that's about the smallest
120
+thing you could call a "server" these days, but when you go to host that
121
+in the cloud, you can expect to pay about 8⨉ as much to comfortably host
122
+Gitlab as for Fossil. This difference is largely due to basic
123
+technology choices: Ruby and PostgreSQL vs C and SQLite.
124
+
125
+The Fossil project itself is [./selfhost.wiki|hosted on a very small
126
+VPS], and we've received many reports on the Fossil forum about people
127
+successfully hosting Fossil service on bare-bones $5/month VPS hosts,
128
+spare Raspberry Pi boards, and other small hosts.
81129
82130
83131
84
-<h3 id="database">2.2 Database</h3>
132
+<h3 id="database">2.3 Durable</h3>
85133
86134
 The baseline data structures for Fossil and Git are the same, modulo
87135
 formatting details. Both systems store check-ins as immutable
88136
 objects referencing their immediate ancestors and named by a
89137
 cryptographic hash of the check-in content.
@@ -124,11 +172,11 @@
124172
 in ways that help developers
125173
 maintain enhanced awareness and comprehension
126174
 and avoid errors.
127175
128176
129
-<h3 id="vs-linux">2.3 Linux vs. SQLite</h3>
177
+<h3 id="vs-linux">2.4 Linux vs. SQLite</h3>
130178
131179
 Fossil and Git promote different development styles because each one was
132180
 specifically designed to support the creator's main software
133181
 development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
134182
 Torvalds] designed Git to support development of
@@ -145,11 +193,11 @@
145193
146194
 When deciding between these two DVCSes, you should ask yourself, "Is my
147195
 project more like Linux or more like SQLite?"
148196
149197
150
-<h4 id="devorg">2.3.1 Development Organization</h4>
198
+<h4 id="devorg">2.4.1 Development Organization</h4>
151199
152200
 Eric S. Raymond's seminal essay-turned-book
153201
 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
154202
 Cathedral and the Bazaar]" details the two major development
155203
 organization styles found in
@@ -257,11 +305,11 @@
257305
258306
 Each DVCS can be used in the opposite style, but doing so works against
259307
 their low-friction paths.
260308
261309
262
-<h4 id="scale">2.3.2 Scale</h4>
310
+<h4 id="scale">2.4.2 Scale</h4>
263311
264312
 The Linux kernel has a far bigger developer community than that of
265313
 SQLite: there are thousands and thousands of contributors to Linux, most
266314
 of whom do not know each others names. These thousands are responsible
267315
 for producing roughly 89⨉ more code than is in SQLite. (10.7
@@ -284,11 +332,11 @@
284332
 [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
285333
 wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
286334
 not the best way to hang a picture on the living room wall.
287335
288336
289
-<h4 id="contrib">2.3.3 Accepting Contributions</h4>
337
+<h4 id="contrib">2.4.3 Accepting Contributions</h4>
290338
291339
 As of this writing, Git has received about 4.5⨉ as many commits as
292340
 Fossil resulting in about 2.5⨉ as many lines of source code. The line
293341
 count excludes tests and in-tree third-party dependencies. It does not
294342
 exclude the default GUI for each, since it's integral for Fossil, so we
@@ -330,11 +378,11 @@
330378
 The end result is that Fossil more closely adheres to
331379
 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
332380
 principle of least astonishment] than Git does.
333381
334382
335
-<h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3>
383
+<h3 id="branches">2.5 Individual Branches vs. The Entire Change History</h3>
336384
337385
 Both Fossil and Git store history as a directed acyclic graph (DAG)
338386
 of changes, but Git tends to focus more on individual branches of
339387
 the DAG, whereas Fossil puts more emphasis on the entire DAG.
340388
@@ -358,53 +406,10 @@
358406
 with just a handful of active committers. Seeing all
359407
 changes on all branches all at once helps keep the whole team
360408
 up-to-date with what everybody else is doing, resulting in a more
361409
 tightly focused and cohesive implementation.
362410
363
-
364
-<h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3>
365
-
366
-Git consists of many small tools, each doing one small part of the job,
367
-which can be recombined (by experts) to perform powerful operations.
368
-Git has a lot of complexity and many dependencies and requires an "installer"
369
-script or program to get it running.
370
-
371
-Fossil is a single self-contained stand-alone executable with hardly
372
-any dependencies. Fossil can be (and often is) run inside a
373
-minimally configured [https://en.wikipedia.org/wiki/Chroot|chroot jail]. To install Fossil,
374
-one merely puts the executable somewhere in the <tt>$PATH</tt>.
375
-
376
-This difference is especially stark on Windows: you need to drag along a
377
-Cygwin or MSYS environment to get Git running on Windows due to all of
378
-its third-party dependencies. Installing Fossil on Windows is the same
379
-as installing it on every other OS: download the executable and drop it
380
-in the path somewhere.
381
-
382
-The designer of Git says that the Unix philosophy is to have lots of
383
-small tools that collaborate to get the job done. The designer of
384
-Fossil says that the Unix philosophy is "It just works." Both
385
-individuals have written their DVCSes to reflect their own view
386
-of the "Unix philosophy."
387
-
388
-This point combines with the [#features|feature set differences] in an
389
-interesting way: although you can add third-party pieces to Git to give
390
-it equivalent functionality to what Fossil delivers out of the box, the
391
-resulting system will doubtlessly be far less efficient than an
392
-equivalent Fossil setup. We've received many reports on the Fossil forum
393
-about people successfully hosting Fossil service on bare-bones $5/month
394
-VPS hosts, spare Raspberry Pi boards, and similarly resource-constrained
395
-environments. Contrast a feature-requivalent like Gitlab, which has
396
-[https://docs.gitlab.com/ee/install/requirements.html|far steeper
397
-demands] due to basic differences in technology choices: Ruby and
398
-PostgreSQL vs C and SQLite! Gitlab's recommended minimum requirements
399
-are fine when you're dedicating a local rack server to Gitlab, since
400
-that's about the smallest thing you could call a "server" these days,
401
-but when you go to host that in the cloud, their 8&nbsp;GiB of RAM and 2
402
-CPU core recommendation costs about 8⨉ as much as a comfortable hosting
403
-environment for Fossil in a recent check at a major VPS hosting
404
-provider.
405
-
406411
407412
 <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
408413
409414
 A "repository" in Git is a pile-of-files in the ".git" subdirectory
410415
 of a single check-out. The check-out and the repository are located
411416
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -42,11 +42,11 @@
42 <td>Remembers what you actually did</td></tr>
43 <tr><td>SHA-1, SHA-256</td>
44 <td>256-bit SHA-3</td></tr>
45 </table></blockquote>
46
47 <h3 id="features">2.1 Feature Set</h3>
48
49 Git provides file versioning services only, whereas Fossil adds
50 an integrated [./wikitheory.wiki | wiki],
51 [./bugtheory.wiki | ticketing &amp; bug tracking],
52 [./embeddeddoc.wiki | embedded documentation],
@@ -68,22 +68,70 @@
68 the same using Git requires locating, installing, configuring, integrating,
69 and managing a wide assortment of separate tools. Standing up a developer
70 website using Fossil can be done in minutes, whereas doing the same using
71 Git requires hours or days.
72
73 All of this is complete and self-contained in Fossil.
74 If you clone [https://github.com/git/git|Git's self-hosting repository],
75 you get just Git's source code.
76 If you clone Fossil's self-hosting repository, you get the entire
77 Fossil website — source code, documentation, ticket history, and so forth.
78 That means you get a copy of this very article and all of its historical
79 versions, plus the same for all of the other public content on this
80 site.²
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
81
82
83
84 <h3 id="database">2.2 Database</h3>
85
86 The baseline data structures for Fossil and Git are the same, modulo
87 formatting details. Both systems store check-ins as immutable
88 objects referencing their immediate ancestors and named by a
89 cryptographic hash of the check-in content.
@@ -124,11 +172,11 @@
124 in ways that help developers
125 maintain enhanced awareness and comprehension
126 and avoid errors.
127
128
129 <h3 id="vs-linux">2.3 Linux vs. SQLite</h3>
130
131 Fossil and Git promote different development styles because each one was
132 specifically designed to support the creator's main software
133 development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
134 Torvalds] designed Git to support development of
@@ -145,11 +193,11 @@
145
146 When deciding between these two DVCSes, you should ask yourself, "Is my
147 project more like Linux or more like SQLite?"
148
149
150 <h4 id="devorg">2.3.1 Development Organization</h4>
151
152 Eric S. Raymond's seminal essay-turned-book
153 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
154 Cathedral and the Bazaar]" details the two major development
155 organization styles found in
@@ -257,11 +305,11 @@
257
258 Each DVCS can be used in the opposite style, but doing so works against
259 their low-friction paths.
260
261
262 <h4 id="scale">2.3.2 Scale</h4>
263
264 The Linux kernel has a far bigger developer community than that of
265 SQLite: there are thousands and thousands of contributors to Linux, most
266 of whom do not know each others names. These thousands are responsible
267 for producing roughly 89⨉ more code than is in SQLite. (10.7
@@ -284,11 +332,11 @@
284 [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
285 wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
286 not the best way to hang a picture on the living room wall.
287
288
289 <h4 id="contrib">2.3.3 Accepting Contributions</h4>
290
291 As of this writing, Git has received about 4.5⨉ as many commits as
292 Fossil resulting in about 2.5⨉ as many lines of source code. The line
293 count excludes tests and in-tree third-party dependencies. It does not
294 exclude the default GUI for each, since it's integral for Fossil, so we
@@ -330,11 +378,11 @@
330 The end result is that Fossil more closely adheres to
331 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
332 principle of least astonishment] than Git does.
333
334
335 <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3>
336
337 Both Fossil and Git store history as a directed acyclic graph (DAG)
338 of changes, but Git tends to focus more on individual branches of
339 the DAG, whereas Fossil puts more emphasis on the entire DAG.
340
@@ -358,53 +406,10 @@
358 with just a handful of active committers. Seeing all
359 changes on all branches all at once helps keep the whole team
360 up-to-date with what everybody else is doing, resulting in a more
361 tightly focused and cohesive implementation.
362
363
364 <h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3>
365
366 Git consists of many small tools, each doing one small part of the job,
367 which can be recombined (by experts) to perform powerful operations.
368 Git has a lot of complexity and many dependencies and requires an "installer"
369 script or program to get it running.
370
371 Fossil is a single self-contained stand-alone executable with hardly
372 any dependencies. Fossil can be (and often is) run inside a
373 minimally configured [https://en.wikipedia.org/wiki/Chroot|chroot jail]. To install Fossil,
374 one merely puts the executable somewhere in the <tt>$PATH</tt>.
375
376 This difference is especially stark on Windows: you need to drag along a
377 Cygwin or MSYS environment to get Git running on Windows due to all of
378 its third-party dependencies. Installing Fossil on Windows is the same
379 as installing it on every other OS: download the executable and drop it
380 in the path somewhere.
381
382 The designer of Git says that the Unix philosophy is to have lots of
383 small tools that collaborate to get the job done. The designer of
384 Fossil says that the Unix philosophy is "It just works." Both
385 individuals have written their DVCSes to reflect their own view
386 of the "Unix philosophy."
387
388 This point combines with the [#features|feature set differences] in an
389 interesting way: although you can add third-party pieces to Git to give
390 it equivalent functionality to what Fossil delivers out of the box, the
391 resulting system will doubtlessly be far less efficient than an
392 equivalent Fossil setup. We've received many reports on the Fossil forum
393 about people successfully hosting Fossil service on bare-bones $5/month
394 VPS hosts, spare Raspberry Pi boards, and similarly resource-constrained
395 environments. Contrast a feature-requivalent like Gitlab, which has
396 [https://docs.gitlab.com/ee/install/requirements.html|far steeper
397 demands] due to basic differences in technology choices: Ruby and
398 PostgreSQL vs C and SQLite! Gitlab's recommended minimum requirements
399 are fine when you're dedicating a local rack server to Gitlab, since
400 that's about the smallest thing you could call a "server" these days,
401 but when you go to host that in the cloud, their 8&nbsp;GiB of RAM and 2
402 CPU core recommendation costs about 8⨉ as much as a comfortable hosting
403 environment for Fossil in a recent check at a major VPS hosting
404 provider.
405
406
407 <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
408
409 A "repository" in Git is a pile-of-files in the ".git" subdirectory
410 of a single check-out. The check-out and the repository are located
411
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -42,11 +42,11 @@
42 <td>Remembers what you actually did</td></tr>
43 <tr><td>SHA-1, SHA-256</td>
44 <td>256-bit SHA-3</td></tr>
45 </table></blockquote>
46
47 <h3 id="features">2.1 Featureful</h3>
48
49 Git provides file versioning services only, whereas Fossil adds
50 an integrated [./wikitheory.wiki | wiki],
51 [./bugtheory.wiki | ticketing &amp; bug tracking],
52 [./embeddeddoc.wiki | embedded documentation],
@@ -68,22 +68,70 @@
68 the same using Git requires locating, installing, configuring, integrating,
69 and managing a wide assortment of separate tools. Standing up a developer
70 website using Fossil can be done in minutes, whereas doing the same using
71 Git requires hours or days.
72
73 Fossil is small, complete, and self-contained. If you clone
74 [https://github.com/git/git|Git's self-hosting repository], you get just
75 Git's source code. If you clone Fossil's self-hosting repository, you
76 get the entire Fossil website — source code, documentation, ticket
77 history, and so forth.² That means you get a copy of this very article
78 and all of its historical versions, plus the same for all of the other
79 public content on this site.
80
81
82 <h3 id="efficient" name="effective">2.2 Efficient and Effective</h3>
83
84 Git is actually a collection of many small tools, each doing one small
85 part of the job, which can be recombined (by experts) to perform
86 powerful operations. Git has a lot of complexity and many dependencies,
87 so that most people end up installing it via some kind of package
88 manager, simply because these problems are best delegated to people
89 skilled in the creation of binary softare packages.
90
91 Fossil is a single self-contained stand-alone executable with hardly any
92 dependencies. Fossil can be (and often is) run inside a minimally
93 configured [https://en.wikipedia.org/wiki/Chroot|chroot jail]. To
94 install Fossil, one merely puts the executable somewhere in the
95 <tt>$PATH</tt>.
96
97 This difference is especially stark on Windows: you need to drag along a
98 Cygwin or MSYS environment to get Git running on Windows due to all of
99 its third-party dependencies. Installing Fossil on Windows is the same
100 as installing it on every other OS: download the executable and drop it
101 in the <tt>%PATH%</tt> somewhere.
102
103 Some say that Git more closely adheres to the Unix philosophy,
104 summarized as "many small tools, loosely joined," but we have many
105 examples of other successful Unix software that violates that principle
106 to good effect, from Apache to Python to ZFS. We can infer from that
107 that this is not an absolute principle of good software design.
108 Sometimes "many features, tightly-coupled" works better. What actually
109 matters is effectiveness and efficiency. We believe Fossil achieves
110 this.
111
112 Git fails on efficiency once you add to it all of the third-party
113 software needed to give it a Fossil-equivalent feature set. Consider
114 [https://about.gitlab.com/|Gitlab], a third-party extension to Git
115 wrapping it in many features, making int roughly Fossil-equivalent,
116 though [https://docs.gitlab.com/ee/install/requirements.html|much more
117 resource hungry] and hence more costly to run than the equivalent
118 Fossil setup. Gitlab's requirements are tolerable when you're dedicating
119 a local rack server or blade to it, since that's about the smallest
120 thing you could call a "server" these days, but when you go to host that
121 in the cloud, you can expect to pay about 8⨉ as much to comfortably host
122 Gitlab as for Fossil. This difference is largely due to basic
123 technology choices: Ruby and PostgreSQL vs C and SQLite.
124
125 The Fossil project itself is [./selfhost.wiki|hosted on a very small
126 VPS], and we've received many reports on the Fossil forum about people
127 successfully hosting Fossil service on bare-bones $5/month VPS hosts,
128 spare Raspberry Pi boards, and other small hosts.
129
130
131
132 <h3 id="database">2.3 Durable</h3>
133
134 The baseline data structures for Fossil and Git are the same, modulo
135 formatting details. Both systems store check-ins as immutable
136 objects referencing their immediate ancestors and named by a
137 cryptographic hash of the check-in content.
@@ -124,11 +172,11 @@
172 in ways that help developers
173 maintain enhanced awareness and comprehension
174 and avoid errors.
175
176
177 <h3 id="vs-linux">2.4 Linux vs. SQLite</h3>
178
179 Fossil and Git promote different development styles because each one was
180 specifically designed to support the creator's main software
181 development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus
182 Torvalds] designed Git to support development of
@@ -145,11 +193,11 @@
193
194 When deciding between these two DVCSes, you should ask yourself, "Is my
195 project more like Linux or more like SQLite?"
196
197
198 <h4 id="devorg">2.4.1 Development Organization</h4>
199
200 Eric S. Raymond's seminal essay-turned-book
201 "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The
202 Cathedral and the Bazaar]" details the two major development
203 organization styles found in
@@ -257,11 +305,11 @@
305
306 Each DVCS can be used in the opposite style, but doing so works against
307 their low-friction paths.
308
309
310 <h4 id="scale">2.4.2 Scale</h4>
311
312 The Linux kernel has a far bigger developer community than that of
313 SQLite: there are thousands and thousands of contributors to Linux, most
314 of whom do not know each others names. These thousands are responsible
315 for producing roughly 89⨉ more code than is in SQLite. (10.7
@@ -284,11 +332,11 @@
332 [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact
333 wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is
334 not the best way to hang a picture on the living room wall.
335
336
337 <h4 id="contrib">2.4.3 Accepting Contributions</h4>
338
339 As of this writing, Git has received about 4.5⨉ as many commits as
340 Fossil resulting in about 2.5⨉ as many lines of source code. The line
341 count excludes tests and in-tree third-party dependencies. It does not
342 exclude the default GUI for each, since it's integral for Fossil, so we
@@ -330,11 +378,11 @@
378 The end result is that Fossil more closely adheres to
379 [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
380 principle of least astonishment] than Git does.
381
382
383 <h3 id="branches">2.5 Individual Branches vs. The Entire Change History</h3>
384
385 Both Fossil and Git store history as a directed acyclic graph (DAG)
386 of changes, but Git tends to focus more on individual branches of
387 the DAG, whereas Fossil puts more emphasis on the entire DAG.
388
@@ -358,53 +406,10 @@
406 with just a handful of active committers. Seeing all
407 changes on all branches all at once helps keep the whole team
408 up-to-date with what everybody else is doing, resulting in a more
409 tightly focused and cohesive implementation.
410
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
411
412 <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
413
414 A "repository" in Git is a pile-of-files in the ".git" subdirectory
415 of a single check-out. The check-out and the repository are located
416
M www/selfhost.wiki
+2 -1
--- www/selfhost.wiki
+++ www/selfhost.wiki
@@ -56,11 +56,12 @@
5656
 </pre></blockquote>
5757
5858
 In recent years, virtual private servers have become a more flexible and
5959
 less expensive hosting option compared to shared hosting accounts.
6060
 So on 2017-07-25, server (3) was moved
61
-onto a $5/month "droplet" VPS from [https://www.digitalocean.com|Digital Ocean]
61
+onto a $5/month "droplet" [https://en.wikipedia.org/wiki/Virtual_private_server|VPS]
62
+from [https://www.digitalocean.com|Digital Ocean]
6263
 located in San Francisco.
6364
6465
 Server (3) is synchronized with the canonical server (1) by running
6566
 the following command via cron:
6667
6768
--- www/selfhost.wiki
+++ www/selfhost.wiki
@@ -56,11 +56,12 @@
56 </pre></blockquote>
57
58 In recent years, virtual private servers have become a more flexible and
59 less expensive hosting option compared to shared hosting accounts.
60 So on 2017-07-25, server (3) was moved
61 onto a $5/month "droplet" VPS from [https://www.digitalocean.com|Digital Ocean]
 
62 located in San Francisco.
63
64 Server (3) is synchronized with the canonical server (1) by running
65 the following command via cron:
66
67
--- www/selfhost.wiki
+++ www/selfhost.wiki
@@ -56,11 +56,12 @@
56 </pre></blockquote>
57
58 In recent years, virtual private servers have become a more flexible and
59 less expensive hosting option compared to shared hosting accounts.
60 So on 2017-07-25, server (3) was moved
61 onto a $5/month "droplet" [https://en.wikipedia.org/wiki/Virtual_private_server|VPS]
62 from [https://www.digitalocean.com|Digital Ocean]
63 located in San Francisco.
64
65 Server (3) is synchronized with the canonical server (1) by running
66 the following command via cron:
67
68

Keyboard Shortcuts

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