Fossil SCM
Expanded point 8 in the whyallinone.md doc to cover the benefits of a common skinning and Markdown rendering system. It also implicitly refers to the $current_feature body class feature to show that there's an escape hatch from all this fine uniformity.
Commit
894967492a4ec66f9fd9613a96809e23d63db5ae83a234812850da64bba55f36
Parent
6975de403311606…
1 file changed
+55
-3
+55
-3
| --- www/whyallinone.md | ||
| +++ www/whyallinone.md | ||
| @@ -146,13 +146,65 @@ | ||
| 146 | 146 | Considerations such as these push many into centralized hosting |
| 147 | 147 | servides such as GitHub, GitLab, Bitbucket, and so forth, but that |
| 148 | 148 | just takes you back to point 3 above. |
| 149 | 149 | |
| 150 | 150 | 8. Hosting all of these elements within a single service gives a |
| 151 | - consistent look-and-feel across all aspects of the project, including | |
| 152 | - [project-specific extensions](./serverext.wiki). | |
| 153 | - The [SQLite Release Checklist][srckl] is a noteworthy example of this. | |
| 151 | + consistent look-and-feel across all aspects of the project. | |
| 152 | + | |
| 153 | + This goes deeper than simply skinning independent software | |
| 154 | + elements, though that’s a big enough problem by itself. If you use | |
| 155 | + a separate DVCS front end, chat system, forum manager, | |
| 156 | + documentation system, ticket tracker, and so on, you are likely to | |
| 157 | + be relegated to simply matching colors and fonts; you might also | |
| 158 | + be able to add a common logo to the header of all of these | |
| 159 | + independent pieces. Without heroic levels of local customization, | |
| 160 | + the pieces won’t look unified, because they weren’t developed that | |
| 161 | + way. | |
| 162 | + | |
| 163 | + The Fossil project not only has a single central development focus | |
| 164 | + resulting in a unified web UI design, it gives you a common | |
| 165 | + skinning system for all of its elements so that if you want to | |
| 166 | + customize its appearance, your improvements affect all elements of | |
| 167 | + Fossil. | |
| 168 | + | |
| 169 | + Or not: there’s a feature in Fossil that lets skin customizations | |
| 170 | + apply to only *some* Fossil features. The initial impetus behind | |
| 171 | + this feature was that one of our users wanted Markdown to be | |
| 172 | + rendered with different indentation in forum posts than in | |
| 173 | + embedded documentation owing to the inherent differences between | |
| 174 | + the two presentation modalities. Yet, when a user taking advantage | |
| 175 | + of this feature wishes to change a UI element common to all Fossil | |
| 176 | + features — say, to change the font for literal code blocks — they | |
| 177 | + can still make that sort of global change, the per-feature CSS | |
| 178 | + inheriting all skin changes it doesn’t explicitly override. | |
| 179 | + | |
| 180 | + Speaking of Markdown, unifying all of these features within Fossil | |
| 181 | + means we have a single Markdown interpreter common to all | |
| 182 | + elements. If you lash multiple software systems together, even if | |
| 183 | + they can all agree on Markdown as a common document markup | |
| 184 | + language — hardly a given, as shown by the MediaWiki and Sphinx | |
| 185 | + elements in point 7 above — they’re likely to render your text | |
| 186 | + using different — possibly even incompatibly-different — Markdown | |
| 187 | + dialects. | |
| 188 | + | |
| 189 | + In Fossil, a developer might write a forum post that later gets | |
| 190 | + promoted to a wiki article or to an embedded version-controlled | |
| 191 | + project document. The developer simply copy-pastes the forum post | |
| 192 | + text into the new document and saves it, not needing to carefully | |
| 193 | + check that it still renders properly under the second Markdown | |
| 194 | + rendering engine. Similarly, if a user reports a potential bug via | |
| 195 | + the forum, the developer can copy interesting pieces of the | |
| 196 | + Markdown from the post into a ticket comment, again without | |
| 197 | + needing to fiddle with dialect incompatibilities. | |
| 198 | + | |
| 199 | + But it goes futher. Fossil has a feature for [project-specific | |
| 200 | + extensions](./serverext.wiki), which backs the [SQLite Release | |
| 201 | + Checklist][srckl], for instance. You wouldn’t know by looking at | |
| 202 | + that page that the software backing that page isn’t actually part | |
| 203 | + of Fossil: the extension delivers up just the core of the page, | |
| 204 | + and Fossil’s skining wraps it in a way that lets it inherit all of | |
| 205 | + the per-project skinning customizations. | |
| 154 | 206 | |
| 155 | 207 | 9. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt), |
| 156 | 208 | through and through. Git-backed lash-ups tend to incorporate |
| 157 | 209 | either proprietary add-ons or proprietary hosting systems that |
| 158 | 210 | produce vendor lock-in. Fossil gives you the freedom to take your |
| 159 | 211 |
| --- www/whyallinone.md | |
| +++ www/whyallinone.md | |
| @@ -146,13 +146,65 @@ | |
| 146 | Considerations such as these push many into centralized hosting |
| 147 | servides such as GitHub, GitLab, Bitbucket, and so forth, but that |
| 148 | just takes you back to point 3 above. |
| 149 | |
| 150 | 8. Hosting all of these elements within a single service gives a |
| 151 | consistent look-and-feel across all aspects of the project, including |
| 152 | [project-specific extensions](./serverext.wiki). |
| 153 | The [SQLite Release Checklist][srckl] is a noteworthy example of this. |
| 154 | |
| 155 | 9. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt), |
| 156 | through and through. Git-backed lash-ups tend to incorporate |
| 157 | either proprietary add-ons or proprietary hosting systems that |
| 158 | produce vendor lock-in. Fossil gives you the freedom to take your |
| 159 |
| --- www/whyallinone.md | |
| +++ www/whyallinone.md | |
| @@ -146,13 +146,65 @@ | |
| 146 | Considerations such as these push many into centralized hosting |
| 147 | servides such as GitHub, GitLab, Bitbucket, and so forth, but that |
| 148 | just takes you back to point 3 above. |
| 149 | |
| 150 | 8. Hosting all of these elements within a single service gives a |
| 151 | consistent look-and-feel across all aspects of the project. |
| 152 | |
| 153 | This goes deeper than simply skinning independent software |
| 154 | elements, though that’s a big enough problem by itself. If you use |
| 155 | a separate DVCS front end, chat system, forum manager, |
| 156 | documentation system, ticket tracker, and so on, you are likely to |
| 157 | be relegated to simply matching colors and fonts; you might also |
| 158 | be able to add a common logo to the header of all of these |
| 159 | independent pieces. Without heroic levels of local customization, |
| 160 | the pieces won’t look unified, because they weren’t developed that |
| 161 | way. |
| 162 | |
| 163 | The Fossil project not only has a single central development focus |
| 164 | resulting in a unified web UI design, it gives you a common |
| 165 | skinning system for all of its elements so that if you want to |
| 166 | customize its appearance, your improvements affect all elements of |
| 167 | Fossil. |
| 168 | |
| 169 | Or not: there’s a feature in Fossil that lets skin customizations |
| 170 | apply to only *some* Fossil features. The initial impetus behind |
| 171 | this feature was that one of our users wanted Markdown to be |
| 172 | rendered with different indentation in forum posts than in |
| 173 | embedded documentation owing to the inherent differences between |
| 174 | the two presentation modalities. Yet, when a user taking advantage |
| 175 | of this feature wishes to change a UI element common to all Fossil |
| 176 | features — say, to change the font for literal code blocks — they |
| 177 | can still make that sort of global change, the per-feature CSS |
| 178 | inheriting all skin changes it doesn’t explicitly override. |
| 179 | |
| 180 | Speaking of Markdown, unifying all of these features within Fossil |
| 181 | means we have a single Markdown interpreter common to all |
| 182 | elements. If you lash multiple software systems together, even if |
| 183 | they can all agree on Markdown as a common document markup |
| 184 | language — hardly a given, as shown by the MediaWiki and Sphinx |
| 185 | elements in point 7 above — they’re likely to render your text |
| 186 | using different — possibly even incompatibly-different — Markdown |
| 187 | dialects. |
| 188 | |
| 189 | In Fossil, a developer might write a forum post that later gets |
| 190 | promoted to a wiki article or to an embedded version-controlled |
| 191 | project document. The developer simply copy-pastes the forum post |
| 192 | text into the new document and saves it, not needing to carefully |
| 193 | check that it still renders properly under the second Markdown |
| 194 | rendering engine. Similarly, if a user reports a potential bug via |
| 195 | the forum, the developer can copy interesting pieces of the |
| 196 | Markdown from the post into a ticket comment, again without |
| 197 | needing to fiddle with dialect incompatibilities. |
| 198 | |
| 199 | But it goes futher. Fossil has a feature for [project-specific |
| 200 | extensions](./serverext.wiki), which backs the [SQLite Release |
| 201 | Checklist][srckl], for instance. You wouldn’t know by looking at |
| 202 | that page that the software backing that page isn’t actually part |
| 203 | of Fossil: the extension delivers up just the core of the page, |
| 204 | and Fossil’s skining wraps it in a way that lets it inherit all of |
| 205 | the per-project skinning customizations. |
| 206 | |
| 207 | 9. Fossil is [free, open-source software](../COPYRIGHT-BSD2.txt), |
| 208 | through and through. Git-backed lash-ups tend to incorporate |
| 209 | either proprietary add-ons or proprietary hosting systems that |
| 210 | produce vendor lock-in. Fossil gives you the freedom to take your |
| 211 |