Fossil SCM

Extracted point 5 of the whyallinone doc, moving it out of the list of "good reasons why bundling other project management features with the DVCS might be useful" to the end of the doc, since it is not one of those "good reasons". It just explains that no one's forcing you to accept all of these benefits.

wyoung 2021-06-10 12:17 trunk
Commit ba9e50de58b64e982869008273baca2c566d83ead8e2902397fca34e547261ee
1 file changed +18 -18
+18 -18
--- www/whyallinone.md
+++ www/whyallinone.md
@@ -103,23 +103,11 @@
103103
from ticket to commit to forum to wiki even across these
104104
administrative boundaries, even with remote off-network clones,
105105
simply by adjusting the interwiki map to match the remote clone’s
106106
network configuration.
107107
108
- 5. The forum and chat features of Fossil are disabled by default, and
109
- you can disable the ticket-tracking and wiki features with a quick
110
- configuration change to its [role-based access control
111
- system](./caps/), allowing you to treat Fossil as a more direct
112
- drop-in for Git. When you’re ready to turn these additional features on, you
113
- can do so with a few mouse clicks.
114
-
115
- Because Fossil is web-native out of the box, if you’ve delegated
116
- these features to outside systems to flesh out Git’s DVCS-only
117
- nature, Fossil can link out to these systems, and they back into
118
- Fossil.
119
-
120
- 6. Bundling all of these services gives [single sign-on][SSO] (SSO) for all
108
+ 5. Bundling all of these services gives [single sign-on][SSO] (SSO) for all
121109
aspects of the project. The same username/password works for code,
122110
wiki, forum, tickets, and chat.
123111
124112
If you choose to administratively separate some of these features
125113
by setting up multiple cooperating Fossil repositories, its [login
@@ -127,11 +115,11 @@
127115
across these administrative boundaries so that, for example, users
128116
allowed to commit to the code repository also get a forum
129117
repository login, but self-registered forum users don’t
130118
automatically get the ability to commit to the code repo.
131119
132
- 7. Bundling all of these features reduces the number of external
120
+ 6. Bundling all of these features reduces the number of external
133121
dependencies for the project.
134122
135123
Take the first two points above: standing up a Fossil repo backup
136124
on a new server may be as simple as copying the backup to the new
137125
server and [configuring its stock HTTP server to point at the
@@ -149,11 +137,11 @@
149137
150138
Considerations such as these push many into centralized hosting
151139
services such as GitHub, GitLab, Bitbucket, and so forth, but that
152140
just takes you back to point 3 above.
153141
154
- 8. Hosting all of these elements within a single service gives a
142
+ 7. Hosting all of these elements within a single service gives a
155143
consistent look-and-feel across all aspects of the project.
156144
157145
Skinning independent software packages’ web interfaces to make
158146
them appear unified is more work than skinning everything once, as
159147
in Fossil, and even then, you can’t make independently-developed
@@ -190,16 +178,16 @@
190178
that page that it’s produced by software that isn’t actually part
191179
of Fossil: the extension only delivers the core of the page,
192180
and Fossil’s skining wraps it in a way that lets it inherit all of
193181
the project-level skinning customizations.
194182
195
- 9. Unifying all of these features within Fossil
183
+ 8. Unifying all of these features within Fossil
196184
means we have a single Markdown interpreter common to all
197185
elements. If you lash multiple software systems together, even if
198186
they can all agree on Markdown as a common document markup
199187
language — hardly a given, as shown by the MediaWiki and Sphinx
200
- elements in point 7 above — they’re likely to render your text
188
+ elements in point 6’s example above — they’re likely to render your text
201189
using different — possibly even incompatibly-different — Markdown
202190
dialects.
203191
204192
This costs you in mental gear-switching when moving from the code
205193
repository to the documentation system to the forums to the ticket
@@ -213,20 +201,32 @@
213201
rendering engine. Similarly, if a user reports a potential bug via
214202
the forum, the developer can copy interesting pieces of the
215203
Markdown from the post into a ticket comment, again without
216204
needing to fiddle with dialect incompatibilities.
217205
218
- 10. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt),
206
+ 9. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt),
219207
through and through. Git-backed lash-ups tend to incorporate
220208
either proprietary add-ons or proprietary hosting systems that
221209
produce vendor lock-in. Fossil gives you the freedom to take your
222210
complete backup (point 2) of the project including its
223211
idiosyncratic customizations and stand it up elsewhere on
224212
commodity hardware and software stacks.
213
+
214
+All of this having been said, the non-DVCS features of Fossil are
215
+optional. Its forum and chat features are disabled by default, and you
216
+can disable the ticket-tracking and wiki features with a quick
217
+configuration change to its [role-based access control system](./caps/).
218
+When you’re ready to turn these additional features on, you can do so
219
+with a few mouse clicks.
220
+
221
+Because Fossil is web-native out of the box, if you’ve delegated these
222
+features to outside systems to flesh out Git’s DVCS-only nature, Fossil
223
+can link out to these systems, and they back into Fossil, letting you
224
+use Fossil in the same DVCS-only mode.
225225
226226
[Discord]: https://discord.com/
227227
[edoc]: ./embeddeddoc.wiki
228228
[Jira]: https://www.atlassian.com/software/jira
229229
[MediaWiki]: https://www.mediawiki.org/
230230
[Sphinx]: https://www.sphinx-doc.org/en/master/
231231
[SSO]: https://en.wikipedia.org/wiki/Single_sign-on
232232
[srckl]: https://www.sqlite.org/src/ext/checklist/top/index
233233
--- www/whyallinone.md
+++ www/whyallinone.md
@@ -103,23 +103,11 @@
103 from ticket to commit to forum to wiki even across these
104 administrative boundaries, even with remote off-network clones,
105 simply by adjusting the interwiki map to match the remote clone’s
106 network configuration.
107
108 5. The forum and chat features of Fossil are disabled by default, and
109 you can disable the ticket-tracking and wiki features with a quick
110 configuration change to its [role-based access control
111 system](./caps/), allowing you to treat Fossil as a more direct
112 drop-in for Git. When you’re ready to turn these additional features on, you
113 can do so with a few mouse clicks.
114
115 Because Fossil is web-native out of the box, if you’ve delegated
116 these features to outside systems to flesh out Git’s DVCS-only
117 nature, Fossil can link out to these systems, and they back into
118 Fossil.
119
120 6. Bundling all of these services gives [single sign-on][SSO] (SSO) for all
121 aspects of the project. The same username/password works for code,
122 wiki, forum, tickets, and chat.
123
124 If you choose to administratively separate some of these features
125 by setting up multiple cooperating Fossil repositories, its [login
@@ -127,11 +115,11 @@
127 across these administrative boundaries so that, for example, users
128 allowed to commit to the code repository also get a forum
129 repository login, but self-registered forum users don’t
130 automatically get the ability to commit to the code repo.
131
132 7. Bundling all of these features reduces the number of external
133 dependencies for the project.
134
135 Take the first two points above: standing up a Fossil repo backup
136 on a new server may be as simple as copying the backup to the new
137 server and [configuring its stock HTTP server to point at the
@@ -149,11 +137,11 @@
149
150 Considerations such as these push many into centralized hosting
151 services such as GitHub, GitLab, Bitbucket, and so forth, but that
152 just takes you back to point 3 above.
153
154 8. Hosting all of these elements within a single service gives a
155 consistent look-and-feel across all aspects of the project.
156
157 Skinning independent software packages’ web interfaces to make
158 them appear unified is more work than skinning everything once, as
159 in Fossil, and even then, you can’t make independently-developed
@@ -190,16 +178,16 @@
190 that page that it’s produced by software that isn’t actually part
191 of Fossil: the extension only delivers the core of the page,
192 and Fossil’s skining wraps it in a way that lets it inherit all of
193 the project-level skinning customizations.
194
195 9. Unifying all of these features within Fossil
196 means we have a single Markdown interpreter common to all
197 elements. If you lash multiple software systems together, even if
198 they can all agree on Markdown as a common document markup
199 language — hardly a given, as shown by the MediaWiki and Sphinx
200 elements in point 7 above — they’re likely to render your text
201 using different — possibly even incompatibly-different — Markdown
202 dialects.
203
204 This costs you in mental gear-switching when moving from the code
205 repository to the documentation system to the forums to the ticket
@@ -213,20 +201,32 @@
213 rendering engine. Similarly, if a user reports a potential bug via
214 the forum, the developer can copy interesting pieces of the
215 Markdown from the post into a ticket comment, again without
216 needing to fiddle with dialect incompatibilities.
217
218 10. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt),
219 through and through. Git-backed lash-ups tend to incorporate
220 either proprietary add-ons or proprietary hosting systems that
221 produce vendor lock-in. Fossil gives you the freedom to take your
222 complete backup (point 2) of the project including its
223 idiosyncratic customizations and stand it up elsewhere on
224 commodity hardware and software stacks.
 
 
 
 
 
 
 
 
 
 
 
 
225
226 [Discord]: https://discord.com/
227 [edoc]: ./embeddeddoc.wiki
228 [Jira]: https://www.atlassian.com/software/jira
229 [MediaWiki]: https://www.mediawiki.org/
230 [Sphinx]: https://www.sphinx-doc.org/en/master/
231 [SSO]: https://en.wikipedia.org/wiki/Single_sign-on
232 [srckl]: https://www.sqlite.org/src/ext/checklist/top/index
233
--- www/whyallinone.md
+++ www/whyallinone.md
@@ -103,23 +103,11 @@
103 from ticket to commit to forum to wiki even across these
104 administrative boundaries, even with remote off-network clones,
105 simply by adjusting the interwiki map to match the remote clone’s
106 network configuration.
107
108 5. Bundling all of these services gives [single sign-on][SSO] (SSO) for all
 
 
 
 
 
 
 
 
 
 
 
 
109 aspects of the project. The same username/password works for code,
110 wiki, forum, tickets, and chat.
111
112 If you choose to administratively separate some of these features
113 by setting up multiple cooperating Fossil repositories, its [login
@@ -127,11 +115,11 @@
115 across these administrative boundaries so that, for example, users
116 allowed to commit to the code repository also get a forum
117 repository login, but self-registered forum users don’t
118 automatically get the ability to commit to the code repo.
119
120 6. Bundling all of these features reduces the number of external
121 dependencies for the project.
122
123 Take the first two points above: standing up a Fossil repo backup
124 on a new server may be as simple as copying the backup to the new
125 server and [configuring its stock HTTP server to point at the
@@ -149,11 +137,11 @@
137
138 Considerations such as these push many into centralized hosting
139 services such as GitHub, GitLab, Bitbucket, and so forth, but that
140 just takes you back to point 3 above.
141
142 7. Hosting all of these elements within a single service gives a
143 consistent look-and-feel across all aspects of the project.
144
145 Skinning independent software packages’ web interfaces to make
146 them appear unified is more work than skinning everything once, as
147 in Fossil, and even then, you can’t make independently-developed
@@ -190,16 +178,16 @@
178 that page that it’s produced by software that isn’t actually part
179 of Fossil: the extension only delivers the core of the page,
180 and Fossil’s skining wraps it in a way that lets it inherit all of
181 the project-level skinning customizations.
182
183 8. Unifying all of these features within Fossil
184 means we have a single Markdown interpreter common to all
185 elements. If you lash multiple software systems together, even if
186 they can all agree on Markdown as a common document markup
187 language — hardly a given, as shown by the MediaWiki and Sphinx
188 elements in point 6’s example above — they’re likely to render your text
189 using different — possibly even incompatibly-different — Markdown
190 dialects.
191
192 This costs you in mental gear-switching when moving from the code
193 repository to the documentation system to the forums to the ticket
@@ -213,20 +201,32 @@
201 rendering engine. Similarly, if a user reports a potential bug via
202 the forum, the developer can copy interesting pieces of the
203 Markdown from the post into a ticket comment, again without
204 needing to fiddle with dialect incompatibilities.
205
206 9. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt),
207 through and through. Git-backed lash-ups tend to incorporate
208 either proprietary add-ons or proprietary hosting systems that
209 produce vendor lock-in. Fossil gives you the freedom to take your
210 complete backup (point 2) of the project including its
211 idiosyncratic customizations and stand it up elsewhere on
212 commodity hardware and software stacks.
213
214 All of this having been said, the non-DVCS features of Fossil are
215 optional. Its forum and chat features are disabled by default, and you
216 can disable the ticket-tracking and wiki features with a quick
217 configuration change to its [role-based access control system](./caps/).
218 When you’re ready to turn these additional features on, you can do so
219 with a few mouse clicks.
220
221 Because Fossil is web-native out of the box, if you’ve delegated these
222 features to outside systems to flesh out Git’s DVCS-only nature, Fossil
223 can link out to these systems, and they back into Fossil, letting you
224 use Fossil in the same DVCS-only mode.
225
226 [Discord]: https://discord.com/
227 [edoc]: ./embeddeddoc.wiki
228 [Jira]: https://www.atlassian.com/software/jira
229 [MediaWiki]: https://www.mediawiki.org/
230 [Sphinx]: https://www.sphinx-doc.org/en/master/
231 [SSO]: https://en.wikipedia.org/wiki/Single_sign-on
232 [srckl]: https://www.sqlite.org/src/ext/checklist/top/index
233

Keyboard Shortcuts

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