1<title>Project Documentation</title> 2<h1 align="center">Project Documentation</h1> 3 4Fossil provides a built-in <a href="wikitheory.wiki">wiki</a> 5that can be used to store the 6documentation for a project. This is sufficient for many projects. 7If your project is well-served by wiki documentation, then you 8need read no further. 9 10But fossil also supports embedding project documentation as 11files in the source tree. There are several potential advantages 12to this approach: 13 14 1. The documentation files are versioned together with the 15 source code files so it is always clear what version of 16 the documentation goes with a particular release. 17 18 2. The documentation files can be edited using your favorite 19 text editor instead of having to use the web-based wiki 20 editor. 21 22 3. Only people with check-in privileges can modify the documentation. 23 (This might be either an advantage or disadvantage, depending 24 on the nature of your project.) 25 26We will call documentation that is included as files in the source tree 27"embedded documentation". 28 29<h1>1.0 Fossil Support For Embedded Documentation</h1> 30 31The fossil web interface supports embedded documentation using 32the "/doc" page. To access embedded documentation, one points 33a web browser to a fossil URL of the following form: 34 35<blockquote> 36<i><baseurl></i><big><b>/doc/</b></big><i><version></i><big><b>/</b></big><i><filename></i> 37</blockquote> 38 39The <i><baseurl></i> is the main URL used to access the fossil web server. 40For example, the <i><baseurl></i> for the fossil project itself is 41[https://fossil-scm.org/home]. 42If you launch the web server using the "[/help?cmd=ui|fossil ui]" command line, 43then the <i><baseurl></i> is usually 44<b>http://localhost:8080/</b>. 45 46The <i><version></i> is the 47[./checkin_names.wiki|name of a check-in] 48that contains the embedded document. This might be a hash prefix for 49the check-in, or it might be the name of a branch or tag, or it might 50be a timestamp. See the prior link 51for more possibilities and examples. 52 53The <i id="ckout"><version></i> can 54also be the special identifier "<b>ckout</b>". 55The "<b>ckout</b>" keywords means to 56pull the documentation file from the local source tree on disk, not 57from the any check-in. The "<b>ckout</b>" keyword 58only works when you start your server using the 59"[/help?cmd=server|fossil server]" or "[/help?cmd=ui|fossil ui]" 60commands. The "/doc/ckout" URL is intended to show a preview of 61the documentation you are currently editing but have not yet checked in. 62 63The original designed purpose of the "ckout" feature is to allow the 64user to preview local changes to documentation before committing the 65change. This is an important facility, since unlike other document 66languages like HTML, there is still a lot of variation among rendering 67engines for Fossil's markup languages, Markdown and Fossil Wiki. Your 68changes may look fine in your whizzy GUI Markdown editor, but what 69actually matters is how <i>Fossil</i> will interpret your Markdown text. 70Therefore, you should always preview your edits before committing them. 71 72To help make "ckout" easier to use, the "[/help?cmd=ui|fossil ui]" 73command has the "--ckout-alias NAME" option that makes NAME an 74alias for "ckout". If you are editing a collection of documents 75that have hardcoded links to one another in the form of 76"/doc/trunk/...", for example, you can test your changes by 77running "fossil ui --ckout-alias trunk" and all of the links will 78point to your uncommitted edits rather than to the latest trunk 79check-in. 80 81Finally, the <i><filename></i> element of the URL is the 82pathname of the documentation file relative to the root of the source 83tree. 84 85The mimetype (and thus the rendering) of documentation files is 86determined by the file suffix. Fossil currently understands 87[/mimetype_list|many different file suffixes], 88including all the popular ones such as ".css", ".gif", ".htm", 89".html", ".jpg", ".jpeg", ".png", and ".txt". 90 91Documentation files whose names end in ".wiki" use the 92[/wiki_rules | fossil wiki markup] - 93a safe subset of HTML together with some wiki rules for paragraph 94breaks, lists, and hyperlinks. 95Documentation files ending in ".md" or ".markdown" use the 96[/md_rules | Markdown markup language]. 97Documentation files ending in ".txt" are plain text. 98Wiki, markdown, and plain text documentation files 99are rendered with the standard fossil header and footer added. 100Most other mimetypes are delivered directly to the requesting 101web browser without interpretation, additions, or changes. 102 103<h2 id="html">1.1 HTML Rendering With Fossil Headers And Footers</h2> 104 105Files with the mimetype "text/html" (the .html or .htm suffix) are 106usually rendered directly to the browser without interpretation. 107However, if the file begins with a <div> element like this: 108 109 <b><div class='fossil-doc' data-title='<i>Title Text</i>'></b> 110 111Then the standard Fossil header and footer are added to the document 112prior to being displayed. The "class='fossil-doc'" attribute is 113required for this to occur. The "data-title='...'" attribute is 114optional, but if it is present the text will become the title displayed 115in the Fossil header. An example of this can be seen in Fossil 116Documentation Index www/permutedindex.html: 117 118 * [/file/www/permutedindex.html?txt|source text for <b>www/permutedindex.html</b>] 119 * [/doc/trunk/www/permutedindex.html|<b>www/permutedindex.html</b> rendered as HTML] 120 121Beware that such HTML files render in the same browser security context 122as all other embedded documentation served from Fossil; they are not 123fully-independent web pages. One practical consequence of this is that 124embedded <tt><script></tt> tags will cause a 125[https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP | Content 126Security Policy] error in your browser with the default CSP as served by 127Fossil. See the documentation on [./customskin.md#headfoot | Header and 128Footer Processing] and [./defcsp.md | The Default CSP]. 129 130 131<h1>2.0 Server-Side Text Substitution</h1> 132 133Fossil can do a few types of substitution of server-side information 134into the embedded document. 135 136<h2>2.1 "$ROOT" In HTML and Markdown Hyperlinks</h2> 137 138Hyperlinks in Markdown and HTML embedded documents can reference 139the root of the Fossil repository using the special text "$ROOT" 140at the beginning of a URL. For example, a Markdown hyperlink to 141the Markdown formatting rules might be 142written in the embedded document like this: 143 144<nowiki><pre> 145 [Markdown formatting rules]($ROOT/wiki_rules) 146</pre></nowiki> 147 148Depending on how the how the Fossil server is configured, that hyperlink 149might be renderer like one of the following: 150 151<nowiki><pre> 152 <a href="/wiki_rules">Wiki formatting rules</a> 153 <a href="/cgi-bin/fossil/wiki_rules">Wiki formatting rules</a> 154</pre></nowiki> 155 156So, in other words, the "$ROOT" text is converted into whatever 157the "<baseurl>" is for the document. 158 159This substitution works for HTML and Markdown documents. 160It does not work for Wiki embedded documents, since with 161Wiki you can just begin a URL with "/" and it automatically knows 162to prepend the $ROOT. 163 164<h2>2.2 "$CURRENT" In "/doc/" Hyperlinks</h2> 165 166Similarly, URLs of the form "/doc/$CURRENT/..." have the check-in 167hash of the check-in currently being viewed substituted in place of 168the "$CURRENT" text. This feature, in combination with the "$ROOT" 169substitution above, allows an absolute path to be used for hyperlinks. 170 171For example, if an embedded document documented wanted to reference 172some other document in a separate file named "www/otherdoc.md", 173it could use a URL like this: 174 175<nowiki><pre> 176 [Other Document]($ROOT/doc/$CURRENT/www/otherdoc.md) 177</pre></nowiki> 178 179As with "$ROOT", this substitution only works for Markdown and HTML 180documents. For Wiki documents, you would need to use a relative URL. 181 182<h2 id="th1">2.3 TH1 Documents</h2> 183 184Fossil will substitute the value of [./th1.md | TH1 expressions] within 185<tt>{</tt> curly braces <tt>}</tt> into the output HTML if you have 186configured it with the <tt>--with-th1-docs</tt> option, which is 187disabled by default. 188 189Since TH1 is a full scripting language, this feature essential grants 190the ability to execute code on the server to anyone with check-in 191privilege for the project. 192This is a security risk that needs to be carefully managed. 193The feature is off by default. 194Administrators should understand and carefully assess the risks 195before enabling the use of TH1 within embedded documentation. 196 197 198<h1>3.0 Examples</h1> 199 200This file that you are currently reading is an example of 201embedded documentation. The name of this file in the fossil 202source tree is "<b>www/embeddeddoc.wiki</b>". 203You are perhaps looking at this 204file using the URL: 205 206 [http://fossil-scm.org/home/doc/trunk/www/embeddeddoc.wiki]. 207 208The first part of this path, the "[http://fossil-scm.org/home]", 209is the base URL. You might have originally typed: 210[http://fossil-scm.org/]. The web server at the fossil-scm.org 211site automatically redirects such links by appending "home". The 212"home" file on fossil-scm.org is really a [./server/any/cgi.md|CGI script] 213which runs the fossil web service in CGI mode. 214The "home" CGI script looks like this: 215 216<blockquote><pre> 217#!/usr/bin/fossil 218repository: /fossil/fossil.fossil 219</pre></blockquote> 220 221This is one of the many ways to set up a 222<a href="./server/">Fossil server</a>. 223 224The "<b>/trunk/</b>" part of the URL tells fossil to use 225the documentation files from the most recent trunk check-in. 226If you wanted to see an historical version of this document, 227you could substitute the name of a check-in for "<b>/trunk/</b>". 228For example, to see the version of this document associated with 229check-in [9be1b00392], simply replace the "<b>/trunk/</b>" with 230"<b>/9be1b00392/</b>". You can also substitute the symbolic name 231for a particular version or branch. For example, you might 232replace "<b>/trunk/</b>" with "<b>/experimental/</b>" to get the latest 233version of this document in the "experimental" branch. The symbolic name 234can also be a date and time string in any of the following formats:</p> 235 236<ul> 237<li> <i>YYYY-MM-DD</i> 238<li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM</i> 239<li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM:SS</i> 240</ul> 241 242When the symbolic name is a date and time, fossil shows the version 243of the document that was most recently checked in as of the date 244and time specified. So, for example, to see what the fossil website 245looked like at the beginning of 2010, enter: 246 247<blockquote> 248<a href="http://fossil-scm.org/home/doc/2010-01-01/www/index.wiki"> 249http://fossil-scm.org/home/doc/<b>2010-01-01</b>/www/index.wiki 250</a> 251</blockquote> 252 253The file that encodes this document is stored in the fossil source tree under 254the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the 255last part of the URL for this document. 256 257As I sit writing this documentation file, I am testing my work by 258running the "<b>fossil ui</b>" command line and viewing 259<b>http://localhost:8080/doc/ckout/www/embeddeddoc.wiki</b> in 260Firefox. I am doing this even though I have not yet checked in 261the "<b>www/embeddeddoc.wiki</b>" file for the first time. Using 262the special "<b>ckout</b>" version identifier on the "<b>/doc</b>" page 263it is easy to make multiple changes to multiple files and see how they all 264look together before committing anything to the repository. 265