9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
<blockquote>
<p>I wrote fossil because none of the
other available DVCSes met my needs. If the other DVCSes do
meet your needs, then you might not need fossil. But they
don't meet mine, and so fossil is necessary for me.</p>
<p>Feature provided by fossil that one does not get with other
DVCSes include:</p>
<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 </li>
<li> simple, well-defined,
<a href="fileformat.wiki">enduring file format</a> </li>
</ol>
</blockquote>
<b>Why should I use this rather than Trac?</b>
<blockquote>
|
|
|
|
|
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
<blockquote>
<p>I wrote fossil because none of the
other available DVCSes met my needs. If the other DVCSes do
meet your needs, then you might not need fossil. But they
don't meet mine, and so fossil is necessary for me.</p>
<p>Features provided by fossil that one does not get with other
DVCSes include:</p>
<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 </li>
<li> Simple, well-defined,
<a href="fileformat.wiki">enduring file format</a> </li>
</ol>
</blockquote>
<b>Why should I use this rather than Trac?</b>
<blockquote>
|
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
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
(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 mecurial.
</blockquote>
<b>Fossil looks like the bug tracker that would be in your
Linksys Router's administration screen.</p>
<blockquote>
<p>I take a pragmatic approach to software: form follows functions.
To me, it is more important to have a highly 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 apparance
of Fossil without seriously compromising its reliablity, performance,
an maintainability, I will be happy to accept them. Fossil is
self-hosting. Send me 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 filed. That file can
then be pushed and pulled along with the rest repository.</b>
<blockquote>
<p>This addressed in the opening paragraphs of
the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.
</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
and excellent fossil record of a long-running project.
</blockquote>
<b>The idea of storing a repository in a binary blob like an
SQLite database terrifies me.</b>
<blockquote>
The use of SQLite to store the database is likely more stable and secure
than any other approach, due to the fact that SQLite is transactional.
Fossil also implements several internal
<a href="selfcheck.wiki">self-checks</a> to insure that no information
is every lost. And, indeed, in over a year of operation, there have been
no reports of data loss due to a Fossil malfunction.
</blockquote>
<b>I am dubious of the benefits of including wikis and bug trackers
directly in the VCS - either they are under-featured compared to full
software like Trac, or the VCS is massively bloated compared to
|
|
|
|
|
|
|
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
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
(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.</p>
<blockquote>
<p>I take a pragmatic approach to software: form follows functions.
To me, it is more important to have a highly 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 apparance
of Fossil without seriously compromising its reliablity, performance,
an maintainability, I will be happy to accept them. Fossil is
self-hosting. Send me 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>This is addressed in the opening paragraphs of
the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.
</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>
<b>The idea of storing a repository in a binary blob like an
SQLite database terrifies me.</b>
<blockquote>
The use of SQLite to store the database is likely more stable and secure
than any other approach, due to the fact that SQLite is transactional.
Fossil also implements several internal
<a href="selfcheck.wiki">self-checks</a> to insure that no information
is ever lost. And, indeed, in over a year of operation, there have been
no reports of data loss due to a Fossil malfunction.
</blockquote>
<b>I am dubious of the benefits of including wikis and bug trackers
directly in the VCS - either they are under-featured compared to full
software like Trac, or the VCS is massively bloated compared to
|