Fossil

Check-in [a52e6845]
Login

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

Overview
Comment:Reduced redundancy in the new feature set size vs ease of use discussion in fossil-v-git.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | bsd-vs-gpl
Files: files | file ages | folders
SHA3-256: a52e68459fe94ce66f87b1a1c247c859caecff77eacc7231eb9b507af66ce039
User & Date: wyoung 2019-07-16 15:44:30
Context
2019-07-17
02:37
Reworked several sections of the fossil-v-git.wiki doc as sub-sections of "Linux vs. SQLite", which now acts as a frame for those sections. Some of these sections are expanded while others disappear entirely, most especially the "BSD vs GPL" argument that we started off on the now-merged branch to try and refine. We replace a discussion of licensing with one of community structure and our approach to patch acceptance, which is more of what the old licensing discussion was trying to get at without getting into the details of software licensing per se. check-in: 69ec89b5 user: wyoung tags: trunk
2019-07-16
15:44
Reduced redundancy in the new feature set size vs ease of use discussion in fossil-v-git. Closed-Leaf check-in: a52e6845 user: wyoung tags: bsd-vs-gpl
15:05
Rewrote the "Accepting Contributions" section of the fossil-v-git doc to focus on the size of each tool in terms of SLOC and features, rather than on licensing details. check-in: 5fe84e70 user: wyoung tags: bsd-vs-gpl
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

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

281
282
283
284
285
286
287
288
289
290
291
292
293
294
295


296
297
298

299
300
301
302
303
304
305
306
307
308


309
310
311
312
313
314
315
316
317
are other relevant differences that also play into this which fall out
of the "Linux vs. SQLite" framing: licensing, community structure, and
how we react to
[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
contributions]. In brief, it's harder to get a new feature into Fossil
than into Git.

Git's larger feature set size is not a good thing. Git's command line
interface is famously arcane. Masters of the arcane are able to do
wizardly things, but only by studying their art deeply for years. This
strikes us as a good thing only in cases where use of the tool itself is
the primary point of that user's work.

Most DVCS users are not using a DVCS for its own sake, so we do not want
the DVCS with the most features but the one that lets us get back to our


actual job as quickly as possible. There is some minimal set of features
required to achieve that, but there is a level beyond which more
features only slow us down when we're trying to figure out how to get

past our latest battle with the DVCS. When the number of features grows
to the point where people of normal motivation cannot spend the time to
master them all, you make the tool <i>less</i> productive to use.

We believe it's better to have a simpler tool with a more easily
internalized behavior set, which you can pick up, use quickly, then set
aside in order to get back to your main task: producing the content that
you manage in the DVCS. We achieve that by carefully choosing which
users to give commit bits to, then which of the feature branches they
create to merge down to trunk.



Fossil more closely adheres to
[https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
principle of least astonishment] than Git does.


<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)







|






|
>
>


|
>
|



|
<
<
<
|
<
>
>

|







281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306



307

308
309
310
311
312
313
314
315
316
317
318
are other relevant differences that also play into this which fall out
of the "Linux vs. SQLite" framing: licensing, community structure, and
how we react to
[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by
contributions]. In brief, it's harder to get a new feature into Fossil
than into Git.

A larger feature set size is not necessarily a good thing. Git's command line
interface is famously arcane. Masters of the arcane are able to do
wizardly things, but only by studying their art deeply for years. This
strikes us as a good thing only in cases where use of the tool itself is
the primary point of that user's work.

Most DVCS users are not using a DVCS for its own sake, so we do not want
the DVCS with the most features, we want the one with a more easily
internalized behavior set, which we can pick up, use quickly, and then
set aside in order to get back to our
actual job as quickly as possible. There is some minimal set of features
required to achieve that, but there is a level beyond which more
features only slow us down while we're learning about the DVCS, as we
must plow through documentation on features we're not likely to ever
use. When the number of features grows
to the point where people of normal motivation cannot spend the time to
master them all, you make the tool <i>less</i> productive to use.

We achieve this balance between feature set size and ease of use by



carefully choosing which users to give commit bits to, then in being

choosy about which of the contributed feature branches to merge down to
trunk.

The end result is that Fossil more closely adheres to
[https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the
principle of least astonishment] than Git does.


<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)