20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
<ol>
<li> Integrated <a href="wikitheory.wiki">wiki</a>. </li>
<li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li>
<li> Immutable artifacts </li>
<li> Self-contained, stand-alone executable that can be run in
a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li>
<li> Simple, well-defined,
<a href="fileformat.wiki">enduring file format</a> </li>
<li> Integrated <a href="webui.wiki">web interface</a> </li>
</ol>
</blockquote>
<b>Why should I use this rather than Trac?</b>
<blockquote>
<ol>
<li> Fossil is distributed. You can view and/or edit tickets, wiki, and
code while off network, then sync your changes later. With Trac, you
can only view and edit tickets and wiki while you are connected to
the server. </li>
<li> Fossil is lightweight and fully self-contained. It is very easy
to setup on a low-resource machine. Fossil does not require an
administrator.</li>
<li> Fossil integrates code versioning into the same repository with
wiki and tickets. There is nothing extra to add or install.
Fossil is an all-in-one turnkey solution. </li>
</ol>
</blockquote>
<b>Love the concept here. Anyone using this for real work yet?</b>
<blockquote>
Fossil is <a href="http://www.fossil-scm.org/">self-hosting</a>.
In fact, this page was probably delivered
to your web-browser via a working fossil instance. The same virtual
machine that hosts http://www.fossil-scm.org/
(a <a href="http://www.linode.com/">Linode 720</a>)
also hosts 24 other fossil repositories for various small projects.
The documentation files for
<a href="http://www.sqlite.org/">SQLite</a> are hosted in a
fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>,
for example.
Other projects are also adopting fossil. But fossil does not yet have
the massive user base of git or mercurial.
</blockquote>
<b>Fossil looks like the bug tracker that would be in your
Linksys Router's administration screen.</b>
<blockquote>
<p>I take a pragmatic approach to software: form follows function.
To me, it is more important to have a reliable, fast, efficient,
enduring, and simple DVCS than one that looks pretty.</p>
<p>On the other hand, if you have patches that improve the appearance
of Fossil without seriously compromising its reliability, performance,
and/or maintainability, I will be happy to accept them. Fossil is
self-hosting. Send email to request a password that will let
you push to the main fossil repository.</p>
</blockquote>
<b>It would be useful to have a separate application that
keeps the bug-tracking database in a versioned file. That file can
then be pushed and pulled along with the rest repository.</b>
<blockquote>
<p>Fossil already <u>does</u> push and pull bugs along with the files
in your repository.
But fossil does <u>not</u> track bugs as files in the source tree.
That approach to bug tracking was rejected for three reasons:</p>
<ol>
<li> Check-ins in fossil are immutable. So if
tickets were part of the check-in, then there would be no way to add
new tickets to a check-in as new bugs are discovered.
|
|
|
|
|
|
|
|
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
<ol>
<li> Integrated <a href="wikitheory.wiki">wiki</a>. </li>
<li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li>
<li> Immutable artifacts </li>
<li> Self-contained, stand-alone executable that can be run in
a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li>
<li> Simple, well-defined,
<a href="fileformat.wiki">enduring file format</a> </li>
<li> Integrated <a href="webui.wiki">web interface</a> </li>
</ol>
</blockquote>
<b>Why should I use this rather than Trac?</b>
<blockquote>
<ol>
<li> Fossil is distributed. You can view and/or edit tickets, wiki, and
code while off network, then sync your changes later. With Trac, you
can only view and edit tickets and wiki while you are connected to
the server. </li>
<li> Fossil is lightweight and fully self-contained. It is very easy
to setup on a low-resource machine. Fossil does not require an
administrator.</li>
<li> Fossil integrates code versioning into the same repository with
wiki and tickets. There is nothing extra to add or install.
Fossil is an all-in-one turnkey solution. </li>
</ol>
</blockquote>
<b>Love the concept here. Anyone using this for real work yet?</b>
<blockquote>
Fossil is <a href="http://www.fossil-scm.org/">self-hosting</a>.
In fact, this page was probably delivered
to your web-browser via a working fossil instance. The same virtual
machine that hosts http://www.fossil-scm.org/
(a <a href="http://www.linode.com/">Linode 720</a>)
also hosts 24 other fossil repositories for various small projects.
The documentation files for
<a href="http://www.sqlite.org/">SQLite</a> are hosted in a
fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>,
for example.
Other projects are also adopting fossil. But fossil does not yet have
the massive user base of git or mercurial.
</blockquote>
<b>Fossil looks like the bug tracker that would be in your
Linksys Router's administration screen.</b>
<blockquote>
<p>I take a pragmatic approach to software: form follows function.
To me, it is more important to have a reliable, fast, efficient,
enduring, and simple DVCS than one that looks pretty.</p>
<p>On the other hand, if you have patches that improve the appearance
of Fossil without seriously compromising its reliability, performance,
and/or maintainability, I will be happy to accept them. Fossil is
self-hosting. Send email to request a password that will let
you push to the main fossil repository.</p>
</blockquote>
<b>It would be useful to have a separate application that
keeps the bug-tracking database in a versioned file. That file can
then be pushed and pulled along with the rest repository.</b>
<blockquote>
<p>Fossil already <u>does</u> push and pull bugs along with the files
in your repository.
But fossil does <u>not</u> track bugs as files in the source tree.
That approach to bug tracking was rejected for three reasons:</p>
<ol>
<li> Check-ins in fossil are immutable. So if
tickets were part of the check-in, then there would be no way to add
new tickets to a check-in as new bugs are discovered.
|
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
be permitted to create tickets.
</ol>
<p>These points are reiterated in the opening paragraphs of
the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.</p>
</blockquote>
<b>Fossil is already the name of a plan9 versioned
append-only filesystem.</b>
<blockquote>
I did not know that. Perhaps they selected the name for the same reason that
I did: because a repository with immutable artifacts preserves
an excellent fossil record of a long-running project.
</blockquote>
|
|
|
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
be permitted to create tickets.
</ol>
<p>These points are reiterated in the opening paragraphs of
the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.</p>
</blockquote>
<b>Fossil is already the name of a plan9 versioned
append-only filesystem.</b>
<blockquote>
I did not know that. Perhaps they selected the name for the same reason that
I did: because a repository with immutable artifacts preserves
an excellent fossil record of a long-running project.
</blockquote>
|
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
directly in the VCS - either they are under-featured compared to full
software like Trac, or the VCS is massively bloated compared to
Subversion or Bazaar.</b>
<blockquote>
<p>I have no doubt that Trac has many features that fossil lacks. But that
is not the point. Fossil has several key features that Trac lacks and that
I need: most notably the fact that
fossil supports disconnected operation.</p>
<p>As for bloat: Fossil is a single self-contained executable.
You do not need any other packages
(diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache,
sqlite, and so forth)
in order to run fossil. Fossil runs just fine in a chroot jail all
by itself. And the self-contained fossil
executable is much less than 1MB in size. (Update 2015-01-12: Fossil has
grown in the years since the previous sentence was written but is still
much less than 2MB according to "size" when compiled using -Os on x64 Linux.)
Fossil is the very opposite of bloat.</p>
</blockquote>
</nowiki>
|
|
|
|
|
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
directly in the VCS - either they are under-featured compared to full
software like Trac, or the VCS is massively bloated compared to
Subversion or Bazaar.</b>
<blockquote>
<p>I have no doubt that Trac has many features that fossil lacks. But that
is not the point. Fossil has several key features that Trac lacks and that
I need: most notably the fact that
fossil supports disconnected operation.</p>
<p>As for bloat: Fossil is a single self-contained executable.
You do not need any other packages
(diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache,
sqlite, and so forth)
in order to run fossil. Fossil runs just fine in a chroot jail all
by itself. And the self-contained fossil
executable is much less than 1MB in size. (Update 2015-01-12: Fossil has
grown in the years since the previous sentence was written but is still
much less than 2MB according to "size" when compiled using -Os on x64 Linux.)
Fossil is the very opposite of bloat.</p>
</blockquote>
</nowiki>
|