|
1
|
<title>Questions And Criticisms</title> |
|
2
|
|
|
3
|
This page is a collection of real questions and criticisms that were |
|
4
|
raised against Fossil early in its history (circa 2008). |
|
5
|
This page is old and has not been kept up-to-date. See the |
|
6
|
[/finfo?name=www/qandc.wiki|change history of this page]. |
|
7
|
|
|
8
|
<b>Fossil sounds like a lot of reinvention of the wheel. |
|
9
|
Why create your own DVCS when you could have reused mercurial?</b> |
|
10
|
|
|
11
|
<div class="indent"> |
|
12
|
I wrote fossil because none of the |
|
13
|
other available DVCSes met my needs. If the other DVCSes do |
|
14
|
meet your needs, then you might not need fossil. But they |
|
15
|
don't meet mine, and so fossil is necessary for me. |
|
16
|
|
|
17
|
Features provided by fossil that one does not get with other |
|
18
|
DVCSes include: |
|
19
|
|
|
20
|
<ol> |
|
21
|
<li> Integrated <a href="wikitheory.wiki">wiki</a>. </li> |
|
22
|
<li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li> |
|
23
|
<li> Immutable artifacts </li> |
|
24
|
<li> Self-contained, stand-alone executable that can be run in |
|
25
|
a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
|
26
|
<li> Simple, well-defined, |
|
27
|
<a href="fileformat.wiki">enduring file format</a> </li> |
|
28
|
<li> Integrated <a href="webui.wiki">web interface</a> </li> |
|
29
|
</ol> |
|
30
|
</div> |
|
31
|
|
|
32
|
<b>Why should I use this rather than Trac?</b> |
|
33
|
|
|
34
|
<div class="indent"> |
|
35
|
<ol> |
|
36
|
<li> Fossil is distributed. You can view and/or edit tickets, wiki, and |
|
37
|
code while off network, then sync your changes later. With Trac, you |
|
38
|
can only view and edit tickets and wiki while you are connected to |
|
39
|
the server. </li> |
|
40
|
<li> Fossil is lightweight and fully self-contained. It is very easy |
|
41
|
to setup on a low-resource machine. Fossil does not require an |
|
42
|
administrator.</li> |
|
43
|
<li> Fossil integrates code versioning into the same repository with |
|
44
|
wiki and tickets. There is nothing extra to add or install. |
|
45
|
Fossil is an all-in-one turnkey solution. </li> |
|
46
|
</ol> |
|
47
|
</div> |
|
48
|
|
|
49
|
<b>Love the concept here. Anyone using this for real work yet?</b> |
|
50
|
|
|
51
|
<div class="indent"> |
|
52
|
Fossil is <a href="https://fossil-scm.org/">self-hosting</a>. |
|
53
|
In fact, this page was probably delivered |
|
54
|
to your web-browser via a working fossil instance. The same virtual |
|
55
|
machine that hosts https://fossil-scm.org/ |
|
56
|
(a <a href="http://www.linode.com/">Linode 720</a>) |
|
57
|
also hosts 24 other fossil repositories for various small projects. |
|
58
|
The documentation files for |
|
59
|
<a href="http://www.sqlite.org/">SQLite</a> are hosted in a |
|
60
|
fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>, |
|
61
|
for example. |
|
62
|
Other projects are also adopting fossil. But fossil does not yet have |
|
63
|
the massive user base of git or mercurial. |
|
64
|
</div> |
|
65
|
|
|
66
|
<b>Fossil looks like the bug tracker that would be in your |
|
67
|
Linksys Router's administration screen.</b> |
|
68
|
|
|
69
|
<div class="indent"> |
|
70
|
I take a pragmatic approach to software: form follows function. |
|
71
|
To me, it is more important to have a reliable, fast, efficient, |
|
72
|
enduring, and simple DVCS than one that looks pretty. |
|
73
|
|
|
74
|
On the other hand, if you have patches that improve the appearance |
|
75
|
of Fossil without seriously compromising its reliability, performance, |
|
76
|
and/or maintainability, I will be happy to accept them. Fossil is |
|
77
|
self-hosting. Send email to request a password that will let |
|
78
|
you push to the main fossil repository. |
|
79
|
</div> |
|
80
|
|
|
81
|
<b>It would be useful to have a separate application that |
|
82
|
keeps the bug-tracking database in a versioned file. That file can |
|
83
|
then be pushed and pulled along with the rest repository.</b> |
|
84
|
|
|
85
|
<div class="indent"> |
|
86
|
Fossil already <u>does</u> push and pull bugs along with the files |
|
87
|
in your repository. |
|
88
|
But fossil does <u>not</u> track bugs as files in the source tree. |
|
89
|
That approach to bug tracking was rejected for three reasons: |
|
90
|
|
|
91
|
<ol> |
|
92
|
<li> Check-ins in fossil are immutable. So if |
|
93
|
tickets were part of the check-in, then there would be no way to add |
|
94
|
new tickets to a check-in as new bugs are discovered. |
|
95
|
|
|
96
|
<li> Any project of reasonable size and complexity will generate thousands |
|
97
|
and thousands of tickets, and we do not want all those ticket files |
|
98
|
cluttering the source tree. |
|
99
|
|
|
100
|
<li> We want tickets to be managed from the web interface and to have a |
|
101
|
permission system that is distinct from check-in permissions. |
|
102
|
In other words, we do not want to restrict the creation and editing |
|
103
|
of tickets to developers with check-in privileges and an installed |
|
104
|
copy of the fossil executable. Casual passers-by on the internet should |
|
105
|
be permitted to create tickets. |
|
106
|
</ol> |
|
107
|
|
|
108
|
These points are reiterated in the opening paragraphs of |
|
109
|
the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document. |
|
110
|
</div> |
|
111
|
|
|
112
|
<b>Fossil is already the name of a plan9 versioned |
|
113
|
append-only filesystem.</b> |
|
114
|
|
|
115
|
<div class="indent"> |
|
116
|
I did not know that. Perhaps they selected the name for the same reason that |
|
117
|
I did: because a repository with immutable artifacts preserves |
|
118
|
an excellent fossil record of a long-running project. |
|
119
|
</div> |
|
120
|
|
|
121
|
<b>The idea of storing a repository in a binary blob like an |
|
122
|
SQLite database terrifies me.</b> |
|
123
|
|
|
124
|
<div class="indent"> |
|
125
|
The use of SQLite to store the database is likely more stable and secure |
|
126
|
than any other approach, due to the fact that SQLite is transactional. |
|
127
|
Fossil also implements several internal |
|
128
|
<a href="selfcheck.wiki">self-checks</a> to insure that no information |
|
129
|
is ever lost. |
|
130
|
</div> |
|
131
|
|
|
132
|
|
|
133
|
<b>I am dubious of the benefits of including wikis and bug trackers |
|
134
|
directly in the VCS - either they are under-featured compared to full |
|
135
|
software like Trac, or the VCS is massively bloated compared to |
|
136
|
Subversion or Bazaar.</b> |
|
137
|
|
|
138
|
<div class="indent"> |
|
139
|
I have no doubt that Trac has many features that fossil lacks. But that |
|
140
|
is not the point. Fossil has several key features that Trac lacks and that |
|
141
|
I need: most notably the fact that |
|
142
|
fossil supports disconnected operation. |
|
143
|
|
|
144
|
As for bloat: Fossil is a single self-contained executable. |
|
145
|
You do not need any other packages |
|
146
|
(diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache, |
|
147
|
SQLite, and so forth) |
|
148
|
in order to run fossil. Fossil runs just fine in a chroot jail all |
|
149
|
by itself. And the self-contained fossil |
|
150
|
executable is much less than 1MB in size. (Update 2015-01-12: Fossil has |
|
151
|
grown in the years since the previous sentence was written but is still |
|
152
|
much less than 2MB according to "size" when compiled using -Os on x64 Linux.) |
|
153
|
Fossil is the very opposite of bloat. |
|
154
|
</div> |
|
155
|
|