54977e1413a… — Fossil SCM

M www/aboutcgi.wiki

+32 -22

		--- www/aboutcgi.wiki
		+++ www/aboutcgi.wiki
		@@ -1,7 +1,9 @@
1	1	<title>How CGI Works In Fossil</title>
2		-<h2>Introduction</h2><blockquote>
	2	+
	3	+<h2>Introduction</h2>
	4	+
3	5	CGI or "Common Gateway Interface" is a venerable yet reliable technique for
4	6	generating dynamic web content. This article gives a quick background on how
5	7	CGI works and describes how Fossil can act as a CGI service.
6	8
7	9	This is a "how it works" guide. This document provides background
		@@ -8,12 +10,12 @@
8	10	information on the CGI protocol so that you can better understand what
9	11	is going on behind the scenes. If you just want to set up Fossil
10	12	as a CGI server, see the [./server/ \| Fossil Server Setup] page. Or
11	13	if you want to development CGI-based extensions to Fossil, see
12	14	the [./serverext.wiki\|CGI Server Extensions] page.
13		-</blockquote>
14		-<h2>A Quick Review Of CGI</h2><blockquote>
	15	+
	16	+<h2>A Quick Review Of CGI</h2>
15	17
16	18	An HTTP request is a block of text that is sent by a client application
17	19	(usually a web browser) and arrives at the web server over a network
18	20	connection. The HTTP request contains a URL that describes the information
19	21	being requested. The URL in the HTTP request is typically the same URL
		@@ -29,11 +31,13 @@
29	31	The web server is free to interpret the HTTP request in any way it wants.
30	32	But most web servers follow a similar pattern, described below.
31	33	(Note: details may vary from one web server to another.)
32	34
33	35	Suppose the filename component of the URL in the HTTP request looks like this:
34		-<blockquote><b>/one/two/timeline/four</b></blockquote>
	36	+
	37	+<pre>/one/two/timeline/four</pre>
	38	+
35	39	Most web servers will search their content area for files that match
36	40	some prefix of the URL. The search starts with <b>/one</b>, then goes to
37	41	<b>/one/two</b>, then <b>/one/two/timeline</b>, and finally
38	42	<b>/one/two/timeline/four</b> is checked. The search stops at the first
39	43	match.
		@@ -46,12 +50,12 @@
46	50	executes the <b>/one/two</b> script. The output generated by
47	51	the script is collected and repackaged as the HTTP reply.
48	52
49	53	Before executing the CGI script, the web server will set up various
50	54	environment variables with information useful to the CGI script:
51		-<table border=1 cellpadding=5>
52		-<tr><th>Environment<br>Variable<th>Meaning
	55	+<table>
	56	+<tr><th>Variable<th>Meaning
53	57	<tr><td>GATEWAY_INTERFACE<td>Always set to "CGI/1.0"
54	58	<tr><td>REQUEST_URI
55	59	<td>The input URL from the HTTP request.
56	60	<tr><td>SCRIPT_NAME
57	61	<td>The prefix of the input URL that matches the CGI script name.
		@@ -85,19 +89,21 @@
85	89	but a CGI script handles just one HTTP request and then exits.
86	90
87	91	The above is a rough outline of how CGI works.
88	92	There are many details omitted from this brief discussion.
89	93	See other on-line CGI tutorials for further information.
90		-</blockquote>
	94	+
91	95	<h2>How Fossil Acts As A CGI Program</h2>
92		-<blockquote>
	96	+
93	97	An appropriate CGI script for running Fossil will look something
94	98	like the following:
95		-<blockquote><pre>
	99	+
	100	+<pre>
96	101	#!/usr/bin/fossil
97	102	repository: /home/www/repos/project.fossil
98		-</pre></blockquote>
	103	+</pre>
	104	+
99	105	The first line of the script is a
100	106	"[https://en.wikipedia.org/wiki/Shebang_%28Unix%29\|shebang]"
101	107	that tells the operating system what program to use as the interpreter
102	108	for this script. On unix, when you execute a script that starts with
103	109	a shebang, the operating system runs the program identified by the
		@@ -134,20 +140,21 @@
134	140	exactly the same thing to Fossil:
135	141	<ol type='A'>
136	142	<li> [https://fossil-scm.org/home/info/c14ecc43]
137	143	<li> [https://fossil-scm.org/home/info?name=c14ecc43]
138	144	</ol>
	145	+
139	146	In both cases, the CGI script is called "/fossil". For case (A),
140	147	the PATH_INFO variable will be "info/c14ecc43" and so the
141	148	"[/help?cmd=/info\|/info]" webpage will be generated and the suffix of
142	149	PATH_INFO will be converted into the "name" query parameter, which
143	150	identifies the artifact about which information is requested.
144	151	In case (B), the PATH_INFO is just "info", but the same "name"
145	152	query parameter is set explicitly by the URL itself.
146		-</blockquote>
	153	+
147	154	<h2>Serving Multiple Fossil Repositories From One CGI Script</h2>
148		-<blockquote>
	155	+
149	156	The previous example showed how to serve a single Fossil repository
150	157	using a single CGI script.
151	158	On a website that wants to serve multiple repositories, one could
152	159	simply create multiple CGI scripts, one script for each repository.
153	160	But it is also possible to serve multiple Fossil repositories from
		@@ -155,22 +162,26 @@
155	162
156	163	If the CGI script for Fossil contains a "directory:" line instead of
157	164	a "repository:" line, then the argument to "directory:" is the name
158	165	of a directory that contains multiple repository files, each ending
159	166	with ".fossil". For example:
160		-<blockquote><pre>
	167	+
	168	+<pre>
161	169	#!/usr/bin/fossil
162	170	directory: /home/www/repos
163		-</pre></blockquote>
	171	+</pre>
	172	+
164	173	Suppose the /home/www/repos directory contains files named
165	174	<b>one.fossil</b>, <b>two.fossil</b>, and <b>subdir/three.fossil</b>.
166	175	Further suppose that the name of the CGI script (relative to the root
167	176	of the webserver document area) is "cgis/example2". Then to
168	177	see the timeline for the "three.fossil" repository, the URL would be:
169		-<blockquote>
170		-<b>http://example.com/cgis/example2/subdir/three/timeline</b>
171		-</blockquote>
	178	+
	179	+<pre>
	180	+http://example.com/cgis/example2/subdir/three/timeline
	181	+</pre>
	182	+
172	183	Here is what happens:
173	184	<ol>
174	185	<li> The input URI on the HTTP request is
175	186	<b>/cgis/example2/subdir/three/timeline</b>
176	187	<li> The web server searches prefixes of the input URI until it finds
		@@ -186,33 +197,33 @@
186	197	"subdir/three/" leaving it at just "timeline".
187	198	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
188	199	requested is "timeline".
189	200	</ol>
190	201	<a id="cgivar"></a>
	202	+
191	203	The web server sets many environment variables in step 2 in addition
192	204	to just PATH_INFO. The following diagram shows a few of these variables
193	205	and their relationship to the request URL:
	206	+
194	207	<pre>
195	208	REQUEST_URI
196	209	___________________\|_______________________
197	210	/ \
198	211	http://example.com/cgis/example2/subdir/three/timeline?c=55d7e1
199	212	\_________/\____________/\____________________/ \______/
200	213	\| \| \| \|
201	214	HTTP_HOST SCRIPT_NAME PATH_INFO QUERY_STRING
202	215	</pre>
203		-</blockquote>
	216	+
204	217	<h2>Additional CGI Script Options</h2>
205		-<blockquote>
206	218
207	219	The CGI script can have additional options used to fine-tune
208	220	Fossil's behavior. See the [./cgi.wiki\|CGI script documentation]
209	221	for details.
210	222
211		-</blockquote>
212	223	<h2>Additional Observations</h2>
213		-<blockquote><ol type="I">
	224	+<ol type="I">
214	225	<li><p>
215	226	Fossil does not distinguish between the various HTTP methods (GET, PUT,
216	227	DELETE, etc). Fossil figures out what it needs to do purely from the
217	228	webpage term of the URI.</p></li>
218	229	<li><p>
		@@ -239,6 +250,5 @@
239	250	<li><p>
240	251	Fossil is itself often launched using CGI. But Fossil can also then
241	252	turn around and launch [./serverext.wiki\|sub-CGI scripts to implement
242	253	extensions].</p></li>
243	254	</ol>
244		-</blockquote>
245	255

	--- www/aboutcgi.wiki
	+++ www/aboutcgi.wiki
	@@ -1,7 +1,9 @@
1	<title>How CGI Works In Fossil</title>
2	<h2>Introduction</h2><blockquote>


3	CGI or "Common Gateway Interface" is a venerable yet reliable technique for
4	generating dynamic web content. This article gives a quick background on how
5	CGI works and describes how Fossil can act as a CGI service.
6
7	This is a "how it works" guide. This document provides background
	@@ -8,12 +10,12 @@
8	information on the CGI protocol so that you can better understand what
9	is going on behind the scenes. If you just want to set up Fossil
10	as a CGI server, see the [./server/ \| Fossil Server Setup] page. Or
11	if you want to development CGI-based extensions to Fossil, see
12	the [./serverext.wiki\|CGI Server Extensions] page.
13	</blockquote>
14	<h2>A Quick Review Of CGI</h2><blockquote>
15
16	An HTTP request is a block of text that is sent by a client application
17	(usually a web browser) and arrives at the web server over a network
18	connection. The HTTP request contains a URL that describes the information
19	being requested. The URL in the HTTP request is typically the same URL
	@@ -29,11 +31,13 @@
29	The web server is free to interpret the HTTP request in any way it wants.
30	But most web servers follow a similar pattern, described below.
31	(Note: details may vary from one web server to another.)
32
33	Suppose the filename component of the URL in the HTTP request looks like this:
34	<blockquote><b>/one/two/timeline/four</b></blockquote>


35	Most web servers will search their content area for files that match
36	some prefix of the URL. The search starts with <b>/one</b>, then goes to
37	<b>/one/two</b>, then <b>/one/two/timeline</b>, and finally
38	<b>/one/two/timeline/four</b> is checked. The search stops at the first
39	match.
	@@ -46,12 +50,12 @@
46	executes the <b>/one/two</b> script. The output generated by
47	the script is collected and repackaged as the HTTP reply.
48
49	Before executing the CGI script, the web server will set up various
50	environment variables with information useful to the CGI script:
51	<table border=1 cellpadding=5>
52	<tr><th>Environment<br>Variable<th>Meaning
53	<tr><td>GATEWAY_INTERFACE<td>Always set to "CGI/1.0"
54	<tr><td>REQUEST_URI
55	<td>The input URL from the HTTP request.
56	<tr><td>SCRIPT_NAME
57	<td>The prefix of the input URL that matches the CGI script name.
	@@ -85,19 +89,21 @@
85	but a CGI script handles just one HTTP request and then exits.
86
87	The above is a rough outline of how CGI works.
88	There are many details omitted from this brief discussion.
89	See other on-line CGI tutorials for further information.
90	</blockquote>
91	<h2>How Fossil Acts As A CGI Program</h2>
92	<blockquote>
93	An appropriate CGI script for running Fossil will look something
94	like the following:
95	<blockquote><pre>

96	#!/usr/bin/fossil
97	repository: /home/www/repos/project.fossil
98	</pre></blockquote>

99	The first line of the script is a
100	"[https://en.wikipedia.org/wiki/Shebang_%28Unix%29\|shebang]"
101	that tells the operating system what program to use as the interpreter
102	for this script. On unix, when you execute a script that starts with
103	a shebang, the operating system runs the program identified by the
	@@ -134,20 +140,21 @@
134	exactly the same thing to Fossil:
135	<ol type='A'>
136	<li> [https://fossil-scm.org/home/info/c14ecc43]
137	<li> [https://fossil-scm.org/home/info?name=c14ecc43]
138	</ol>

139	In both cases, the CGI script is called "/fossil". For case (A),
140	the PATH_INFO variable will be "info/c14ecc43" and so the
141	"[/help?cmd=/info\|/info]" webpage will be generated and the suffix of
142	PATH_INFO will be converted into the "name" query parameter, which
143	identifies the artifact about which information is requested.
144	In case (B), the PATH_INFO is just "info", but the same "name"
145	query parameter is set explicitly by the URL itself.
146	</blockquote>
147	<h2>Serving Multiple Fossil Repositories From One CGI Script</h2>
148	<blockquote>
149	The previous example showed how to serve a single Fossil repository
150	using a single CGI script.
151	On a website that wants to serve multiple repositories, one could
152	simply create multiple CGI scripts, one script for each repository.
153	But it is also possible to serve multiple Fossil repositories from
	@@ -155,22 +162,26 @@
155
156	If the CGI script for Fossil contains a "directory:" line instead of
157	a "repository:" line, then the argument to "directory:" is the name
158	of a directory that contains multiple repository files, each ending
159	with ".fossil". For example:
160	<blockquote><pre>

161	#!/usr/bin/fossil
162	directory: /home/www/repos
163	</pre></blockquote>

164	Suppose the /home/www/repos directory contains files named
165	<b>one.fossil</b>, <b>two.fossil</b>, and <b>subdir/three.fossil</b>.
166	Further suppose that the name of the CGI script (relative to the root
167	of the webserver document area) is "cgis/example2". Then to
168	see the timeline for the "three.fossil" repository, the URL would be:
169	<blockquote>
170	<b>http://example.com/cgis/example2/subdir/three/timeline</b>
171	</blockquote>


172	Here is what happens:
173	<ol>
174	<li> The input URI on the HTTP request is
175	<b>/cgis/example2/subdir/three/timeline</b>
176	<li> The web server searches prefixes of the input URI until it finds
	@@ -186,33 +197,33 @@
186	"subdir/three/" leaving it at just "timeline".
187	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
188	requested is "timeline".
189	</ol>
190	<a id="cgivar"></a>

191	The web server sets many environment variables in step 2 in addition
192	to just PATH_INFO. The following diagram shows a few of these variables
193	and their relationship to the request URL:

194	<pre>
195	REQUEST_URI
196	___________________\|_______________________
197	/ \
198	http://example.com/cgis/example2/subdir/three/timeline?c=55d7e1
199	\_________/\____________/\____________________/ \______/
200	\| \| \| \|
201	HTTP_HOST SCRIPT_NAME PATH_INFO QUERY_STRING
202	</pre>
203	</blockquote>
204	<h2>Additional CGI Script Options</h2>
205	<blockquote>
206
207	The CGI script can have additional options used to fine-tune
208	Fossil's behavior. See the [./cgi.wiki\|CGI script documentation]
209	for details.
210
211	</blockquote>
212	<h2>Additional Observations</h2>
213	<blockquote><ol type="I">
214	<li><p>
215	Fossil does not distinguish between the various HTTP methods (GET, PUT,
216	DELETE, etc). Fossil figures out what it needs to do purely from the
217	webpage term of the URI.</p></li>
218	<li><p>
	@@ -239,6 +250,5 @@
239	<li><p>
240	Fossil is itself often launched using CGI. But Fossil can also then
241	turn around and launch [./serverext.wiki\|sub-CGI scripts to implement
242	extensions].</p></li>
243	</ol>
244	</blockquote>
245

	--- www/aboutcgi.wiki
	+++ www/aboutcgi.wiki
	@@ -1,7 +1,9 @@
1	<title>How CGI Works In Fossil</title>
2
3	<h2>Introduction</h2>
4
5	CGI or "Common Gateway Interface" is a venerable yet reliable technique for
6	generating dynamic web content. This article gives a quick background on how
7	CGI works and describes how Fossil can act as a CGI service.
8
9	This is a "how it works" guide. This document provides background
	@@ -8,12 +10,12 @@
10	information on the CGI protocol so that you can better understand what
11	is going on behind the scenes. If you just want to set up Fossil
12	as a CGI server, see the [./server/ \| Fossil Server Setup] page. Or
13	if you want to development CGI-based extensions to Fossil, see
14	the [./serverext.wiki\|CGI Server Extensions] page.
15
16	<h2>A Quick Review Of CGI</h2>
17
18	An HTTP request is a block of text that is sent by a client application
19	(usually a web browser) and arrives at the web server over a network
20	connection. The HTTP request contains a URL that describes the information
21	being requested. The URL in the HTTP request is typically the same URL
	@@ -29,11 +31,13 @@
31	The web server is free to interpret the HTTP request in any way it wants.
32	But most web servers follow a similar pattern, described below.
33	(Note: details may vary from one web server to another.)
34
35	Suppose the filename component of the URL in the HTTP request looks like this:
36
37	<pre>/one/two/timeline/four</pre>
38
39	Most web servers will search their content area for files that match
40	some prefix of the URL. The search starts with <b>/one</b>, then goes to
41	<b>/one/two</b>, then <b>/one/two/timeline</b>, and finally
42	<b>/one/two/timeline/four</b> is checked. The search stops at the first
43	match.
	@@ -46,12 +50,12 @@
50	executes the <b>/one/two</b> script. The output generated by
51	the script is collected and repackaged as the HTTP reply.
52
53	Before executing the CGI script, the web server will set up various
54	environment variables with information useful to the CGI script:
55	<table>
56	<tr><th>Variable<th>Meaning
57	<tr><td>GATEWAY_INTERFACE<td>Always set to "CGI/1.0"
58	<tr><td>REQUEST_URI
59	<td>The input URL from the HTTP request.
60	<tr><td>SCRIPT_NAME
61	<td>The prefix of the input URL that matches the CGI script name.
	@@ -85,19 +89,21 @@
89	but a CGI script handles just one HTTP request and then exits.
90
91	The above is a rough outline of how CGI works.
92	There are many details omitted from this brief discussion.
93	See other on-line CGI tutorials for further information.
94
95	<h2>How Fossil Acts As A CGI Program</h2>
96
97	An appropriate CGI script for running Fossil will look something
98	like the following:
99
100	<pre>
101	#!/usr/bin/fossil
102	repository: /home/www/repos/project.fossil
103	</pre>
104
105	The first line of the script is a
106	"[https://en.wikipedia.org/wiki/Shebang_%28Unix%29\|shebang]"
107	that tells the operating system what program to use as the interpreter
108	for this script. On unix, when you execute a script that starts with
109	a shebang, the operating system runs the program identified by the
	@@ -134,20 +140,21 @@
140	exactly the same thing to Fossil:
141	<ol type='A'>
142	<li> [https://fossil-scm.org/home/info/c14ecc43]
143	<li> [https://fossil-scm.org/home/info?name=c14ecc43]
144	</ol>
145
146	In both cases, the CGI script is called "/fossil". For case (A),
147	the PATH_INFO variable will be "info/c14ecc43" and so the
148	"[/help?cmd=/info\|/info]" webpage will be generated and the suffix of
149	PATH_INFO will be converted into the "name" query parameter, which
150	identifies the artifact about which information is requested.
151	In case (B), the PATH_INFO is just "info", but the same "name"
152	query parameter is set explicitly by the URL itself.
153
154	<h2>Serving Multiple Fossil Repositories From One CGI Script</h2>
155
156	The previous example showed how to serve a single Fossil repository
157	using a single CGI script.
158	On a website that wants to serve multiple repositories, one could
159	simply create multiple CGI scripts, one script for each repository.
160	But it is also possible to serve multiple Fossil repositories from
	@@ -155,22 +162,26 @@
162
163	If the CGI script for Fossil contains a "directory:" line instead of
164	a "repository:" line, then the argument to "directory:" is the name
165	of a directory that contains multiple repository files, each ending
166	with ".fossil". For example:
167
168	<pre>
169	#!/usr/bin/fossil
170	directory: /home/www/repos
171	</pre>
172
173	Suppose the /home/www/repos directory contains files named
174	<b>one.fossil</b>, <b>two.fossil</b>, and <b>subdir/three.fossil</b>.
175	Further suppose that the name of the CGI script (relative to the root
176	of the webserver document area) is "cgis/example2". Then to
177	see the timeline for the "three.fossil" repository, the URL would be:
178
179	<pre>
180	http://example.com/cgis/example2/subdir/three/timeline
181	</pre>
182
183	Here is what happens:
184	<ol>
185	<li> The input URI on the HTTP request is
186	<b>/cgis/example2/subdir/three/timeline</b>
187	<li> The web server searches prefixes of the input URI until it finds
	@@ -186,33 +197,33 @@
197	"subdir/three/" leaving it at just "timeline".
198	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
199	requested is "timeline".
200	</ol>
201	<a id="cgivar"></a>
202
203	The web server sets many environment variables in step 2 in addition
204	to just PATH_INFO. The following diagram shows a few of these variables
205	and their relationship to the request URL:
206
207	<pre>
208	REQUEST_URI
209	___________________\|_______________________
210	/ \
211	http://example.com/cgis/example2/subdir/three/timeline?c=55d7e1
212	\_________/\____________/\____________________/ \______/
213	\| \| \| \|
214	HTTP_HOST SCRIPT_NAME PATH_INFO QUERY_STRING
215	</pre>
216
217	<h2>Additional CGI Script Options</h2>

218
219	The CGI script can have additional options used to fine-tune
220	Fossil's behavior. See the [./cgi.wiki\|CGI script documentation]
221	for details.
222

223	<h2>Additional Observations</h2>
224	<ol type="I">
225	<li><p>
226	Fossil does not distinguish between the various HTTP methods (GET, PUT,
227	DELETE, etc). Fossil figures out what it needs to do purely from the
228	webpage term of the URI.</p></li>
229	<li><p>
	@@ -239,6 +250,5 @@
250	<li><p>
251	Fossil is itself often launched using CGI. But Fossil can also then
252	turn around and launch [./serverext.wiki\|sub-CGI scripts to implement
253	extensions].</p></li>
254	</ol>

255

M www/branching.wiki

+4 -4

		--- www/branching.wiki
		+++ www/branching.wiki
		@@ -246,13 +246,13 @@
246	246	branching as intentional forking and the naming of forks as branches.
247	247	They are in fact separate concepts, but since Fossil is intended to be
248	248	used primarily by humans, we combine them in Fossil's human user
249	249	interfaces.
250	250
251		-<blockquote>
	251	+<p class="blockquote">
252	252	<b>Key Distinction:</b> A branch is a <i>named, intentional</i> fork.
253		-</blockquote>
	253	+</p>
254	254
255	255	Unnamed forks <i>may</i> be intentional, but most of the time, they're
256	256	accidental and left unnamed.
257	257
258	258	Fossil offers two primary ways to create named, intentional forks,
		@@ -695,11 +695,11 @@
695	695	painless to fix them] when they do occur.
696	696
697	697
698	698	<h2>Review Of Terminology</h2>
699	699
700		-<blockquote><dl>
	700	+<dl>
701	701	<dt><b>Branch</b></dt>
702	702	<dd><p>A branch is a set of check-ins with the same value for their
703	703	"branch" property.</p></dd>
704	704	<dt><b>Leaf</b></dt>
705	705	<dd><p>A leaf is a check-in with no children in the same branch.</p></dd>
		@@ -714,11 +714,11 @@
714	714	children in the same branch.</p></dd>
715	715	<dt><b>Branch Point</b></dt>
716	716	<dd><p>A branch point occurs when a check-in has two or more direct (non-merge)
717	717	children in different branches. A branch point is similar to a fork,
718	718	except that the children are in different branches.</p></dd>
719		-</dl></blockquote>
	719	+</dl>
720	720
721	721	Check-in 4 of Figure 3 is not a leaf because it has a child (check-in 5)
722	722	in the same branch. Check-in 9 of Figure 5 also has a child (check-in 10)
723	723	but that child is in a different branch, so check-in 9 is a leaf. Because
724	724	of the <b>closed</b> tag on check-in 9, it is a closed leaf.
725	725

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -246,13 +246,13 @@
246	branching as intentional forking and the naming of forks as branches.
247	They are in fact separate concepts, but since Fossil is intended to be
248	used primarily by humans, we combine them in Fossil's human user
249	interfaces.
250
251	<blockquote>
252	<b>Key Distinction:</b> A branch is a <i>named, intentional</i> fork.
253	</blockquote>
254
255	Unnamed forks <i>may</i> be intentional, but most of the time, they're
256	accidental and left unnamed.
257
258	Fossil offers two primary ways to create named, intentional forks,
	@@ -695,11 +695,11 @@
695	painless to fix them] when they do occur.
696
697
698	<h2>Review Of Terminology</h2>
699
700	<blockquote><dl>
701	<dt><b>Branch</b></dt>
702	<dd><p>A branch is a set of check-ins with the same value for their
703	"branch" property.</p></dd>
704	<dt><b>Leaf</b></dt>
705	<dd><p>A leaf is a check-in with no children in the same branch.</p></dd>
	@@ -714,11 +714,11 @@
714	children in the same branch.</p></dd>
715	<dt><b>Branch Point</b></dt>
716	<dd><p>A branch point occurs when a check-in has two or more direct (non-merge)
717	children in different branches. A branch point is similar to a fork,
718	except that the children are in different branches.</p></dd>
719	</dl></blockquote>
720
721	Check-in 4 of Figure 3 is not a leaf because it has a child (check-in 5)
722	in the same branch. Check-in 9 of Figure 5 also has a child (check-in 10)
723	but that child is in a different branch, so check-in 9 is a leaf. Because
724	of the <b>closed</b> tag on check-in 9, it is a closed leaf.
725

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -246,13 +246,13 @@
246	branching as intentional forking and the naming of forks as branches.
247	They are in fact separate concepts, but since Fossil is intended to be
248	used primarily by humans, we combine them in Fossil's human user
249	interfaces.
250
251	<p class="blockquote">
252	<b>Key Distinction:</b> A branch is a <i>named, intentional</i> fork.
253	</p>
254
255	Unnamed forks <i>may</i> be intentional, but most of the time, they're
256	accidental and left unnamed.
257
258	Fossil offers two primary ways to create named, intentional forks,
	@@ -695,11 +695,11 @@
695	painless to fix them] when they do occur.
696
697
698	<h2>Review Of Terminology</h2>
699
700	<dl>
701	<dt><b>Branch</b></dt>
702	<dd><p>A branch is a set of check-ins with the same value for their
703	"branch" property.</p></dd>
704	<dt><b>Leaf</b></dt>
705	<dd><p>A leaf is a check-in with no children in the same branch.</p></dd>
	@@ -714,11 +714,11 @@
714	children in the same branch.</p></dd>
715	<dt><b>Branch Point</b></dt>
716	<dd><p>A branch point occurs when a check-in has two or more direct (non-merge)
717	children in different branches. A branch point is similar to a fork,
718	except that the children are in different branches.</p></dd>
719	</dl>
720
721	Check-in 4 of Figure 3 is not a leaf because it has a child (check-in 5)
722	in the same branch. Check-in 9 of Figure 5 also has a child (check-in 10)
723	but that child is in a different branch, so check-in 9 is a leaf. Because
724	of the <b>closed</b> tag on check-in 9, it is a closed leaf.
725

M www/cgi.wiki

+2 -2

		--- www/cgi.wiki
		+++ www/cgi.wiki
		@@ -23,14 +23,14 @@
23	23	<h1>CGI Script Options</h1>
24	24
25	25	The CGI script used to launch a Fossil server will usually look something
26	26	like this:
27	27
28		-<blockquote><verbatim>
	28	+<verbatim>
29	29	#!/usr/bin/fossil
30	30	repository: /home/www/fossils/myproject.fossil
31		-</verbatim></blockquote>
	31	+</verbatim>
32	32
33	33	Of course, pathnames will likely be different. The first line
34	34	(the "[wikipedia:/wiki/Shebang_(Unix)\|shebang]")
35	35	always gives the name of the Fossil executable. Subsequent lines are of
36	36	the form "<b>property: argument ...</b>".
37	37

	--- www/cgi.wiki
	+++ www/cgi.wiki
	@@ -23,14 +23,14 @@
23	<h1>CGI Script Options</h1>
24
25	The CGI script used to launch a Fossil server will usually look something
26	like this:
27
28	<blockquote><verbatim>
29	#!/usr/bin/fossil
30	repository: /home/www/fossils/myproject.fossil
31	</verbatim></blockquote>
32
33	Of course, pathnames will likely be different. The first line
34	(the "[wikipedia:/wiki/Shebang_(Unix)\|shebang]")
35	always gives the name of the Fossil executable. Subsequent lines are of
36	the form "<b>property: argument ...</b>".
37

	--- www/cgi.wiki
	+++ www/cgi.wiki
	@@ -23,14 +23,14 @@
23	<h1>CGI Script Options</h1>
24
25	The CGI script used to launch a Fossil server will usually look something
26	like this:
27
28	<verbatim>
29	#!/usr/bin/fossil
30	repository: /home/www/fossils/myproject.fossil
31	</verbatim>
32
33	Of course, pathnames will likely be different. The first line
34	(the "[wikipedia:/wiki/Shebang_(Unix)\|shebang]")
35	always gives the name of the Fossil executable. Subsequent lines are of
36	the form "<b>property: argument ...</b>".
37

M www/checkin_names.wiki

+41 -41

		--- www/checkin_names.wiki
		+++ www/checkin_names.wiki
		@@ -1,10 +1,9 @@
1	1	<title>Check-in Names</title>
2	2
3		-<table align="right" width="33%">
4		-<tr><td>
5		-<h3>Quick Reference</h3>
	3	+<div class="sidebar no-label">
	4	+<b>Quick Reference</b>
6	5	<ul>
7	6	<li> Hash prefix
8	7	<li> Branch name
9	8	<li> Tag name
10	9	<li> Timestamp: <i>YYYY-MM-DD HH:MM:SS</i>
		@@ -19,30 +18,30 @@
19	18	<li> <b>next</b>
20	19	<li> <b>previous</b> or <b>prev</b>
21	20	<li> <b>ckout</b> (<a href='./embeddeddoc.wiki'>embedded docs</a> only)
22	21	</ul>
23	22	</ul>
24		-</td></tr>
25		-</table>
	23	+</div>
26	24
27	25	Many Fossil [/help\|commands] and [./webui.wiki \| web interface] URLs accept
28	26	check-in names as an argument. For example, the "[/help/info\|info]" command
29	27	accepts an optional check-in name to identify the specific check-in
30	28	about which information is desired:
31	29
32		-<blockquote>
33		-<tt>fossil info</tt> <i>checkin-name</i>
34		-</blockquote>
	30	+<pre>
	31	+fossil info< <i>checkin-name</i>
	32	+</pre>
35	33
36	34	You are perhaps reading this page from the following URL:
37	35
38		-<blockquote>
39		-https://fossil-scm.org/home/doc/<b>trunk</b>/www/checkin_names.wiki
40		-</blockquote>
	36	+<verbatim>
	37	+https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki
	38	+</verbatim>
41	39
42		-The URL above is an example of an [./embeddeddoc.wiki \| embedded documentation]
43		-page in Fossil. The bold term of the pathname is a check-in name that
	40	+This is an example of an [./embeddeddoc.wiki \| embedded documentation]
	41	+page URL. The "trunk" element of the pathname is a
	42	+[./glossary.md#check-in \| check-in] name that
44	43	determines which version of the documentation to display.
45	44
46	45	Fossil provides a variety of ways to specify a check-in. This
47	46	document describes the various methods.
48	47
		@@ -50,49 +49,50 @@
50	49
51	50	The canonical name of a check-in is the hash of its
52	51	[./fileformat.wiki#manifest \| manifest] expressed as a
53	52	[./hashes.md \| long lowercase hexadecimal number]. For example:
54	53
55		-<blockquote><pre>
	54	+<pre>
56	55	fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
57		-</pre></blockquote>
	56	+</pre>
58	57
59	58	The full 40 or 64 character hash is unwieldy to remember and type, though,
60	59	so Fossil also accepts a unique prefix of the hash, using any combination
61	60	of upper and lower case letters, as long as the prefix is at least 4
62	61	characters long. Hence the following commands all
63	62	accomplish the same thing as the above:
64	63
65		-<blockquote><pre>
	64	+<pre>
66	65	fossil info e5a734a19a9
67	66	fossil info E5a734A
68	67	fossil info e5a7
69		-</blockquote>
	68	+</pre>
70	69
71		-Many web interface screens identify check-ins by 10- or 16-character
72		-prefix of canonical name.
	70	+Fossil uses this feature itself, identifying check-ins by 8 to 16-character
	71	+prefixes of the canonical name in places where it doesn't want to chew
	72	+up the screen real estate required to display the whole hash.
73	73
74	74	<h2 id="tags">Tags And Branch Names</h2>
75	75
76	76	Using a tag or branch name where a check-in name is expected causes
77	77	Fossil to choose the most recent check-in with that tag or branch name.
78	78	So for example, the most recent check-in that
79	79	is tagged with "release" as of this writing is [b98ce23d4fc].
80	80	The command:
81	81
82		-<blockquote><pre>
	82	+<pre>
83	83	fossil info release
84		-</pre></blockquote>
	84	+</pre>
85	85
86	86	…results in the following output:
87	87
88		-<blockquote><pre>
	88	+<pre>
89	89	hash: b98ce23d4fc3b734cdc058ee8a67e6dad675ca13 2020-08-20 13:27:04 UTC
90	90	parent: 40feec329163103293d98dfcc2d119d1a16b227a 2020-08-20 13:01:51 UTC
91	91	tags: release, branch-2.12, version-2.12.1
92	92	comment: Version 2.12.1 (user: drh)
93		-</pre></blockquote>
	93	+</pre>
94	94
95	95	There are multiple check-ins that are tagged with "release" but
96	96	(as of this writing) the [b98ce23d4fc]
97	97	check-in is the most recent so it is the one that is selected.
98	98
		@@ -108,13 +108,13 @@
108	108	also happened to have tagged a different check-in with "deed2". If
109	109	you use the "deed2" name, does it choose the canonical name or the tag
110	110	name? In such cases, you can prefix the tag name with "tag:".
111	111	For example:
112	112
113		-<blockquote><tt>
	113	+<pre>
114	114	fossil info tag:deed2
115		-</tt></blockquote>
	115	+</pre>
116	116
117	117	The "tag:deed2" name will refer to the most recent check-in
118	118	tagged with "deed2" rather than the
119	119	check-in whose canonical name begins with "deed2".
120	120
		@@ -181,21 +181,21 @@
181	181	rather than as a tag by passing “date:2020-04-01”.
182	182
183	183	For an example of how timestamps are useful,
184	184	consider the homepage for the Fossil website itself:
185	185
186		-<blockquote>
	186	+<pre>
187	187	https://fossil-scm.org/home/doc/<b>trunk</b>/www/index.wiki
188		-</blockquote>
	188	+</pre>
189	189
190	190	The bold component of that URL is a check-in name. To see the stored content
191	191	of the Fossil website repository as of January 1, 2009, one has merely to change
192	192	the URL to the following:
193	193
194		-<blockquote>
	194	+<pre>
195	195	https://fossil-scm.org/home/doc/<b>2009-01-01</b>/www/index.wiki
196		-</blockquote>
	196	+</pre>
197	197
198	198	(Note that this won't roll you back to the <i>skin</i> and other
199	199	cosmetic configurations as of that date. It also won't change screens
200	200	like the timeline, which has an independent date selector.)
201	201
		@@ -204,13 +204,13 @@
204	204	A check-in name can also take the form of a tag or branch name followed by
205	205	a colon and then a timestamp. The combination means to take the most
206	206	recent check-in with the given tag or branch which is not more recent than
207	207	the timestamp. So, for example:
208	208
209		-<blockquote><tt>
	209	+<pre>
210	210	fossil update trunk:2010-07-01T14:30
211		-</tt></blockquote>
	211	+</pre>
212	212
213	213	Would cause Fossil to update the working check-out to be the most recent
214	214	check-in on the trunk that is not more recent than 14:30 (UTC) on
215	215	July 1, 2010.
216	216
		@@ -220,13 +220,13 @@
220	220	last check-in on the parent branch prior to the beginning of the branch.
221	221	Such a label is useful, for example, in computing all diffs for a single
222	222	branch. The following example will show all changes in the hypothetical
223	223	branch "xyzzy":
224	224
225		-<blockquote><tt>
	225	+<pre>
226	226	fossil diff --from root:xyzzy --to xyzzy
227		-</tt></blockquote>
	227	+</pre>
228	228
229	229	<a id="merge-in"></a>
230	230	That doesn't do what you might expect after you merge the parent
231	231	branch's changes into the child branch: the above command will include
232	232	changes made on the parent branch as well.
		@@ -242,13 +242,13 @@
242	242	The prefix "<tt>start:</tt>" gives the first check-in of the named branch.
243	243
244	244	The prefixes "<tt>root:</tt>", "<tt>start:</tt>", and "<tt>merge-in:</tt>"
245	245	can be chained: one can say for example
246	246
247		-<blockquote><tt>
	247	+<pre>
248	248	fossil info merge-in:xyzzy:2022-03-01
249		-</tt></blockquote>
	249	+</pre>
250	250
251	251	to get informations about the most recent merge-in point on the branch
252	252	"xyzzy" that happened on or before March 1, 2022.
253	253
254	254	<h2 id="special">Special Tags</h2>
		@@ -257,13 +257,13 @@
257	257	equivalent to the timestamp "9999-12-31".
258	258
259	259	This special name works anywhere you can pass a "NAME", such as with
260	260	<tt>/info</tt> URLs:
261	261
262		-<blockquote><pre>
	262	+<pre>
263	263	http://localhost:8080/info/tip
264		-</pre></blockquote>
	264	+</pre>
265	265
266	266	There are several other special names, but they only work from within a
267	267	check-out directory because they are relative to the current checked-out
268	268	version:
269	269
		@@ -283,20 +283,20 @@
283	283	<h2 id="examples">Additional Examples</h2>
284	284
285	285	To view the changes in the most recent check-in prior to the version currently
286	286	checked out:
287	287
288		-<blockquote><pre>
	288	+<pre>
289	289	fossil diff --from previous --to current
290		-</pre></blockquote>
	290	+</pre>
291	291
292	292	Suppose you are of the habit of tagging each release with a "release" tag.
293	293	Then to see everything that has changed on the trunk since the last release:
294	294
295		-<blockquote><pre>
	295	+<pre>
296	296	fossil diff --from release --to trunk
297		-</pre></blockquote>
	297	+</pre>
298	298
299	299
300	300	<h2 id="order">Resolution Order</h2>
301	301
302	302	Fossil currently resolves name strings to artifact hashes in the
303	303

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -1,10 +1,9 @@
1	<title>Check-in Names</title>
2
3	<table align="right" width="33%">
4	<tr><td>
5	<h3>Quick Reference</h3>
6	<ul>
7	<li> Hash prefix
8	<li> Branch name
9	<li> Tag name
10	<li> Timestamp: <i>YYYY-MM-DD HH:MM:SS</i>
	@@ -19,30 +18,30 @@
19	<li> <b>next</b>
20	<li> <b>previous</b> or <b>prev</b>
21	<li> <b>ckout</b> (<a href='./embeddeddoc.wiki'>embedded docs</a> only)
22	</ul>
23	</ul>
24	</td></tr>
25	</table>
26
27	Many Fossil [/help\|commands] and [./webui.wiki \| web interface] URLs accept
28	check-in names as an argument. For example, the "[/help/info\|info]" command
29	accepts an optional check-in name to identify the specific check-in
30	about which information is desired:
31
32	<blockquote>
33	<tt>fossil info</tt> <i>checkin-name</i>
34	</blockquote>
35
36	You are perhaps reading this page from the following URL:
37
38	<blockquote>
39	https://fossil-scm.org/home/doc/<b>trunk</b>/www/checkin_names.wiki
40	</blockquote>
41
42	The URL above is an example of an [./embeddeddoc.wiki \| embedded documentation]
43	page in Fossil. The bold term of the pathname is a check-in name that

44	determines which version of the documentation to display.
45
46	Fossil provides a variety of ways to specify a check-in. This
47	document describes the various methods.
48
	@@ -50,49 +49,50 @@
50
51	The canonical name of a check-in is the hash of its
52	[./fileformat.wiki#manifest \| manifest] expressed as a
53	[./hashes.md \| long lowercase hexadecimal number]. For example:
54
55	<blockquote><pre>
56	fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
57	</pre></blockquote>
58
59	The full 40 or 64 character hash is unwieldy to remember and type, though,
60	so Fossil also accepts a unique prefix of the hash, using any combination
61	of upper and lower case letters, as long as the prefix is at least 4
62	characters long. Hence the following commands all
63	accomplish the same thing as the above:
64
65	<blockquote><pre>
66	fossil info e5a734a19a9
67	fossil info E5a734A
68	fossil info e5a7
69	</blockquote>
70
71	Many web interface screens identify check-ins by 10- or 16-character
72	prefix of canonical name.

73
74	<h2 id="tags">Tags And Branch Names</h2>
75
76	Using a tag or branch name where a check-in name is expected causes
77	Fossil to choose the most recent check-in with that tag or branch name.
78	So for example, the most recent check-in that
79	is tagged with "release" as of this writing is [b98ce23d4fc].
80	The command:
81
82	<blockquote><pre>
83	fossil info release
84	</pre></blockquote>
85
86	…results in the following output:
87
88	<blockquote><pre>
89	hash: b98ce23d4fc3b734cdc058ee8a67e6dad675ca13 2020-08-20 13:27:04 UTC
90	parent: 40feec329163103293d98dfcc2d119d1a16b227a 2020-08-20 13:01:51 UTC
91	tags: release, branch-2.12, version-2.12.1
92	comment: Version 2.12.1 (user: drh)
93	</pre></blockquote>
94
95	There are multiple check-ins that are tagged with "release" but
96	(as of this writing) the [b98ce23d4fc]
97	check-in is the most recent so it is the one that is selected.
98
	@@ -108,13 +108,13 @@
108	also happened to have tagged a different check-in with "deed2". If
109	you use the "deed2" name, does it choose the canonical name or the tag
110	name? In such cases, you can prefix the tag name with "tag:".
111	For example:
112
113	<blockquote><tt>
114	fossil info tag:deed2
115	</tt></blockquote>
116
117	The "tag:deed2" name will refer to the most recent check-in
118	tagged with "deed2" rather than the
119	check-in whose canonical name begins with "deed2".
120
	@@ -181,21 +181,21 @@
181	rather than as a tag by passing “date:2020-04-01”.
182
183	For an example of how timestamps are useful,
184	consider the homepage for the Fossil website itself:
185
186	<blockquote>
187	https://fossil-scm.org/home/doc/<b>trunk</b>/www/index.wiki
188	</blockquote>
189
190	The bold component of that URL is a check-in name. To see the stored content
191	of the Fossil website repository as of January 1, 2009, one has merely to change
192	the URL to the following:
193
194	<blockquote>
195	https://fossil-scm.org/home/doc/<b>2009-01-01</b>/www/index.wiki
196	</blockquote>
197
198	(Note that this won't roll you back to the <i>skin</i> and other
199	cosmetic configurations as of that date. It also won't change screens
200	like the timeline, which has an independent date selector.)
201
	@@ -204,13 +204,13 @@
204	A check-in name can also take the form of a tag or branch name followed by
205	a colon and then a timestamp. The combination means to take the most
206	recent check-in with the given tag or branch which is not more recent than
207	the timestamp. So, for example:
208
209	<blockquote><tt>
210	fossil update trunk:2010-07-01T14:30
211	</tt></blockquote>
212
213	Would cause Fossil to update the working check-out to be the most recent
214	check-in on the trunk that is not more recent than 14:30 (UTC) on
215	July 1, 2010.
216
	@@ -220,13 +220,13 @@
220	last check-in on the parent branch prior to the beginning of the branch.
221	Such a label is useful, for example, in computing all diffs for a single
222	branch. The following example will show all changes in the hypothetical
223	branch "xyzzy":
224
225	<blockquote><tt>
226	fossil diff --from root:xyzzy --to xyzzy
227	</tt></blockquote>
228
229	<a id="merge-in"></a>
230	That doesn't do what you might expect after you merge the parent
231	branch's changes into the child branch: the above command will include
232	changes made on the parent branch as well.
	@@ -242,13 +242,13 @@
242	The prefix "<tt>start:</tt>" gives the first check-in of the named branch.
243
244	The prefixes "<tt>root:</tt>", "<tt>start:</tt>", and "<tt>merge-in:</tt>"
245	can be chained: one can say for example
246
247	<blockquote><tt>
248	fossil info merge-in:xyzzy:2022-03-01
249	</tt></blockquote>
250
251	to get informations about the most recent merge-in point on the branch
252	"xyzzy" that happened on or before March 1, 2022.
253
254	<h2 id="special">Special Tags</h2>
	@@ -257,13 +257,13 @@
257	equivalent to the timestamp "9999-12-31".
258
259	This special name works anywhere you can pass a "NAME", such as with
260	<tt>/info</tt> URLs:
261
262	<blockquote><pre>
263	http://localhost:8080/info/tip
264	</pre></blockquote>
265
266	There are several other special names, but they only work from within a
267	check-out directory because they are relative to the current checked-out
268	version:
269
	@@ -283,20 +283,20 @@
283	<h2 id="examples">Additional Examples</h2>
284
285	To view the changes in the most recent check-in prior to the version currently
286	checked out:
287
288	<blockquote><pre>
289	fossil diff --from previous --to current
290	</pre></blockquote>
291
292	Suppose you are of the habit of tagging each release with a "release" tag.
293	Then to see everything that has changed on the trunk since the last release:
294
295	<blockquote><pre>
296	fossil diff --from release --to trunk
297	</pre></blockquote>
298
299
300	<h2 id="order">Resolution Order</h2>
301
302	Fossil currently resolves name strings to artifact hashes in the
303

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -1,10 +1,9 @@
1	<title>Check-in Names</title>
2
3	<div class="sidebar no-label">
4	<b>Quick Reference</b>

5	<ul>
6	<li> Hash prefix
7	<li> Branch name
8	<li> Tag name
9	<li> Timestamp: <i>YYYY-MM-DD HH:MM:SS</i>
	@@ -19,30 +18,30 @@
18	<li> <b>next</b>
19	<li> <b>previous</b> or <b>prev</b>
20	<li> <b>ckout</b> (<a href='./embeddeddoc.wiki'>embedded docs</a> only)
21	</ul>
22	</ul>
23	</div>

24
25	Many Fossil [/help\|commands] and [./webui.wiki \| web interface] URLs accept
26	check-in names as an argument. For example, the "[/help/info\|info]" command
27	accepts an optional check-in name to identify the specific check-in
28	about which information is desired:
29
30	<pre>
31	fossil info< <i>checkin-name</i>
32	</pre>
33
34	You are perhaps reading this page from the following URL:
35
36	<verbatim>
37	https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki
38	</verbatim>
39
40	This is an example of an [./embeddeddoc.wiki \| embedded documentation]
41	page URL. The "trunk" element of the pathname is a
42	[./glossary.md#check-in \| check-in] name that
43	determines which version of the documentation to display.
44
45	Fossil provides a variety of ways to specify a check-in. This
46	document describes the various methods.
47
	@@ -50,49 +49,50 @@
49
50	The canonical name of a check-in is the hash of its
51	[./fileformat.wiki#manifest \| manifest] expressed as a
52	[./hashes.md \| long lowercase hexadecimal number]. For example:
53
54	<pre>
55	fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9
56	</pre>
57
58	The full 40 or 64 character hash is unwieldy to remember and type, though,
59	so Fossil also accepts a unique prefix of the hash, using any combination
60	of upper and lower case letters, as long as the prefix is at least 4
61	characters long. Hence the following commands all
62	accomplish the same thing as the above:
63
64	<pre>
65	fossil info e5a734a19a9
66	fossil info E5a734A
67	fossil info e5a7
68	</pre>
69
70	Fossil uses this feature itself, identifying check-ins by 8 to 16-character
71	prefixes of the canonical name in places where it doesn't want to chew
72	up the screen real estate required to display the whole hash.
73
74	<h2 id="tags">Tags And Branch Names</h2>
75
76	Using a tag or branch name where a check-in name is expected causes
77	Fossil to choose the most recent check-in with that tag or branch name.
78	So for example, the most recent check-in that
79	is tagged with "release" as of this writing is [b98ce23d4fc].
80	The command:
81
82	<pre>
83	fossil info release
84	</pre>
85
86	…results in the following output:
87
88	<pre>
89	hash: b98ce23d4fc3b734cdc058ee8a67e6dad675ca13 2020-08-20 13:27:04 UTC
90	parent: 40feec329163103293d98dfcc2d119d1a16b227a 2020-08-20 13:01:51 UTC
91	tags: release, branch-2.12, version-2.12.1
92	comment: Version 2.12.1 (user: drh)
93	</pre>
94
95	There are multiple check-ins that are tagged with "release" but
96	(as of this writing) the [b98ce23d4fc]
97	check-in is the most recent so it is the one that is selected.
98
	@@ -108,13 +108,13 @@
108	also happened to have tagged a different check-in with "deed2". If
109	you use the "deed2" name, does it choose the canonical name or the tag
110	name? In such cases, you can prefix the tag name with "tag:".
111	For example:
112
113	<pre>
114	fossil info tag:deed2
115	</pre>
116
117	The "tag:deed2" name will refer to the most recent check-in
118	tagged with "deed2" rather than the
119	check-in whose canonical name begins with "deed2".
120
	@@ -181,21 +181,21 @@
181	rather than as a tag by passing “date:2020-04-01”.
182
183	For an example of how timestamps are useful,
184	consider the homepage for the Fossil website itself:
185
186	<pre>
187	https://fossil-scm.org/home/doc/<b>trunk</b>/www/index.wiki
188	</pre>
189
190	The bold component of that URL is a check-in name. To see the stored content
191	of the Fossil website repository as of January 1, 2009, one has merely to change
192	the URL to the following:
193
194	<pre>
195	https://fossil-scm.org/home/doc/<b>2009-01-01</b>/www/index.wiki
196	</pre>
197
198	(Note that this won't roll you back to the <i>skin</i> and other
199	cosmetic configurations as of that date. It also won't change screens
200	like the timeline, which has an independent date selector.)
201
	@@ -204,13 +204,13 @@
204	A check-in name can also take the form of a tag or branch name followed by
205	a colon and then a timestamp. The combination means to take the most
206	recent check-in with the given tag or branch which is not more recent than
207	the timestamp. So, for example:
208
209	<pre>
210	fossil update trunk:2010-07-01T14:30
211	</pre>
212
213	Would cause Fossil to update the working check-out to be the most recent
214	check-in on the trunk that is not more recent than 14:30 (UTC) on
215	July 1, 2010.
216
	@@ -220,13 +220,13 @@
220	last check-in on the parent branch prior to the beginning of the branch.
221	Such a label is useful, for example, in computing all diffs for a single
222	branch. The following example will show all changes in the hypothetical
223	branch "xyzzy":
224
225	<pre>
226	fossil diff --from root:xyzzy --to xyzzy
227	</pre>
228
229	<a id="merge-in"></a>
230	That doesn't do what you might expect after you merge the parent
231	branch's changes into the child branch: the above command will include
232	changes made on the parent branch as well.
	@@ -242,13 +242,13 @@
242	The prefix "<tt>start:</tt>" gives the first check-in of the named branch.
243
244	The prefixes "<tt>root:</tt>", "<tt>start:</tt>", and "<tt>merge-in:</tt>"
245	can be chained: one can say for example
246
247	<pre>
248	fossil info merge-in:xyzzy:2022-03-01
249	</pre>
250
251	to get informations about the most recent merge-in point on the branch
252	"xyzzy" that happened on or before March 1, 2022.
253
254	<h2 id="special">Special Tags</h2>
	@@ -257,13 +257,13 @@
257	equivalent to the timestamp "9999-12-31".
258
259	This special name works anywhere you can pass a "NAME", such as with
260	<tt>/info</tt> URLs:
261
262	<pre>
263	http://localhost:8080/info/tip
264	</pre>
265
266	There are several other special names, but they only work from within a
267	check-out directory because they are relative to the current checked-out
268	version:
269
	@@ -283,20 +283,20 @@
283	<h2 id="examples">Additional Examples</h2>
284
285	To view the changes in the most recent check-in prior to the version currently
286	checked out:
287
288	<pre>
289	fossil diff --from previous --to current
290	</pre>
291
292	Suppose you are of the habit of tagging each release with a "release" tag.
293	Then to see everything that has changed on the trunk since the last release:
294
295	<pre>
296	fossil diff --from release --to trunk
297	</pre>
298
299
300	<h2 id="order">Resolution Order</h2>
301
302	Fossil currently resolves name strings to artifact hashes in the
303

M www/childprojects.wiki

+2 -2

		--- www/childprojects.wiki
		+++ www/childprojects.wiki
		@@ -28,18 +28,18 @@
28	28	<h2>Creating a Child Project</h2>
29	29
30	30	To create a new child project, first clone the parent. Then make manual
31	31	SQL changes to the child repository as follows:
32	32
33		-<blockquote><verbatim>
	33	+<verbatim>
34	34	UPDATE config SET name='parent-project-code' WHERE name='project-code';
35	35	UPDATE config SET name='parent-project-name' WHERE name='project-name';
36	36	INSERT INTO config(name,value)
37	37	VALUES('project-code',lower(hex(randomblob(20))));
38	38	INSERT INTO config(name,value)
39	39	VALUES('project-name','CHILD-PROJECT-NAME');
40		-</verbatim></blockquote>
	40	+</verbatim>
41	41
42	42	Modify the CHILD-PROJECT-NAME in the last statement to be the name of
43	43	the child project, of course.
44	44
45	45	The repository is now a separate project, independent from its parent.
46	46

	--- www/childprojects.wiki
	+++ www/childprojects.wiki
	@@ -28,18 +28,18 @@
28	<h2>Creating a Child Project</h2>
29
30	To create a new child project, first clone the parent. Then make manual
31	SQL changes to the child repository as follows:
32
33	<blockquote><verbatim>
34	UPDATE config SET name='parent-project-code' WHERE name='project-code';
35	UPDATE config SET name='parent-project-name' WHERE name='project-name';
36	INSERT INTO config(name,value)
37	VALUES('project-code',lower(hex(randomblob(20))));
38	INSERT INTO config(name,value)
39	VALUES('project-name','CHILD-PROJECT-NAME');
40	</verbatim></blockquote>
41
42	Modify the CHILD-PROJECT-NAME in the last statement to be the name of
43	the child project, of course.
44
45	The repository is now a separate project, independent from its parent.
46

	--- www/childprojects.wiki
	+++ www/childprojects.wiki
	@@ -28,18 +28,18 @@
28	<h2>Creating a Child Project</h2>
29
30	To create a new child project, first clone the parent. Then make manual
31	SQL changes to the child repository as follows:
32
33	<verbatim>
34	UPDATE config SET name='parent-project-code' WHERE name='project-code';
35	UPDATE config SET name='parent-project-name' WHERE name='project-name';
36	INSERT INTO config(name,value)
37	VALUES('project-code',lower(hex(randomblob(20))));
38	INSERT INTO config(name,value)
39	VALUES('project-name','CHILD-PROJECT-NAME');
40	</verbatim>
41
42	Modify the CHILD-PROJECT-NAME in the last statement to be the name of
43	the child project, of course.
44
45	The repository is now a separate project, independent from its parent.
46

M www/concepts.wiki

+12 -14

		--- www/concepts.wiki
		+++ www/concepts.wiki
		@@ -114,17 +114,17 @@
114	114	it is computationally intractable to generate a file that will have that
115	115	same artifact ID.
116	116
117	117	Artifact IDs look something like this:
118	118
119		-<blockquote><b>
120		-6089f0b563a9db0a6d90682fe47fd7161ff867c8<br>
121		-59712614a1b3ccfd84078a37fa5b606e28434326<br>
122		-19dbf73078be9779edd6a0156195e610f81c94f9<br>
123		-b4104959a67175f02d6b415480be22a239f1f077<br>
	119	+<pre>
	120	+6089f0b563a9db0a6d90682fe47fd7161ff867c8
	121	+59712614a1b3ccfd84078a37fa5b606e28434326
	122	+19dbf73078be9779edd6a0156195e610f81c94f9
	123	+b4104959a67175f02d6b415480be22a239f1f077
124	124	997c9d6ae03ad114b2b57f04e9eeef17dcb82788
125		-</b></blockquote>
	125	+</pre>
126	126
127	127	When referring to an artifact using Fossil, you can use a unique
128	128	prefix of the artifact ID that is four characters or longer. This saves
129	129	a lot of typing. When displaying artifact IDs, Fossil will usually only
130	130	show the first 10 digits since that is normally enough to uniquely
		@@ -238,13 +238,11 @@
238	238
239	239	To use Fossil, simply type the name of the executable in your
240	240	shell, followed by one of the various built-in commands and
241	241	arguments appropriate for that command. For example:
242	242
243		-<blockquote><b>
244		-fossil help
245		-</b></blockquote>
	243	+<pre>fossil help</pre>
246	244
247	245	In the next section, when we say things like "use the <b>help</b>
248	246	command" we mean to use the command name "help" as the first
249	247	token after the name of the Fossil executable, as shown above.
250	248
		@@ -281,15 +279,15 @@
281	279
282	280	The default setting for Fossil is to be in autosync mode. You
283	281	can change the autosync setting or check the current autosync
284	282	setting using commands like:
285	283
286		-<blockquote>
287		-<b>fossil setting autosync on<br>
288		-fossil setting autosync off<br>
289		-<b>fossil settings</b>
290		-</blockquote>
	284	+<pre>
	285	+fossil setting autosync on
	286	+fossil setting autosync off
	287	+fossil settings
	288	+</pre>
291	289
292	290	By default, Fossil runs with autosync mode turned on. The
293	291	authors finds that projects run more smoothly in autosync mode since
294	292	autosync helps to prevent pointless forking and merging and helps keeps
295	293	all collaborators working on exactly the same code rather than on their
296	294

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -114,17 +114,17 @@
114	it is computationally intractable to generate a file that will have that
115	same artifact ID.
116
117	Artifact IDs look something like this:
118
119	<blockquote><b>
120	6089f0b563a9db0a6d90682fe47fd7161ff867c8<br>
121	59712614a1b3ccfd84078a37fa5b606e28434326<br>
122	19dbf73078be9779edd6a0156195e610f81c94f9<br>
123	b4104959a67175f02d6b415480be22a239f1f077<br>
124	997c9d6ae03ad114b2b57f04e9eeef17dcb82788
125	</b></blockquote>
126
127	When referring to an artifact using Fossil, you can use a unique
128	prefix of the artifact ID that is four characters or longer. This saves
129	a lot of typing. When displaying artifact IDs, Fossil will usually only
130	show the first 10 digits since that is normally enough to uniquely
	@@ -238,13 +238,11 @@
238
239	To use Fossil, simply type the name of the executable in your
240	shell, followed by one of the various built-in commands and
241	arguments appropriate for that command. For example:
242
243	<blockquote><b>
244	fossil help
245	</b></blockquote>
246
247	In the next section, when we say things like "use the <b>help</b>
248	command" we mean to use the command name "help" as the first
249	token after the name of the Fossil executable, as shown above.
250
	@@ -281,15 +279,15 @@
281
282	The default setting for Fossil is to be in autosync mode. You
283	can change the autosync setting or check the current autosync
284	setting using commands like:
285
286	<blockquote>
287	<b>fossil setting autosync on<br>
288	fossil setting autosync off<br>
289	<b>fossil settings</b>
290	</blockquote>
291
292	By default, Fossil runs with autosync mode turned on. The
293	authors finds that projects run more smoothly in autosync mode since
294	autosync helps to prevent pointless forking and merging and helps keeps
295	all collaborators working on exactly the same code rather than on their
296

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -114,17 +114,17 @@
114	it is computationally intractable to generate a file that will have that
115	same artifact ID.
116
117	Artifact IDs look something like this:
118
119	<pre>
120	6089f0b563a9db0a6d90682fe47fd7161ff867c8
121	59712614a1b3ccfd84078a37fa5b606e28434326
122	19dbf73078be9779edd6a0156195e610f81c94f9
123	b4104959a67175f02d6b415480be22a239f1f077
124	997c9d6ae03ad114b2b57f04e9eeef17dcb82788
125	</pre>
126
127	When referring to an artifact using Fossil, you can use a unique
128	prefix of the artifact ID that is four characters or longer. This saves
129	a lot of typing. When displaying artifact IDs, Fossil will usually only
130	show the first 10 digits since that is normally enough to uniquely
	@@ -238,13 +238,11 @@
238
239	To use Fossil, simply type the name of the executable in your
240	shell, followed by one of the various built-in commands and
241	arguments appropriate for that command. For example:
242
243	<pre>fossil help</pre>


244
245	In the next section, when we say things like "use the <b>help</b>
246	command" we mean to use the command name "help" as the first
247	token after the name of the Fossil executable, as shown above.
248
	@@ -281,15 +279,15 @@
279
280	The default setting for Fossil is to be in autosync mode. You
281	can change the autosync setting or check the current autosync
282	setting using commands like:
283
284	<pre>
285	fossil setting autosync on
286	fossil setting autosync off
287	fossil settings
288	</pre>
289
290	By default, Fossil runs with autosync mode turned on. The
291	authors finds that projects run more smoothly in autosync mode since
292	autosync helps to prevent pointless forking and merging and helps keeps
293	all collaborators working on exactly the same code rather than on their
294

M www/custom_ticket.wiki

+60 -55

		--- www/custom_ticket.wiki
		+++ www/custom_ticket.wiki
		@@ -1,133 +1,140 @@
1	1	<title>Customizing The Ticket System</title>
2		-<nowiki>
	2	+
3	3	<h2>Introduction</h2>
4	4
5	5	This guide will explain how to add the "assigned_to" and "submitted_by" fields
6	6	to the ticket system in Fossil, as well as making the system more useful. You
7	7	must have "admin" access to the repository to implement these instructions.
8	8
9	9	<h2>First modify the TICKET table</h2>
10	10
11		-<blockquote>
12	11	Click on the "Admin" menu, then "Tickets", then "Table". After the other fields
13	12	and before the final ")", insert:
14	13	<pre>
15	14	,
16	15	assigned_to TEXT,
17	16	opened_by TEXT
18	17	</pre>
	18	+
19	19	And "Apply Changes". You have just added two more fields to the ticket
20	20	database! NOTE: I won't tell you to "Apply Changes" after each step from here
21	21	on out. Now, how do you use these fields?
22		-</blockquote>
23	22
24	23	<h2>Next add assignees</h2>
25	24
26		-<blockquote>
27	25	Back to the "Tickets" admin page, and click "Common". Add something like this:
28	26	<pre>
29	27	set assigned_choices {
30	28	unassigned
31	29	tom
32	30	dick
33	31	harriet
34	32	}
35	33	</pre>
	34	+
36	35	Obviously, choose names corresponding to the logins on your system. The
37	36	'unassigned' entry is important, as it prevents you from having a NULL in that
38	37	field (which causes problems later when editing).
39		-</blockquote>
40	38
41	39	<h2>Now modify the 'new ticket' page</h2>
42	40
43		-<blockquote>
44	41	Back to the "Tickets" admin page, and click "New Ticket Page". This is a little
45	42	more tricky. Edit the top part:
46		-<pre>
47		- if {[info exists submit]} {
48		- set status Open
49		- set opened_by $login
50		- set assigned_to "unassigned"
51		- submit_ticket
52		- }
53		-</pre>
	43	+
	44	+<verbatim>
	45	+if {[info exists submit]} {
	46	+ set status Open
	47	+ set opened_by $login
	48	+ set assigned_to "unassigned"
	49	+ submit_ticket
	50	+}
	51	+</verbatim>
	52	+
54	53	Note the "set opened_by" bit -- that will automatically set the "opened_by"
55	54	field to the login name of the bug reporter. Now, skip to the part with "EMail"
56	55	and modify it like so:
57		-<pre>
58		-<th1>enable_output [expr { "$login" eq "anonymous"}]</th1>
59		-<tr>
60		-<td align="right">EMail:
61		-<input type="text" name="private_contact" value="$<private_contact>" size="30">
62		-</td>
63		-<td><u>Not publicly visible</u>. Used by developers to contact you with
64		-questions.</td>
65		-</tr>
66		-<th1>enable_output 1</th1>
67		-</pre>
	56	+
	57	+<verbatim>
	58	+<th1>enable_output expr { "$login" eq "anonymous"}</th1>
	59	+<tr>
	60	+<td align="right">
	61	+ EMail:
	62	+ <input type="text" name="private_contact" value="$<private_contact>" size="30">
	63	+</td>
	64	+<td>
	65	+ <u>Not publicly visible</u>. Used by developers to contact you with questions.
	66	+</td>
	67	+</tr>
	68	+<th1>enable_output 1</th1>
	69	+</verbatim>
	70	+
68	71	This bit of code will get rid of the "email" field entry for logged-in users.
69	72	Since we know the user's information, we don't have to ask for it. NOTE: it
70	73	might be good to automatically scoop up the user's email and put it here.
71	74
72	75	You might also want to enable people to actually assign the ticket to a specific
73	76	person during creation. For this to work, you need to add the code
74	77	for "assigned_to" as shown below under the heading "Modify the 'edit ticket' page".
75	78	This will give you an additional combobox where you can choose a person during
76	79	ticket creation.
77		-</blockquote>
78	80
79	81	<h2>Modify the 'view ticket' page</h2>
80	82
81		-<blockquote>
82	83	Look for the text "Contact:" (about halfway through). Then insert these lines
83	84	after the closing tr tag and before the "enable_output" line:
84		-<pre>
85		-<tr>
86		- <td align="right">Assigned to:</td><td bgcolor="#d0d0d0">
87		- $<assigned_to>
88		- </td>
89		- <td align="right">Opened by:</td><td bgcolor="#d0d0d0">
90		- $<opened_by>
91		- </td>
92		-</pre>
	85	+
	86	+<verbatim>
	87	+<td align="right">Assigned to:</td><td bgcolor="#d0d0d0">
	88	+ $<assigned_to>
	89	+</td>
	90	+<td align="right">Opened by:</td><td bgcolor="#d0d0d0">
	91	+ $<opened_by>
	92	+</td>
	93	+</verbatim>
	94	+
93	95	This will add a row which displays these two fields, in the event the user has
94	96	<a href="./caps/ref.html#w">ticket "edit" capability</a>.
95		-</blockquote>
96	97
97	98	<h2>Modify the 'edit ticket' page</h2>
98	99
99		-<blockquote>
100	100	Before the "Severity:" line, add this:
101		-<pre>
102		-<tr><td align="right">Assigned to:</td><td>
103		-<th1>combobox assigned_to $assigned_choices 1</th1>
104		-</td></tr>
105		-</pre>
	101	+
	102	+<verbatim>
	103	+<tr>
	104	+ <td align="right">Assigned to:</td>
	105	+ <td>
	106	+ <th1>combobox assigned_to $assigned_choices 1</th1>
	107	+ </td>
	108	+</tr>
	109	+</verbatim>
	110	+
106	111	That will give you a drop-down list of assignees. The first argument to the TH1
107	112	command 'combobox' is the database field which the combobox is associated to.
108	113	The next argument is the list of choices you want to show in the combobox (and
109	114	that you specified in the second step above. The last argument should be 1 for a
110	115	true combobox (see the <a href="th1.md#combobox">TH1 documentation</a> for
111	116	details).
112	117
113	118	Now, similar to the previous
114	119	section, look for "Contact:" and add this:
115		-<pre>
116		- <tr><td align="right">Reported by:</td><td>
117		- <input type="text" name="opened_by" size="40"
118		- value="$<opened_by>">
119		- </td></tr>
120		-</pre>
121		-</blockquote>
	120	+
	121	+<verbatim>
	122	+<tr>
	123	+ <td align="right">Reported by:</td>
	124	+ <td>
	125	+ <input type="text" name="opened_by" size="40" value="$<opened_by>">
	126	+ </td>
	127	+</tr>
	128	+</verbatim>
122	129
123	130	<h2>What next?</h2>
124	131
125		-<blockquote>
126	132	Now you can add custom reports which select based on the person to whom the
127	133	ticket is assigned. For example, an "Assigned to me" report could be:
128		-<pre>
	134	+
	135	+<verbatim>
129	136	SELECT
130	137	CASE WHEN status IN ('Open','Verified') THEN '#f2dcdc'
131	138	WHEN status='Review' THEN '#e8e8e8'
132	139	WHEN status='Fixed' THEN '#cfe8bd'
133	140	WHEN status='Tested' THEN '#bde5d6'
		@@ -139,8 +146,6 @@
139	146	status,
140	147	subsystem,
141	148	title
142	149	FROM ticket
143	150	WHERE assigned_to=user()
144		-</pre>
145		-</blockquote>
146		-</nowiki>
	151	+</verbatim>
147	152

	--- www/custom_ticket.wiki
	+++ www/custom_ticket.wiki
	@@ -1,133 +1,140 @@
1	<title>Customizing The Ticket System</title>
2	<nowiki>
3	<h2>Introduction</h2>
4
5	This guide will explain how to add the "assigned_to" and "submitted_by" fields
6	to the ticket system in Fossil, as well as making the system more useful. You
7	must have "admin" access to the repository to implement these instructions.
8
9	<h2>First modify the TICKET table</h2>
10
11	<blockquote>
12	Click on the "Admin" menu, then "Tickets", then "Table". After the other fields
13	and before the final ")", insert:
14	<pre>
15	,
16	assigned_to TEXT,
17	opened_by TEXT
18	</pre>

19	And "Apply Changes". You have just added two more fields to the ticket
20	database! NOTE: I won't tell you to "Apply Changes" after each step from here
21	on out. Now, how do you use these fields?
22	</blockquote>
23
24	<h2>Next add assignees</h2>
25
26	<blockquote>
27	Back to the "Tickets" admin page, and click "Common". Add something like this:
28	<pre>
29	set assigned_choices {
30	unassigned
31	tom
32	dick
33	harriet
34	}
35	</pre>

36	Obviously, choose names corresponding to the logins on your system. The
37	'unassigned' entry is important, as it prevents you from having a NULL in that
38	field (which causes problems later when editing).
39	</blockquote>
40
41	<h2>Now modify the 'new ticket' page</h2>
42
43	<blockquote>
44	Back to the "Tickets" admin page, and click "New Ticket Page". This is a little
45	more tricky. Edit the top part:
46	<pre>
47	if {[info exists submit]} {
48	set status Open
49	set opened_by $login
50	set assigned_to "unassigned"
51	submit_ticket
52	}
53	</pre>


54	Note the "set opened_by" bit -- that will automatically set the "opened_by"
55	field to the login name of the bug reporter. Now, skip to the part with "EMail"
56	and modify it like so:
57	<pre>
58	<th1>enable_output [expr { "$login" eq "anonymous"}]</th1>
59	<tr>
60	<td align="right">EMail:
61	<input type="text" name="private_contact" value="$<private_contact>" size="30">
62	</td>
63	<td><u>Not publicly visible</u>. Used by developers to contact you with
64	questions.</td>
65	</tr>
66	<th1>enable_output 1</th1>
67	</pre>




68	This bit of code will get rid of the "email" field entry for logged-in users.
69	Since we know the user's information, we don't have to ask for it. NOTE: it
70	might be good to automatically scoop up the user's email and put it here.
71
72	You might also want to enable people to actually assign the ticket to a specific
73	person during creation. For this to work, you need to add the code
74	for "assigned_to" as shown below under the heading "Modify the 'edit ticket' page".
75	This will give you an additional combobox where you can choose a person during
76	ticket creation.
77	</blockquote>
78
79	<h2>Modify the 'view ticket' page</h2>
80
81	<blockquote>
82	Look for the text "Contact:" (about halfway through). Then insert these lines
83	after the closing tr tag and before the "enable_output" line:
84	<pre>
85	<tr>
86	<td align="right">Assigned to:</td><td bgcolor="#d0d0d0">
87	$<assigned_to>
88	</td>
89	<td align="right">Opened by:</td><td bgcolor="#d0d0d0">
90	$<opened_by>
91	</td>
92	</pre>

93	This will add a row which displays these two fields, in the event the user has
94	<a href="./caps/ref.html#w">ticket "edit" capability</a>.
95	</blockquote>
96
97	<h2>Modify the 'edit ticket' page</h2>
98
99	<blockquote>
100	Before the "Severity:" line, add this:
101	<pre>
102	<tr><td align="right">Assigned to:</td><td>
103	<th1>combobox assigned_to $assigned_choices 1</th1>
104	</td></tr>
105	</pre>





106	That will give you a drop-down list of assignees. The first argument to the TH1
107	command 'combobox' is the database field which the combobox is associated to.
108	The next argument is the list of choices you want to show in the combobox (and
109	that you specified in the second step above. The last argument should be 1 for a
110	true combobox (see the <a href="th1.md#combobox">TH1 documentation</a> for
111	details).
112
113	Now, similar to the previous
114	section, look for "Contact:" and add this:
115	<pre>
116	<tr><td align="right">Reported by:</td><td>
117	<input type="text" name="opened_by" size="40"
118	value="$<opened_by>">
119	</td></tr>
120	</pre>
121	</blockquote>


122
123	<h2>What next?</h2>
124
125	<blockquote>
126	Now you can add custom reports which select based on the person to whom the
127	ticket is assigned. For example, an "Assigned to me" report could be:
128	<pre>

129	SELECT
130	CASE WHEN status IN ('Open','Verified') THEN '#f2dcdc'
131	WHEN status='Review' THEN '#e8e8e8'
132	WHEN status='Fixed' THEN '#cfe8bd'
133	WHEN status='Tested' THEN '#bde5d6'
	@@ -139,8 +146,6 @@
139	status,
140	subsystem,
141	title
142	FROM ticket
143	WHERE assigned_to=user()
144	</pre>
145	</blockquote>
146	</nowiki>
147

	--- www/custom_ticket.wiki
	+++ www/custom_ticket.wiki
	@@ -1,133 +1,140 @@
1	<title>Customizing The Ticket System</title>
2
3	<h2>Introduction</h2>
4
5	This guide will explain how to add the "assigned_to" and "submitted_by" fields
6	to the ticket system in Fossil, as well as making the system more useful. You
7	must have "admin" access to the repository to implement these instructions.
8
9	<h2>First modify the TICKET table</h2>
10

11	Click on the "Admin" menu, then "Tickets", then "Table". After the other fields
12	and before the final ")", insert:
13	<pre>
14	,
15	assigned_to TEXT,
16	opened_by TEXT
17	</pre>
18
19	And "Apply Changes". You have just added two more fields to the ticket
20	database! NOTE: I won't tell you to "Apply Changes" after each step from here
21	on out. Now, how do you use these fields?

22
23	<h2>Next add assignees</h2>
24

25	Back to the "Tickets" admin page, and click "Common". Add something like this:
26	<pre>
27	set assigned_choices {
28	unassigned
29	tom
30	dick
31	harriet
32	}
33	</pre>
34
35	Obviously, choose names corresponding to the logins on your system. The
36	'unassigned' entry is important, as it prevents you from having a NULL in that
37	field (which causes problems later when editing).

38
39	<h2>Now modify the 'new ticket' page</h2>
40

41	Back to the "Tickets" admin page, and click "New Ticket Page". This is a little
42	more tricky. Edit the top part:
43
44	<verbatim>
45	if {[info exists submit]} {
46	set status Open
47	set opened_by $login
48	set assigned_to "unassigned"
49	submit_ticket
50	}
51	</verbatim>
52
53	Note the "set opened_by" bit -- that will automatically set the "opened_by"
54	field to the login name of the bug reporter. Now, skip to the part with "EMail"
55	and modify it like so:
56
57	<verbatim>
58	<th1>enable_output expr { "$login" eq "anonymous"}</th1>
59	<tr>
60	<td align="right">
61	EMail:
62	<input type="text" name="private_contact" value="$<private_contact>" size="30">
63	</td>
64	<td>
65	<u>Not publicly visible</u>. Used by developers to contact you with questions.
66	</td>
67	</tr>
68	<th1>enable_output 1</th1>
69	</verbatim>
70
71	This bit of code will get rid of the "email" field entry for logged-in users.
72	Since we know the user's information, we don't have to ask for it. NOTE: it
73	might be good to automatically scoop up the user's email and put it here.
74
75	You might also want to enable people to actually assign the ticket to a specific
76	person during creation. For this to work, you need to add the code
77	for "assigned_to" as shown below under the heading "Modify the 'edit ticket' page".
78	This will give you an additional combobox where you can choose a person during
79	ticket creation.

80
81	<h2>Modify the 'view ticket' page</h2>
82

83	Look for the text "Contact:" (about halfway through). Then insert these lines
84	after the closing tr tag and before the "enable_output" line:
85
86	<verbatim>
87	<td align="right">Assigned to:</td><td bgcolor="#d0d0d0">
88	$<assigned_to>
89	</td>
90	<td align="right">Opened by:</td><td bgcolor="#d0d0d0">
91	$<opened_by>
92	</td>
93	</verbatim>
94
95	This will add a row which displays these two fields, in the event the user has
96	<a href="./caps/ref.html#w">ticket "edit" capability</a>.

97
98	<h2>Modify the 'edit ticket' page</h2>
99

100	Before the "Severity:" line, add this:
101
102	<verbatim>
103	<tr>
104	<td align="right">Assigned to:</td>
105	<td>
106	<th1>combobox assigned_to $assigned_choices 1</th1>
107	</td>
108	</tr>
109	</verbatim>
110
111	That will give you a drop-down list of assignees. The first argument to the TH1
112	command 'combobox' is the database field which the combobox is associated to.
113	The next argument is the list of choices you want to show in the combobox (and
114	that you specified in the second step above. The last argument should be 1 for a
115	true combobox (see the <a href="th1.md#combobox">TH1 documentation</a> for
116	details).
117
118	Now, similar to the previous
119	section, look for "Contact:" and add this:
120
121	<verbatim>
122	<tr>
123	<td align="right">Reported by:</td>
124	<td>
125	<input type="text" name="opened_by" size="40" value="$<opened_by>">
126	</td>
127	</tr>
128	</verbatim>
129
130	<h2>What next?</h2>
131

132	Now you can add custom reports which select based on the person to whom the
133	ticket is assigned. For example, an "Assigned to me" report could be:
134
135	<verbatim>
136	SELECT
137	CASE WHEN status IN ('Open','Verified') THEN '#f2dcdc'
138	WHEN status='Review' THEN '#e8e8e8'
139	WHEN status='Fixed' THEN '#cfe8bd'
140	WHEN status='Tested' THEN '#bde5d6'
	@@ -139,8 +146,6 @@
146	status,
147	subsystem,
148	title
149	FROM ticket
150	WHERE assigned_to=user()
151	</verbatim>


152

M www/delta_format.wiki

+2 -2

		--- www/delta_format.wiki
		+++ www/delta_format.wiki
		@@ -190,13 +190,13 @@
190	190	"0"-characters, except if they are significant (i.e. 0 => "0").
191	191
192	192	The base-64 encoding uses one character for each 6 bits of
193	193	the integer to be encoded. The encoding characters are:
194	194
195		-<blockquote><pre>
	195	+<pre>
196	196	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~
197		-</pre></blockquote>
	197	+</pre>
198	198
199	199	The least significant 6 bits of the integer are encoded by
200	200	the first character, followed by
201	201	the next 6 bits, and so on until all non-zero bits of the integer
202	202	are encoded. The minimum number of encoding characters is used.
203	203

	--- www/delta_format.wiki
	+++ www/delta_format.wiki
	@@ -190,13 +190,13 @@
190	"0"-characters, except if they are significant (i.e. 0 => "0").
191
192	The base-64 encoding uses one character for each 6 bits of
193	the integer to be encoded. The encoding characters are:
194
195	<blockquote><pre>
196	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~
197	</pre></blockquote>
198
199	The least significant 6 bits of the integer are encoded by
200	the first character, followed by
201	the next 6 bits, and so on until all non-zero bits of the integer
202	are encoded. The minimum number of encoding characters is used.
203

	--- www/delta_format.wiki
	+++ www/delta_format.wiki
	@@ -190,13 +190,13 @@
190	"0"-characters, except if they are significant (i.e. 0 => "0").
191
192	The base-64 encoding uses one character for each 6 bits of
193	the integer to be encoded. The encoding characters are:
194
195	<pre>
196	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~
197	</pre>
198
199	The least significant 6 bits of the integer are encoded by
200	the first character, followed by
201	the next 6 bits, and so on until all non-zero bits of the integer
202	are encoded. The minimum number of encoding characters is used.
203

M www/embeddeddoc.wiki

+7 -10

		--- www/embeddeddoc.wiki
		+++ www/embeddeddoc.wiki
		@@ -29,13 +29,13 @@
29	29
30	30	The fossil web interface supports embedded documentation using
31	31	the "/doc" page. To access embedded documentation, one points
32	32	a web browser to a fossil URL of the following form:
33	33
34		-<blockquote>
	34	+<pre>
35	35	<i><baseurl></i><big><b>/doc/</b></big><i><version></i><big><b>/</b></big><i><filename></i>
36		-</blockquote>
	36	+</pre>
37	37
38	38	The <i><baseurl></i> is the main URL used to access the fossil web server.
39	39	For example, the <i><baseurl></i> for the fossil project itself is
40	40	[https://fossil-scm.org/home].
41	41	If you launch the web server using the "[/help?cmd=ui\|fossil ui]" command line,
		@@ -200,24 +200,24 @@
200	200	embedded documentation. The name of this file in the fossil
201	201	source tree is "<b>www/embeddeddoc.wiki</b>".
202	202	You are perhaps looking at this
203	203	file using the URL:
204	204
205		- [https://fossil-scm.org/home/doc/trunk/www/embeddeddoc.wiki].
	205	+<pre>[https://fossil-scm.org/home/doc/trunk/www/embeddeddoc.wiki]</pre>
206	206
207	207	The first part of this path, the "[https://fossil-scm.org/home]",
208	208	is the base URL. You might have originally typed:
209	209	[https://fossil-scm.org/]. The web server at the fossil-scm.org
210	210	site automatically redirects such links by appending "home". The
211	211	"home" file on fossil-scm.org is really a [./server/any/cgi.md\|CGI script]
212	212	which runs the fossil web service in CGI mode.
213	213	The "home" CGI script looks like this:
214	214
215		-<blockquote><pre>
	215	+<pre>
216	216	#!/usr/bin/fossil
217	217	repository: /fossil/fossil.fossil
218		-</pre></blockquote>
	218	+</pre>
219	219
220	220	This is one of the many ways to set up a
221	221	<a href="./server/">Fossil server</a>.
222	222
223	223	The "<b>/trunk/</b>" part of the URL tells fossil to use
		@@ -241,15 +241,12 @@
241	241	When the symbolic name is a date and time, fossil shows the version
242	242	of the document that was most recently checked in as of the date
243	243	and time specified. So, for example, to see what the fossil website
244	244	looked like at the beginning of 2010, enter:
245	245
246		-<blockquote>
247		-<a href="/doc/2010-01-01/www/index.wiki">
248		-https://fossil-scm.org/home/doc/<b>2010-01-01</b>/www/index.wiki
249		-</a>
250		-</blockquote>
	246	+<pre><a href="/doc/2010-01-01/www/index.wiki">https://fossil-scm.org/home/doc/<b>2010-01-01</b>/www/index.wiki
	247	+</a></pre>
251	248
252	249	The file that encodes this document is stored in the fossil source tree under
253	250	the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the
254	251	last part of the URL for this document.
255	252
256	253

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -29,13 +29,13 @@
29
30	The fossil web interface supports embedded documentation using
31	the "/doc" page. To access embedded documentation, one points
32	a web browser to a fossil URL of the following form:
33
34	<blockquote>
35	<i><baseurl></i><big><b>/doc/</b></big><i><version></i><big><b>/</b></big><i><filename></i>
36	</blockquote>
37
38	The <i><baseurl></i> is the main URL used to access the fossil web server.
39	For example, the <i><baseurl></i> for the fossil project itself is
40	[https://fossil-scm.org/home].
41	If you launch the web server using the "[/help?cmd=ui\|fossil ui]" command line,
	@@ -200,24 +200,24 @@
200	embedded documentation. The name of this file in the fossil
201	source tree is "<b>www/embeddeddoc.wiki</b>".
202	You are perhaps looking at this
203	file using the URL:
204
205	[https://fossil-scm.org/home/doc/trunk/www/embeddeddoc.wiki].
206
207	The first part of this path, the "[https://fossil-scm.org/home]",
208	is the base URL. You might have originally typed:
209	[https://fossil-scm.org/]. The web server at the fossil-scm.org
210	site automatically redirects such links by appending "home". The
211	"home" file on fossil-scm.org is really a [./server/any/cgi.md\|CGI script]
212	which runs the fossil web service in CGI mode.
213	The "home" CGI script looks like this:
214
215	<blockquote><pre>
216	#!/usr/bin/fossil
217	repository: /fossil/fossil.fossil
218	</pre></blockquote>
219
220	This is one of the many ways to set up a
221	<a href="./server/">Fossil server</a>.
222
223	The "<b>/trunk/</b>" part of the URL tells fossil to use
	@@ -241,15 +241,12 @@
241	When the symbolic name is a date and time, fossil shows the version
242	of the document that was most recently checked in as of the date
243	and time specified. So, for example, to see what the fossil website
244	looked like at the beginning of 2010, enter:
245
246	<blockquote>
247	<a href="/doc/2010-01-01/www/index.wiki">
248	https://fossil-scm.org/home/doc/<b>2010-01-01</b>/www/index.wiki
249	</a>
250	</blockquote>
251
252	The file that encodes this document is stored in the fossil source tree under
253	the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the
254	last part of the URL for this document.
255
256

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -29,13 +29,13 @@
29
30	The fossil web interface supports embedded documentation using
31	the "/doc" page. To access embedded documentation, one points
32	a web browser to a fossil URL of the following form:
33
34	<pre>
35	<i><baseurl></i><big><b>/doc/</b></big><i><version></i><big><b>/</b></big><i><filename></i>
36	</pre>
37
38	The <i><baseurl></i> is the main URL used to access the fossil web server.
39	For example, the <i><baseurl></i> for the fossil project itself is
40	[https://fossil-scm.org/home].
41	If you launch the web server using the "[/help?cmd=ui\|fossil ui]" command line,
	@@ -200,24 +200,24 @@
200	embedded documentation. The name of this file in the fossil
201	source tree is "<b>www/embeddeddoc.wiki</b>".
202	You are perhaps looking at this
203	file using the URL:
204
205	<pre>[https://fossil-scm.org/home/doc/trunk/www/embeddeddoc.wiki]</pre>
206
207	The first part of this path, the "[https://fossil-scm.org/home]",
208	is the base URL. You might have originally typed:
209	[https://fossil-scm.org/]. The web server at the fossil-scm.org
210	site automatically redirects such links by appending "home". The
211	"home" file on fossil-scm.org is really a [./server/any/cgi.md\|CGI script]
212	which runs the fossil web service in CGI mode.
213	The "home" CGI script looks like this:
214
215	<pre>
216	#!/usr/bin/fossil
217	repository: /fossil/fossil.fossil
218	</pre>
219
220	This is one of the many ways to set up a
221	<a href="./server/">Fossil server</a>.
222
223	The "<b>/trunk/</b>" part of the URL tells fossil to use
	@@ -241,15 +241,12 @@
241	When the symbolic name is a date and time, fossil shows the version
242	of the document that was most recently checked in as of the date
243	and time specified. So, for example, to see what the fossil website
244	looked like at the beginning of 2010, enter:
245
246	<pre><a href="/doc/2010-01-01/www/index.wiki">https://fossil-scm.org/home/doc/<b>2010-01-01</b>/www/index.wiki
247	</a></pre>



248
249	The file that encodes this document is stored in the fossil source tree under
250	the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the
251	last part of the URL for this document.
252
253

M www/event.wiki

+12 -18

		--- www/event.wiki
		+++ www/event.wiki
		@@ -73,16 +73,14 @@
73	73	new technotes. And there is a submenu hyperlink on technote displays for
74	74	editing existing technotes.
75	75
76	76	Technotes can also be created using the <b>wiki create</b> command:
77	77
78		-<blockquote>
79		-<b>
80		-fossil wiki create TestTechnote -t now --technote-bgcolor lightgreen technote.md<br>
81		-<tt>Created new tech note 2021-03-15 13:05:56</tt><br>
82		-</b>
83		-</blockquote>
	78	+<verbatim>
	79	+fossil wiki create TestTechnote -t now --technote-bgcolor lightgreen technote.md
	80	+Created new tech note 2021-03-15 13:05:56
	81	+</verbatim>
84	82
85	83	This command inserts a light green technote in the timeline at 2021-03-15 13:05:56, with
86	84	the contents of file <b>technote.md</b> and comment "TestTechnote". Specifying a different time using
87	85	<b>-t DATETIME</b> will insert the technote at the specified timestamp location in the timeline.
88	86	Different technotes can have the same timestamp.
		@@ -90,30 +88,26 @@
90	88	The first argument to create, <b>TECHNOTE-COMMENT</b>, is the title text for the technote
91	89	that appears in the timeline.
92	90
93	91	To view all technotes, use the <b>wiki ls</b> command:
94	92
95		-<blockquote>
96		-<b>
97		-fossil wiki ls --technote --show-technote-ids<br>
98		-<tt>z739263a134bf0da1d28e939f4c4367f51ef4c51 2020-12-19 13:20:19</tt><br>
99		-<tt>e15a918a8bed71c2ac091d74dc397b8d3340d5e1 2018-09-22 17:40:10</tt><br>
100		-</b>
101		-</blockquote>
	93	+<verbatim>
	94	+fossil wiki ls --technote --show-technote-ids
	95	+z739263a134bf0da1d28e939f4c4367f51ef4c51 2020-12-19 13:20:19
	96	+e15a918a8bed71c2ac091d74dc397b8d3340d5e1 2018-09-22 17:40:10
	97	+</verbatim>
102	98
103	99	A technote ID is the UUID of the technote.
104	100
105	101	To view an individual technote, use the <b>wiki export</b> command:
106	102
107		-<blockquote>
108		-<b>
109		-fossil wiki export --technote version-2.16<br>
	103	+<verbatim>
	104	+fossil wiki export --technote version-2.16
110	105	Release Notes 2021-07-02
111	106
112	107	This note describes changes in the Fossil snapshot for ...
113		-</b>
114		-</blockquote>
	108	+</verbatim>
115	109
116	110	The <b>-t\|--technote</b> option to the <b>export</b> subcommand takes one of
117	111	three identifiers: <b>DATETIME</b>; <b>TECHNOTE-ID</b>; and <b>TAG</b>.
118	112	See the [/help?cmd=wiki \| wiki help] for specifics.
119	113
120	114

	--- www/event.wiki
	+++ www/event.wiki
	@@ -73,16 +73,14 @@
73	new technotes. And there is a submenu hyperlink on technote displays for
74	editing existing technotes.
75
76	Technotes can also be created using the <b>wiki create</b> command:
77
78	<blockquote>
79	<b>
80	fossil wiki create TestTechnote -t now --technote-bgcolor lightgreen technote.md<br>
81	<tt>Created new tech note 2021-03-15 13:05:56</tt><br>
82	</b>
83	</blockquote>
84
85	This command inserts a light green technote in the timeline at 2021-03-15 13:05:56, with
86	the contents of file <b>technote.md</b> and comment "TestTechnote". Specifying a different time using
87	<b>-t DATETIME</b> will insert the technote at the specified timestamp location in the timeline.
88	Different technotes can have the same timestamp.
	@@ -90,30 +88,26 @@
90	The first argument to create, <b>TECHNOTE-COMMENT</b>, is the title text for the technote
91	that appears in the timeline.
92
93	To view all technotes, use the <b>wiki ls</b> command:
94
95	<blockquote>
96	<b>
97	fossil wiki ls --technote --show-technote-ids<br>
98	<tt>z739263a134bf0da1d28e939f4c4367f51ef4c51 2020-12-19 13:20:19</tt><br>
99	<tt>e15a918a8bed71c2ac091d74dc397b8d3340d5e1 2018-09-22 17:40:10</tt><br>
100	</b>
101	</blockquote>
102
103	A technote ID is the UUID of the technote.
104
105	To view an individual technote, use the <b>wiki export</b> command:
106
107	<blockquote>
108	<b>
109	fossil wiki export --technote version-2.16<br>
110	Release Notes 2021-07-02
111
112	This note describes changes in the Fossil snapshot for ...
113	</b>
114	</blockquote>
115
116	The <b>-t\|--technote</b> option to the <b>export</b> subcommand takes one of
117	three identifiers: <b>DATETIME</b>; <b>TECHNOTE-ID</b>; and <b>TAG</b>.
118	See the [/help?cmd=wiki \| wiki help] for specifics.
119
120

	--- www/event.wiki
	+++ www/event.wiki
	@@ -73,16 +73,14 @@
73	new technotes. And there is a submenu hyperlink on technote displays for
74	editing existing technotes.
75
76	Technotes can also be created using the <b>wiki create</b> command:
77
78	<verbatim>
79	fossil wiki create TestTechnote -t now --technote-bgcolor lightgreen technote.md
80	Created new tech note 2021-03-15 13:05:56
81	</verbatim>


82
83	This command inserts a light green technote in the timeline at 2021-03-15 13:05:56, with
84	the contents of file <b>technote.md</b> and comment "TestTechnote". Specifying a different time using
85	<b>-t DATETIME</b> will insert the technote at the specified timestamp location in the timeline.
86	Different technotes can have the same timestamp.
	@@ -90,30 +88,26 @@
88	The first argument to create, <b>TECHNOTE-COMMENT</b>, is the title text for the technote
89	that appears in the timeline.
90
91	To view all technotes, use the <b>wiki ls</b> command:
92
93	<verbatim>
94	fossil wiki ls --technote --show-technote-ids
95	z739263a134bf0da1d28e939f4c4367f51ef4c51 2020-12-19 13:20:19
96	e15a918a8bed71c2ac091d74dc397b8d3340d5e1 2018-09-22 17:40:10
97	</verbatim>


98
99	A technote ID is the UUID of the technote.
100
101	To view an individual technote, use the <b>wiki export</b> command:
102
103	<verbatim>
104	fossil wiki export --technote version-2.16

105	Release Notes 2021-07-02
106
107	This note describes changes in the Fossil snapshot for ...
108	</verbatim>

109
110	The <b>-t\|--technote</b> option to the <b>export</b> subcommand takes one of
111	three identifiers: <b>DATETIME</b>; <b>TECHNOTE-ID</b>; and <b>TAG</b>.
112	See the [/help?cmd=wiki \| wiki help] for specifics.
113
114

M www/faq.tcl

+19 -15

		--- www/faq.tcl
		+++ www/faq.tcl
		@@ -12,13 +12,13 @@
12	12	What GUIs are available for fossil?
13	13	} {
14	14	The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
15	15	Just run:
16	16
17		- <blockquote>
	17	+ <pre>
18	18	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
19		- </blockquote>
	19	+ </pre>
20	20
21	21	And your default web browser should pop up and automatically point to
22	22	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
23	23	if you are within an open check-out.)
24	24	}
		@@ -42,13 +42,13 @@
42	42	make the new check-in be the first check-in for a new branch.
43	43
44	44	If you want to create a new branch whose initial content is the
45	45	same as an existing check-in, use this command:
46	46
47		- <blockquote>
	47	+ <pre>
48	48	<b>fossil [/help/branch\|branch] new</b> <i>BRANCH-NAME BASIS</i>
49		- </blockquote>
	49	+ </pre>
50	50
51	51	The <i>BRANCH-NAME</i> argument is the name of the new branch and the
52	52	<i>BASIS</i> argument is the name of the check-in that the branch splits
53	53	off from.
54	54
		@@ -75,13 +75,13 @@
75	75	for example, it is common to give every released version a "release" tag.
76	76
77	77	If you want add a tag to an existing check-in, you can use the
78	78	<b>[/help/tag\|tag]</b> command. For example:
79	79
80		- <blockquote>
	80	+ <pre>
81	81	<b>fossil [/help/branch\|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i>
82		- </blockquote>
	82	+ </pre>
83	83
84	84	The CHECK-IN in the previous line can be any
85	85	[./checkin_names.wiki \| valid check-in name format].
86	86
87	87	You can also add (and remove) tags from a check-in using the
		@@ -127,25 +127,30 @@
127	127
128	128	faq {
129	129	How do I make a clone of the fossil self-hosting repository?
130	130	} {
131	131	Any of the following commands should work:
132		- <blockquote><pre>
	132	+
	133	+ <pre>
133	134	fossil [/help/clone\|clone] https://fossil-scm.org/ fossil.fossil
134	135	fossil [/help/clone\|clone] https://www2.fossil-scm.org/ fossil.fossil
135	136	fossil [/help/clone\|clone] https://www3.fossil-scm.org/site.cgi fossil.fossil
136		- </pre></blockquote>
	137	+ </pre>
	138	+
137	139	Once you have the repository cloned, you can open a local check-out
138	140	as follows:
139		- <blockquote><pre>
	141	+
	142	+ <pre>
140	143	mkdir src; cd src; fossil [/help/open\|open] ../fossil.fossil
141		- </pre></blockquote>
	144	+ </pre>
	145	+
142	146	Thereafter you should be able to keep your local check-out up to date
143	147	with the latest code in the public repository by typing:
144		- <blockquote><pre>
	148	+
	149	+ <pre>
145	150	fossil [/help/update\|update]
146		- </pre></blockquote>
	151	+ </pre>
147	152	}
148	153
149	154	faq {
150	155	How do I import or export content from and to other version control systems?
151	156	} {
		@@ -155,12 +160,11 @@
155	160
156	161
157	162	#############################################################################
158	163	# Code to actually generate the FAQ
159	164	#
160		-puts "<title>Fossil FAQ</title>"
161		-puts "<h1 align=\"center\">Frequently Asked Questions</h1>\n"
	165	+puts "<title>Fossil FAQ</title>\n"
162	166	puts "Note: See also <a href=\"qandc.wiki\">Questions and Criticisms</a>.\n"
163	167
164	168	puts {<ol>}
165	169	for {set i 1} {$i<$cnt} {incr i} {
166	170	puts "<li><a href=\"#q$i\">[lindex $faq($i) 0]</a></li>"
		@@ -170,8 +174,8 @@
170	174
171	175	for {set i 1} {$i<$cnt} {incr i} {
172	176	puts "<p id=\"q$i\"><b>($i) [lindex $faq($i) 0]</b></p>\n"
173	177	set body [lindex $faq($i) 1]
174	178	regsub -all "\n *" [string trim $body] "\n" body
175		- puts "<blockquote>$body</blockquote></li>\n"
	179	+ puts "$body</li>\n"
176	180	}
177	181	puts {</ol>}
178	182

	--- www/faq.tcl
	+++ www/faq.tcl
	@@ -12,13 +12,13 @@
12	What GUIs are available for fossil?
13	} {
14	The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
15	Just run:
16
17	<blockquote>
18	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
19	</blockquote>
20
21	And your default web browser should pop up and automatically point to
22	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
23	if you are within an open check-out.)
24	}
	@@ -42,13 +42,13 @@
42	make the new check-in be the first check-in for a new branch.
43
44	If you want to create a new branch whose initial content is the
45	same as an existing check-in, use this command:
46
47	<blockquote>
48	<b>fossil [/help/branch\|branch] new</b> <i>BRANCH-NAME BASIS</i>
49	</blockquote>
50
51	The <i>BRANCH-NAME</i> argument is the name of the new branch and the
52	<i>BASIS</i> argument is the name of the check-in that the branch splits
53	off from.
54
	@@ -75,13 +75,13 @@
75	for example, it is common to give every released version a "release" tag.
76
77	If you want add a tag to an existing check-in, you can use the
78	<b>[/help/tag\|tag]</b> command. For example:
79
80	<blockquote>
81	<b>fossil [/help/branch\|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i>
82	</blockquote>
83
84	The CHECK-IN in the previous line can be any
85	[./checkin_names.wiki \| valid check-in name format].
86
87	You can also add (and remove) tags from a check-in using the
	@@ -127,25 +127,30 @@
127
128	faq {
129	How do I make a clone of the fossil self-hosting repository?
130	} {
131	Any of the following commands should work:
132	<blockquote><pre>

133	fossil [/help/clone\|clone] https://fossil-scm.org/ fossil.fossil
134	fossil [/help/clone\|clone] https://www2.fossil-scm.org/ fossil.fossil
135	fossil [/help/clone\|clone] https://www3.fossil-scm.org/site.cgi fossil.fossil
136	</pre></blockquote>

137	Once you have the repository cloned, you can open a local check-out
138	as follows:
139	<blockquote><pre>

140	mkdir src; cd src; fossil [/help/open\|open] ../fossil.fossil
141	</pre></blockquote>

142	Thereafter you should be able to keep your local check-out up to date
143	with the latest code in the public repository by typing:
144	<blockquote><pre>

145	fossil [/help/update\|update]
146	</pre></blockquote>
147	}
148
149	faq {
150	How do I import or export content from and to other version control systems?
151	} {
	@@ -155,12 +160,11 @@
155
156
157	#############################################################################
158	# Code to actually generate the FAQ
159	#
160	puts "<title>Fossil FAQ</title>"
161	puts "<h1 align=\"center\">Frequently Asked Questions</h1>\n"
162	puts "Note: See also <a href=\"qandc.wiki\">Questions and Criticisms</a>.\n"
163
164	puts {<ol>}
165	for {set i 1} {$i<$cnt} {incr i} {
166	puts "<li><a href=\"#q$i\">[lindex $faq($i) 0]</a></li>"
	@@ -170,8 +174,8 @@
170
171	for {set i 1} {$i<$cnt} {incr i} {
172	puts "<p id=\"q$i\"><b>($i) [lindex $faq($i) 0]</b></p>\n"
173	set body [lindex $faq($i) 1]
174	regsub -all "\n *" [string trim $body] "\n" body
175	puts "<blockquote>$body</blockquote></li>\n"
176	}
177	puts {</ol>}
178

	--- www/faq.tcl
	+++ www/faq.tcl
	@@ -12,13 +12,13 @@
12	What GUIs are available for fossil?
13	} {
14	The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
15	Just run:
16
17	<pre>
18	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
19	</pre>
20
21	And your default web browser should pop up and automatically point to
22	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
23	if you are within an open check-out.)
24	}
	@@ -42,13 +42,13 @@
42	make the new check-in be the first check-in for a new branch.
43
44	If you want to create a new branch whose initial content is the
45	same as an existing check-in, use this command:
46
47	<pre>
48	<b>fossil [/help/branch\|branch] new</b> <i>BRANCH-NAME BASIS</i>
49	</pre>
50
51	The <i>BRANCH-NAME</i> argument is the name of the new branch and the
52	<i>BASIS</i> argument is the name of the check-in that the branch splits
53	off from.
54
	@@ -75,13 +75,13 @@
75	for example, it is common to give every released version a "release" tag.
76
77	If you want add a tag to an existing check-in, you can use the
78	<b>[/help/tag\|tag]</b> command. For example:
79
80	<pre>
81	<b>fossil [/help/branch\|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i>
82	</pre>
83
84	The CHECK-IN in the previous line can be any
85	[./checkin_names.wiki \| valid check-in name format].
86
87	You can also add (and remove) tags from a check-in using the
	@@ -127,25 +127,30 @@
127
128	faq {
129	How do I make a clone of the fossil self-hosting repository?
130	} {
131	Any of the following commands should work:
132
133	<pre>
134	fossil [/help/clone\|clone] https://fossil-scm.org/ fossil.fossil
135	fossil [/help/clone\|clone] https://www2.fossil-scm.org/ fossil.fossil
136	fossil [/help/clone\|clone] https://www3.fossil-scm.org/site.cgi fossil.fossil
137	</pre>
138
139	Once you have the repository cloned, you can open a local check-out
140	as follows:
141
142	<pre>
143	mkdir src; cd src; fossil [/help/open\|open] ../fossil.fossil
144	</pre>
145
146	Thereafter you should be able to keep your local check-out up to date
147	with the latest code in the public repository by typing:
148
149	<pre>
150	fossil [/help/update\|update]
151	</pre>
152	}
153
154	faq {
155	How do I import or export content from and to other version control systems?
156	} {
	@@ -155,12 +160,11 @@
160
161
162	#############################################################################
163	# Code to actually generate the FAQ
164	#
165	puts "<title>Fossil FAQ</title>\n"

166	puts "Note: See also <a href=\"qandc.wiki\">Questions and Criticisms</a>.\n"
167
168	puts {<ol>}
169	for {set i 1} {$i<$cnt} {incr i} {
170	puts "<li><a href=\"#q$i\">[lindex $faq($i) 0]</a></li>"
	@@ -170,8 +174,8 @@
174
175	for {set i 1} {$i<$cnt} {incr i} {
176	puts "<p id=\"q$i\"><b>($i) [lindex $faq($i) 0]</b></p>\n"
177	set body [lindex $faq($i) 1]
178	regsub -all "\n *" [string trim $body] "\n" body
179	puts "$body</li>\n"
180	}
181	puts {</ol>}
182

M www/faq.wiki

+30 -25

		--- www/faq.wiki
		+++ www/faq.wiki
		@@ -14,41 +14,41 @@
14	14	<li><a href="#q8">How do I import or export content from and to other version control systems?</a></li>
15	15	</ol>
16	16	<hr>
17	17	<p id="q1"><b>(1) What GUIs are available for fossil?</b></p>
18	18
19		-<blockquote>The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
	19	+The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
20	20	Just run:
21	21
22		-<blockquote>
	22	+<pre>
23	23	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
24		-</blockquote>
	24	+</pre>
25	25
26	26	And your default web browser should pop up and automatically point to
27	27	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
28		-if you are within an open check-out.)</blockquote></li>
	28	+if you are within an open check-out.)</li>
29	29
30	30	<p id="q2"><b>(2) What is the difference between a "branch" and a "fork"?</b></p>
31	31
32		-<blockquote>This is a big question - too big to answer in a FAQ. Please
	32	+This is a big question - too big to answer in a FAQ. Please
33	33	read the <a href="branching.wiki">Branching, Forking, Merging,
34		-and Tagging</a> document.</blockquote></li>
	34	+and Tagging</a> document.</li>
35	35
36	36	<p id="q3"><b>(3) How do I create a new branch?</b></p>
37	37
38		-<blockquote>There are lots of ways:
	38	+There are lots of ways:
39	39
40	40	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
41	41	command, you can add the option "--branch <i>BRANCH-NAME</i>" to
42	42	make the new check-in be the first check-in for a new branch.
43	43
44	44	If you want to create a new branch whose initial content is the
45	45	same as an existing check-in, use this command:
46	46
47		-<blockquote>
	47	+<pre>
48	48	<b>fossil [/help/branch\|branch] new</b> <i>BRANCH-NAME BASIS</i>
49		-</blockquote>
	49	+</pre>
50	50
51	51	The <i>BRANCH-NAME</i> argument is the name of the new branch and the
52	52	<i>BASIS</i> argument is the name of the check-in that the branch splits
53	53	off from.
54	54
		@@ -58,15 +58,15 @@
58	58	the initial check-in of your branch on the timeline and click on its
59	59	link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
60	60	link (near the "Commands:" label) and click on that. On the
61	61	"Edit Check-in" page, check the box beside "Branching:" and fill in
62	62	the name of your new branch to the right and press the "Apply Changes"
63		-button.</blockquote></li>
	63	+button.</li>
64	64
65	65	<p id="q4"><b>(4) How do I tag a check-in?</b></p>
66	66
67		-<blockquote>There are several ways:
	67	+There are several ways:
68	68
69	69	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
70	70	command, you can add a tag to that check-in using the
71	71	"--tag <i>TAGNAME</i>" command-line option. You can repeat the --tag
72	72	option to give a check-in multiple tags. Tags need not be unique. So,
		@@ -73,13 +73,13 @@
73	73	for example, it is common to give every released version a "release" tag.
74	74
75	75	If you want add a tag to an existing check-in, you can use the
76	76	<b>[/help/tag\|tag]</b> command. For example:
77	77
78		-<blockquote>
	78	+<pre>
79	79	<b>fossil [/help/branch\|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i>
80		-</blockquote>
	80	+</pre>
81	81
82	82	The CHECK-IN in the previous line can be any
83	83	[./checkin_names.wiki \| valid check-in name format].
84	84
85	85	You can also add (and remove) tags from a check-in using the
		@@ -86,16 +86,16 @@
86	86	[./webui.wiki \| web interface]. First locate the check-in that you
87	87	what to tag on the timeline, then click on the link to go the detailed
88	88	information page for that check-in. Then find the "<b>edit</b>"
89	89	link (near the "Commands:" label) and click on that. There are
90	90	controls on the edit page that allow new tags to be added and existing
91		-tags to be removed.</blockquote></li>
	91	+tags to be removed.</li>
92	92
93	93	<p id="q5"><b>(5) How do I create a private branch that won't get pushed back to the
94	94	main repository.</b></p>
95	95
96		-<blockquote>Use the <b>--private</b> command-line option on the
	96	+Use the <b>--private</b> command-line option on the
97	97	<b>commit</b> command. The result will be a check-in which exists on
98	98	your local repository only and is never pushed to other repositories.
99	99	All descendants of a private check-in are also private.
100	100
101	101	Unless you specify something different using the <b>--branch</b> and/or
		@@ -110,35 +110,40 @@
110	110	as if all the changes that occurred on your private branch occurred in
111	111	a single check-in.
112	112	Of course, you can also keep your branch private forever simply
113	113	by not merging the changes in the private branch back into the trunk.
114	114
115		-[./private.wiki \| Additional information]</blockquote></li>
	115	+[./private.wiki \| Additional information]</li>
116	116
117	117	<p id="q6"><b>(6) How can I delete inappropriate content from my fossil repository?</b></p>
118	118
119		-<blockquote>See the article on [./shunning.wiki \| "shunning"] for details.</blockquote></li>
	119	+See the article on [./shunning.wiki \| "shunning"] for details.</li>
120	120
121	121	<p id="q7"><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p>
122	122
123		-<blockquote>Any of the following commands should work:
124		-<blockquote><pre>
	123	+Any of the following commands should work:
	124	+
	125	+<pre>
125	126	fossil [/help/clone\|clone] https://fossil-scm.org/ fossil.fossil
126	127	fossil [/help/clone\|clone] https://www2.fossil-scm.org/ fossil.fossil
127	128	fossil [/help/clone\|clone] https://www3.fossil-scm.org/site.cgi fossil.fossil
128		-</pre></blockquote>
	129	+</pre>
	130	+
129	131	Once you have the repository cloned, you can open a local check-out
130	132	as follows:
131		-<blockquote><pre>
	133	+
	134	+<pre>
132	135	mkdir src; cd src; fossil [/help/open\|open] ../fossil.fossil
133		-</pre></blockquote>
	136	+</pre>
	137	+
134	138	Thereafter you should be able to keep your local check-out up to date
135	139	with the latest code in the public repository by typing:
136		-<blockquote><pre>
	140	+
	141	+<pre>
137	142	fossil [/help/update\|update]
138		-</pre></blockquote></blockquote></li>
	143	+</pre></li>
139	144
140	145	<p id="q8"><b>(8) How do I import or export content from and to other version control systems?</b></p>
141	146
142		-<blockquote>Please see [./inout.wiki \| Import And Export]</blockquote></li>
	147	+Please see [./inout.wiki \| Import And Export]</li>
143	148
144	149	</ol>
145	150

	--- www/faq.wiki
	+++ www/faq.wiki
	@@ -14,41 +14,41 @@
14	<li><a href="#q8">How do I import or export content from and to other version control systems?</a></li>
15	</ol>
16	<hr>
17	<p id="q1"><b>(1) What GUIs are available for fossil?</b></p>
18
19	<blockquote>The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
20	Just run:
21
22	<blockquote>
23	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
24	</blockquote>
25
26	And your default web browser should pop up and automatically point to
27	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
28	if you are within an open check-out.)</blockquote></li>
29
30	<p id="q2"><b>(2) What is the difference between a "branch" and a "fork"?</b></p>
31
32	<blockquote>This is a big question - too big to answer in a FAQ. Please
33	read the <a href="branching.wiki">Branching, Forking, Merging,
34	and Tagging</a> document.</blockquote></li>
35
36	<p id="q3"><b>(3) How do I create a new branch?</b></p>
37
38	<blockquote>There are lots of ways:
39
40	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
41	command, you can add the option "--branch <i>BRANCH-NAME</i>" to
42	make the new check-in be the first check-in for a new branch.
43
44	If you want to create a new branch whose initial content is the
45	same as an existing check-in, use this command:
46
47	<blockquote>
48	<b>fossil [/help/branch\|branch] new</b> <i>BRANCH-NAME BASIS</i>
49	</blockquote>
50
51	The <i>BRANCH-NAME</i> argument is the name of the new branch and the
52	<i>BASIS</i> argument is the name of the check-in that the branch splits
53	off from.
54
	@@ -58,15 +58,15 @@
58	the initial check-in of your branch on the timeline and click on its
59	link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
60	link (near the "Commands:" label) and click on that. On the
61	"Edit Check-in" page, check the box beside "Branching:" and fill in
62	the name of your new branch to the right and press the "Apply Changes"
63	button.</blockquote></li>
64
65	<p id="q4"><b>(4) How do I tag a check-in?</b></p>
66
67	<blockquote>There are several ways:
68
69	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
70	command, you can add a tag to that check-in using the
71	"--tag <i>TAGNAME</i>" command-line option. You can repeat the --tag
72	option to give a check-in multiple tags. Tags need not be unique. So,
	@@ -73,13 +73,13 @@
73	for example, it is common to give every released version a "release" tag.
74
75	If you want add a tag to an existing check-in, you can use the
76	<b>[/help/tag\|tag]</b> command. For example:
77
78	<blockquote>
79	<b>fossil [/help/branch\|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i>
80	</blockquote>
81
82	The CHECK-IN in the previous line can be any
83	[./checkin_names.wiki \| valid check-in name format].
84
85	You can also add (and remove) tags from a check-in using the
	@@ -86,16 +86,16 @@
86	[./webui.wiki \| web interface]. First locate the check-in that you
87	what to tag on the timeline, then click on the link to go the detailed
88	information page for that check-in. Then find the "<b>edit</b>"
89	link (near the "Commands:" label) and click on that. There are
90	controls on the edit page that allow new tags to be added and existing
91	tags to be removed.</blockquote></li>
92
93	<p id="q5"><b>(5) How do I create a private branch that won't get pushed back to the
94	main repository.</b></p>
95
96	<blockquote>Use the <b>--private</b> command-line option on the
97	<b>commit</b> command. The result will be a check-in which exists on
98	your local repository only and is never pushed to other repositories.
99	All descendants of a private check-in are also private.
100
101	Unless you specify something different using the <b>--branch</b> and/or
	@@ -110,35 +110,40 @@
110	as if all the changes that occurred on your private branch occurred in
111	a single check-in.
112	Of course, you can also keep your branch private forever simply
113	by not merging the changes in the private branch back into the trunk.
114
115	[./private.wiki \| Additional information]</blockquote></li>
116
117	<p id="q6"><b>(6) How can I delete inappropriate content from my fossil repository?</b></p>
118
119	<blockquote>See the article on [./shunning.wiki \| "shunning"] for details.</blockquote></li>
120
121	<p id="q7"><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p>
122
123	<blockquote>Any of the following commands should work:
124	<blockquote><pre>

125	fossil [/help/clone\|clone] https://fossil-scm.org/ fossil.fossil
126	fossil [/help/clone\|clone] https://www2.fossil-scm.org/ fossil.fossil
127	fossil [/help/clone\|clone] https://www3.fossil-scm.org/site.cgi fossil.fossil
128	</pre></blockquote>

129	Once you have the repository cloned, you can open a local check-out
130	as follows:
131	<blockquote><pre>

132	mkdir src; cd src; fossil [/help/open\|open] ../fossil.fossil
133	</pre></blockquote>

134	Thereafter you should be able to keep your local check-out up to date
135	with the latest code in the public repository by typing:
136	<blockquote><pre>

137	fossil [/help/update\|update]
138	</pre></blockquote></blockquote></li>
139
140	<p id="q8"><b>(8) How do I import or export content from and to other version control systems?</b></p>
141
142	<blockquote>Please see [./inout.wiki \| Import And Export]</blockquote></li>
143
144	</ol>
145

	--- www/faq.wiki
	+++ www/faq.wiki
	@@ -14,41 +14,41 @@
14	<li><a href="#q8">How do I import or export content from and to other version control systems?</a></li>
15	</ol>
16	<hr>
17	<p id="q1"><b>(1) What GUIs are available for fossil?</b></p>
18
19	The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
20	Just run:
21
22	<pre>
23	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
24	</pre>
25
26	And your default web browser should pop up and automatically point to
27	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
28	if you are within an open check-out.)</li>
29
30	<p id="q2"><b>(2) What is the difference between a "branch" and a "fork"?</b></p>
31
32	This is a big question - too big to answer in a FAQ. Please
33	read the <a href="branching.wiki">Branching, Forking, Merging,
34	and Tagging</a> document.</li>
35
36	<p id="q3"><b>(3) How do I create a new branch?</b></p>
37
38	There are lots of ways:
39
40	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
41	command, you can add the option "--branch <i>BRANCH-NAME</i>" to
42	make the new check-in be the first check-in for a new branch.
43
44	If you want to create a new branch whose initial content is the
45	same as an existing check-in, use this command:
46
47	<pre>
48	<b>fossil [/help/branch\|branch] new</b> <i>BRANCH-NAME BASIS</i>
49	</pre>
50
51	The <i>BRANCH-NAME</i> argument is the name of the new branch and the
52	<i>BASIS</i> argument is the name of the check-in that the branch splits
53	off from.
54
	@@ -58,15 +58,15 @@
58	the initial check-in of your branch on the timeline and click on its
59	link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
60	link (near the "Commands:" label) and click on that. On the
61	"Edit Check-in" page, check the box beside "Branching:" and fill in
62	the name of your new branch to the right and press the "Apply Changes"
63	button.</li>
64
65	<p id="q4"><b>(4) How do I tag a check-in?</b></p>
66
67	There are several ways:
68
69	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
70	command, you can add a tag to that check-in using the
71	"--tag <i>TAGNAME</i>" command-line option. You can repeat the --tag
72	option to give a check-in multiple tags. Tags need not be unique. So,
	@@ -73,13 +73,13 @@
73	for example, it is common to give every released version a "release" tag.
74
75	If you want add a tag to an existing check-in, you can use the
76	<b>[/help/tag\|tag]</b> command. For example:
77
78	<pre>
79	<b>fossil [/help/branch\|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i>
80	</pre>
81
82	The CHECK-IN in the previous line can be any
83	[./checkin_names.wiki \| valid check-in name format].
84
85	You can also add (and remove) tags from a check-in using the
	@@ -86,16 +86,16 @@
86	[./webui.wiki \| web interface]. First locate the check-in that you
87	what to tag on the timeline, then click on the link to go the detailed
88	information page for that check-in. Then find the "<b>edit</b>"
89	link (near the "Commands:" label) and click on that. There are
90	controls on the edit page that allow new tags to be added and existing
91	tags to be removed.</li>
92
93	<p id="q5"><b>(5) How do I create a private branch that won't get pushed back to the
94	main repository.</b></p>
95
96	Use the <b>--private</b> command-line option on the
97	<b>commit</b> command. The result will be a check-in which exists on
98	your local repository only and is never pushed to other repositories.
99	All descendants of a private check-in are also private.
100
101	Unless you specify something different using the <b>--branch</b> and/or
	@@ -110,35 +110,40 @@
110	as if all the changes that occurred on your private branch occurred in
111	a single check-in.
112	Of course, you can also keep your branch private forever simply
113	by not merging the changes in the private branch back into the trunk.
114
115	[./private.wiki \| Additional information]</li>
116
117	<p id="q6"><b>(6) How can I delete inappropriate content from my fossil repository?</b></p>
118
119	See the article on [./shunning.wiki \| "shunning"] for details.</li>
120
121	<p id="q7"><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p>
122
123	Any of the following commands should work:
124
125	<pre>
126	fossil [/help/clone\|clone] https://fossil-scm.org/ fossil.fossil
127	fossil [/help/clone\|clone] https://www2.fossil-scm.org/ fossil.fossil
128	fossil [/help/clone\|clone] https://www3.fossil-scm.org/site.cgi fossil.fossil
129	</pre>
130
131	Once you have the repository cloned, you can open a local check-out
132	as follows:
133
134	<pre>
135	mkdir src; cd src; fossil [/help/open\|open] ../fossil.fossil
136	</pre>
137
138	Thereafter you should be able to keep your local check-out up to date
139	with the latest code in the public repository by typing:
140
141	<pre>
142	fossil [/help/update\|update]
143	</pre></li>
144
145	<p id="q8"><b>(8) How do I import or export content from and to other version control systems?</b></p>
146
147	Please see [./inout.wiki \| Import And Export]</li>
148
149	</ol>
150

M www/fossil_prompt.wiki

+2 -3

		--- www/fossil_prompt.wiki
		+++ www/fossil_prompt.wiki
		@@ -1,7 +1,6 @@
1	1	<title>Fossilized Bash Prompt</title>
2		-<h1>2013-02-21</h1>
3	2
4	3	Dan Kennedy has contributed a
5	4	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	5	that manipulates the bash prompt to show the status of
7	6	the Fossil repository that the user is currently visiting.
		@@ -10,14 +9,14 @@
10	9	red when there are uncommitted changes.
11	10
12	11	To try out this script, simply download it from the link above, then
13	12	type:
14	13
15		-<blockquote><pre>
	14	+<pre>
16	15	. fossil_prompt.sh
17		-</pre></blockquote>
	16	+</pre>
18	17
19	18	For a permanent installation, you can graft the code into your
20	19	<tt>.bashrc</tt> file in your home directory.
21	20
22	21	The code is very simple (only 32 non-comment lines, as of this writing)
23	22	and hence easy to customized.
24	23

	--- www/fossil_prompt.wiki
	+++ www/fossil_prompt.wiki
	@@ -1,7 +1,6 @@
1	<title>Fossilized Bash Prompt</title>
2	<h1>2013-02-21</h1>
3
4	Dan Kennedy has contributed a
5	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	that manipulates the bash prompt to show the status of
7	the Fossil repository that the user is currently visiting.
	@@ -10,14 +9,14 @@
10	red when there are uncommitted changes.
11
12	To try out this script, simply download it from the link above, then
13	type:
14
15	<blockquote><pre>
16	. fossil_prompt.sh
17	</pre></blockquote>
18
19	For a permanent installation, you can graft the code into your
20	<tt>.bashrc</tt> file in your home directory.
21
22	The code is very simple (only 32 non-comment lines, as of this writing)
23	and hence easy to customized.
24

	--- www/fossil_prompt.wiki
	+++ www/fossil_prompt.wiki
	@@ -1,7 +1,6 @@
1	<title>Fossilized Bash Prompt</title>

2
3	Dan Kennedy has contributed a
4	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
5	that manipulates the bash prompt to show the status of
6	the Fossil repository that the user is currently visiting.
	@@ -10,14 +9,14 @@
9	red when there are uncommitted changes.
10
11	To try out this script, simply download it from the link above, then
12	type:
13
14	<pre>
15	. fossil_prompt.sh
16	</pre>
17
18	For a permanent installation, you can graft the code into your
19	<tt>.bashrc</tt> file in your home directory.
20
21	The code is very simple (only 32 non-comment lines, as of this writing)
22	and hence easy to customized.
23

M www/hashpolicy.wiki

+2 -2

		--- www/hashpolicy.wiki
		+++ www/hashpolicy.wiki
		@@ -168,13 +168,13 @@
168	168
169	169	If you are still on Fossil 2.1 through 2.9 but you want Fossil to go
170	170	ahead and start using SHA3 hashes, change the hash policy to
171	171	"sha3" using a command like this:
172	172
173		-<blockquote><verbatim>
	173	+<verbatim>
174	174	fossil hash-policy sha3
175		-</verbatim></blockquote>
	175	+</verbatim>
176	176
177	177	The next check-in will use a SHA3 hash, so that when that check-in is pushed
178	178	to colleagues, their clones will include the new SHA3-named artifact, so
179	179	their local Fossil instances will automatically convert their clones to
180	180	"sha3" mode as well.
181	181

	--- www/hashpolicy.wiki
	+++ www/hashpolicy.wiki
	@@ -168,13 +168,13 @@
168
169	If you are still on Fossil 2.1 through 2.9 but you want Fossil to go
170	ahead and start using SHA3 hashes, change the hash policy to
171	"sha3" using a command like this:
172
173	<blockquote><verbatim>
174	fossil hash-policy sha3
175	</verbatim></blockquote>
176
177	The next check-in will use a SHA3 hash, so that when that check-in is pushed
178	to colleagues, their clones will include the new SHA3-named artifact, so
179	their local Fossil instances will automatically convert their clones to
180	"sha3" mode as well.
181

	--- www/hashpolicy.wiki
	+++ www/hashpolicy.wiki
	@@ -168,13 +168,13 @@
168
169	If you are still on Fossil 2.1 through 2.9 but you want Fossil to go
170	ahead and start using SHA3 hashes, change the hash policy to
171	"sha3" using a command like this:
172
173	<verbatim>
174	fossil hash-policy sha3
175	</verbatim>
176
177	The next check-in will use a SHA3 hash, so that when that check-in is pushed
178	to colleagues, their clones will include the new SHA3-named artifact, so
179	their local Fossil instances will automatically convert their clones to
180	"sha3" mode as well.
181

M www/inout.wiki

+10 -10

		--- www/inout.wiki
		+++ www/inout.wiki
		@@ -8,14 +8,14 @@
8	8
9	9	<h2>Git → Fossil</h2>
10	10
11	11	To import a Git repository into Fossil, say something like:
12	12
13		-<blockquote><pre>
	13	+<pre>
14	14	cd git-repo
15	15	git fast-export --all \| fossil import --git new-repo.fossil
16		-</pre></blockquote>
	16	+</pre>
17	17
18	18	The 3rd argument to the "fossil import"
19	19	command is the name of a new Fossil repository that is created to hold the Git
20	20	content.
21	21
		@@ -58,15 +58,15 @@
58	58	<h2>Fossil → Git</h2>
59	59
60	60	To convert a Fossil repository into a Git repository, run commands like
61	61	this:
62	62
63		-<blockquote><pre>
	63	+<pre>
64	64	git init new-repo
65	65	cd new-repo
66	66	fossil export --git ../repo.fossil \| git fast-import
67		-</pre></blockquote>
	67	+</pre>
68	68
69	69	In other words, create a new Git repository, then pipe the output from the
70	70	"fossil export --git" command into the "git fast-import" command.
71	71
72	72	Note that the "fossil export --git" command only exports the versioned files.
		@@ -97,11 +97,11 @@
97	97
98	98	To illustrate, consider the example of a remote Fossil repository that a
99	99	user wants to import into a local Git repository. First, the user would clone
100	100	the remote repository and import it into a new Git repository:
101	101
102		-<blockquote><pre>
	102	+<pre>
103	103	fossil clone /path/to/remote/repo.fossil repo.fossil
104	104	mkdir repo
105	105	cd repo
106	106	fossil open ../repo.fossil
107	107	mkdir ../repo.git
		@@ -108,33 +108,33 @@
108	108	cd ../repo.git
109	109	git init .
110	110	fossil export --git --export-marks ../repo/fossil.marks \
111	111	../repo.fossil \| git fast-import \
112	112	--export-marks=../repo/git.marks
113		-</pre></blockquote>
	113	+</pre>
114	114
115	115	Once the import has completed, the user would need to <tt>git checkout
116	116	trunk</tt>. At any point after this, new changes can be imported from the
117	117	remote Fossil repository:
118	118
119		-<blockquote><pre>
	119	+<pre>
120	120	cd ../repo
121	121	fossil pull
122	122	cd ../repo.git
123	123	fossil export --git --import-marks ../repo/fossil.marks \
124	124	--export-marks ../repo/fossil.marks \
125	125	../repo.fossil \| git fast-import \
126	126	--import-marks=../repo/git.marks \
127	127	--export-marks=../repo/git.marks
128		-</pre></blockquote>
	128	+</pre>
129	129
130	130	Changes in the Git repository can be exported to the Fossil repository and then
131	131	pushed to the remote:
132	132
133		-<blockquote><pre>
	133	+<pre>
134	134	git fast-export --import-marks=../repo/git.marks \
135	135	--export-marks=../repo/git.marks --all \| fossil import --git \
136	136	--incremental --import-marks ../repo/fossil.marks \
137	137	--export-marks ../repo/fossil.marks ../repo.fossil
138	138	cd ../repo
139	139	fossil push
140		-</pre></blockquote>
	140	+</pre>
141	141

	--- www/inout.wiki
	+++ www/inout.wiki
	@@ -8,14 +8,14 @@
8
9	<h2>Git → Fossil</h2>
10
11	To import a Git repository into Fossil, say something like:
12
13	<blockquote><pre>
14	cd git-repo
15	git fast-export --all \| fossil import --git new-repo.fossil
16	</pre></blockquote>
17
18	The 3rd argument to the "fossil import"
19	command is the name of a new Fossil repository that is created to hold the Git
20	content.
21
	@@ -58,15 +58,15 @@
58	<h2>Fossil → Git</h2>
59
60	To convert a Fossil repository into a Git repository, run commands like
61	this:
62
63	<blockquote><pre>
64	git init new-repo
65	cd new-repo
66	fossil export --git ../repo.fossil \| git fast-import
67	</pre></blockquote>
68
69	In other words, create a new Git repository, then pipe the output from the
70	"fossil export --git" command into the "git fast-import" command.
71
72	Note that the "fossil export --git" command only exports the versioned files.
	@@ -97,11 +97,11 @@
97
98	To illustrate, consider the example of a remote Fossil repository that a
99	user wants to import into a local Git repository. First, the user would clone
100	the remote repository and import it into a new Git repository:
101
102	<blockquote><pre>
103	fossil clone /path/to/remote/repo.fossil repo.fossil
104	mkdir repo
105	cd repo
106	fossil open ../repo.fossil
107	mkdir ../repo.git
	@@ -108,33 +108,33 @@
108	cd ../repo.git
109	git init .
110	fossil export --git --export-marks ../repo/fossil.marks \
111	../repo.fossil \| git fast-import \
112	--export-marks=../repo/git.marks
113	</pre></blockquote>
114
115	Once the import has completed, the user would need to <tt>git checkout
116	trunk</tt>. At any point after this, new changes can be imported from the
117	remote Fossil repository:
118
119	<blockquote><pre>
120	cd ../repo
121	fossil pull
122	cd ../repo.git
123	fossil export --git --import-marks ../repo/fossil.marks \
124	--export-marks ../repo/fossil.marks \
125	../repo.fossil \| git fast-import \
126	--import-marks=../repo/git.marks \
127	--export-marks=../repo/git.marks
128	</pre></blockquote>
129
130	Changes in the Git repository can be exported to the Fossil repository and then
131	pushed to the remote:
132
133	<blockquote><pre>
134	git fast-export --import-marks=../repo/git.marks \
135	--export-marks=../repo/git.marks --all \| fossil import --git \
136	--incremental --import-marks ../repo/fossil.marks \
137	--export-marks ../repo/fossil.marks ../repo.fossil
138	cd ../repo
139	fossil push
140	</pre></blockquote>
141

	--- www/inout.wiki
	+++ www/inout.wiki
	@@ -8,14 +8,14 @@
8
9	<h2>Git → Fossil</h2>
10
11	To import a Git repository into Fossil, say something like:
12
13	<pre>
14	cd git-repo
15	git fast-export --all \| fossil import --git new-repo.fossil
16	</pre>
17
18	The 3rd argument to the "fossil import"
19	command is the name of a new Fossil repository that is created to hold the Git
20	content.
21
	@@ -58,15 +58,15 @@
58	<h2>Fossil → Git</h2>
59
60	To convert a Fossil repository into a Git repository, run commands like
61	this:
62
63	<pre>
64	git init new-repo
65	cd new-repo
66	fossil export --git ../repo.fossil \| git fast-import
67	</pre>
68
69	In other words, create a new Git repository, then pipe the output from the
70	"fossil export --git" command into the "git fast-import" command.
71
72	Note that the "fossil export --git" command only exports the versioned files.
	@@ -97,11 +97,11 @@
97
98	To illustrate, consider the example of a remote Fossil repository that a
99	user wants to import into a local Git repository. First, the user would clone
100	the remote repository and import it into a new Git repository:
101
102	<pre>
103	fossil clone /path/to/remote/repo.fossil repo.fossil
104	mkdir repo
105	cd repo
106	fossil open ../repo.fossil
107	mkdir ../repo.git
	@@ -108,33 +108,33 @@
108	cd ../repo.git
109	git init .
110	fossil export --git --export-marks ../repo/fossil.marks \
111	../repo.fossil \| git fast-import \
112	--export-marks=../repo/git.marks
113	</pre>
114
115	Once the import has completed, the user would need to <tt>git checkout
116	trunk</tt>. At any point after this, new changes can be imported from the
117	remote Fossil repository:
118
119	<pre>
120	cd ../repo
121	fossil pull
122	cd ../repo.git
123	fossil export --git --import-marks ../repo/fossil.marks \
124	--export-marks ../repo/fossil.marks \
125	../repo.fossil \| git fast-import \
126	--import-marks=../repo/git.marks \
127	--export-marks=../repo/git.marks
128	</pre>
129
130	Changes in the Git repository can be exported to the Fossil repository and then
131	pushed to the remote:
132
133	<pre>
134	git fast-export --import-marks=../repo/git.marks \
135	--export-marks=../repo/git.marks --all \| fossil import --git \
136	--incremental --import-marks ../repo/fossil.marks \
137	--export-marks ../repo/fossil.marks ../repo.fossil
138	cd ../repo
139	fossil push
140	</pre>
141

M www/password.wiki

+10 -10

		--- www/password.wiki
		+++ www/password.wiki
		@@ -21,13 +21,13 @@
21	21	the project-code, the user login, and the user cleartext password.
22	22	Suppose user "alice" with password "asdfg" had an account on the
23	23	Fossil self-hosting repository. Then the value of USER.PW
24	24	for alice would be the SHA1 hash of
25	25
26		-<blockquote>
	26	+<pre>
27	27	CE59BB9F186226D80E49D1FA2DB29F935CCA0333/alice/asdfg
28		-</blockquote>
	28	+</pre>
29	29
30	30	Note that by including the project-code and the login as part of the
31	31	hash, a different USER.PW value results even if two or more users on
32	32	the repository select the same "asdfg" password or if user alice
33	33	reuses the same password on multiple projects.
		@@ -36,23 +36,23 @@
36	36	"user" command-line method, the new password is stored using the SHA1
37	37	encoding. Thus, cleartext passwords will gradually migrate to become
38	38	SHA1 passwords. All remaining cleartext passwords can be converted to
39	39	SHA1 passwords using the following command:
40	40
41		-<blockquote><pre>
	41	+<pre>
42	42	fossil test-hash-passwords <i>REPOSITORY-NAME</i>
43		-</pre></blockquote>
	43	+</pre>
44	44
45	45	Remember that converting from cleartext to SHA1 passwords is an
46	46	irreversible operation.
47	47
48	48	The only way to insert a new cleartext password into the USER table
49	49	is to do so manually using SQL commands. For example:
50	50
51		-<blockquote><pre>
	51	+<pre>
52	52	UPDATE user SET pw='asdfg' WHERE login='alice';
53		-</pre></blockquote>
	53	+</pre>
54	54
55	55	Note that an password that is an empty string or NULL will disable
56	56	all login for that user. Thus, to lock a user out of the system,
57	57	one has only to set their password to an empty string, using either
58	58	the web interface or direct SQL manipulation of the USER table.
		@@ -116,24 +116,24 @@
116	116	only holds the SHA1 hash of the password, then only newer clients will be
117	117	able to authenticate to the server.
118	118
119	119	The client normally gets the login and password from the "remote URL".
120	120
121		-<blockquote><pre>
	121	+<pre>
122	122	http://<span style="color:blue">login:password</span>@servername.org/path
123		-</pre></blockquote>
	123	+</pre>
124	124
125	125	For older clients, the password is used for the shared secret as stated
126	126	in the URL and with no encoding.
127	127	For newer clients, the shared secret is derived from the password
128	128	by transformed the password using the SHA1 hash encoding
129	129	described above. However, if the first character of the password is
130	130	"" (ASCII 0x2a) then the "" is skipped and the rest of the password
131	131	is used directly as the share secret without the SHA1 encoding.
132	132
133		-<blockquote><pre>
	133	+<pre>
134	134	http://<span style="color:blue">login:*password</span>@servername.org/path
135		-</pre></blockquote>
	135	+</pre>
136	136
137	137	This *-before-the-password trick can be used by newer clients to
138	138	sync against a legacy server that does not understand the new SHA1
139	139	password encoding.
140	140

	--- www/password.wiki
	+++ www/password.wiki
	@@ -21,13 +21,13 @@
21	the project-code, the user login, and the user cleartext password.
22	Suppose user "alice" with password "asdfg" had an account on the
23	Fossil self-hosting repository. Then the value of USER.PW
24	for alice would be the SHA1 hash of
25
26	<blockquote>
27	CE59BB9F186226D80E49D1FA2DB29F935CCA0333/alice/asdfg
28	</blockquote>
29
30	Note that by including the project-code and the login as part of the
31	hash, a different USER.PW value results even if two or more users on
32	the repository select the same "asdfg" password or if user alice
33	reuses the same password on multiple projects.
	@@ -36,23 +36,23 @@
36	"user" command-line method, the new password is stored using the SHA1
37	encoding. Thus, cleartext passwords will gradually migrate to become
38	SHA1 passwords. All remaining cleartext passwords can be converted to
39	SHA1 passwords using the following command:
40
41	<blockquote><pre>
42	fossil test-hash-passwords <i>REPOSITORY-NAME</i>
43	</pre></blockquote>
44
45	Remember that converting from cleartext to SHA1 passwords is an
46	irreversible operation.
47
48	The only way to insert a new cleartext password into the USER table
49	is to do so manually using SQL commands. For example:
50
51	<blockquote><pre>
52	UPDATE user SET pw='asdfg' WHERE login='alice';
53	</pre></blockquote>
54
55	Note that an password that is an empty string or NULL will disable
56	all login for that user. Thus, to lock a user out of the system,
57	one has only to set their password to an empty string, using either
58	the web interface or direct SQL manipulation of the USER table.
	@@ -116,24 +116,24 @@
116	only holds the SHA1 hash of the password, then only newer clients will be
117	able to authenticate to the server.
118
119	The client normally gets the login and password from the "remote URL".
120
121	<blockquote><pre>
122	http://<span style="color:blue">login:password</span>@servername.org/path
123	</pre></blockquote>
124
125	For older clients, the password is used for the shared secret as stated
126	in the URL and with no encoding.
127	For newer clients, the shared secret is derived from the password
128	by transformed the password using the SHA1 hash encoding
129	described above. However, if the first character of the password is
130	"" (ASCII 0x2a) then the "" is skipped and the rest of the password
131	is used directly as the share secret without the SHA1 encoding.
132
133	<blockquote><pre>
134	http://<span style="color:blue">login:*password</span>@servername.org/path
135	</pre></blockquote>
136
137	This *-before-the-password trick can be used by newer clients to
138	sync against a legacy server that does not understand the new SHA1
139	password encoding.
140

	--- www/password.wiki
	+++ www/password.wiki
	@@ -21,13 +21,13 @@
21	the project-code, the user login, and the user cleartext password.
22	Suppose user "alice" with password "asdfg" had an account on the
23	Fossil self-hosting repository. Then the value of USER.PW
24	for alice would be the SHA1 hash of
25
26	<pre>
27	CE59BB9F186226D80E49D1FA2DB29F935CCA0333/alice/asdfg
28	</pre>
29
30	Note that by including the project-code and the login as part of the
31	hash, a different USER.PW value results even if two or more users on
32	the repository select the same "asdfg" password or if user alice
33	reuses the same password on multiple projects.
	@@ -36,23 +36,23 @@
36	"user" command-line method, the new password is stored using the SHA1
37	encoding. Thus, cleartext passwords will gradually migrate to become
38	SHA1 passwords. All remaining cleartext passwords can be converted to
39	SHA1 passwords using the following command:
40
41	<pre>
42	fossil test-hash-passwords <i>REPOSITORY-NAME</i>
43	</pre>
44
45	Remember that converting from cleartext to SHA1 passwords is an
46	irreversible operation.
47
48	The only way to insert a new cleartext password into the USER table
49	is to do so manually using SQL commands. For example:
50
51	<pre>
52	UPDATE user SET pw='asdfg' WHERE login='alice';
53	</pre>
54
55	Note that an password that is an empty string or NULL will disable
56	all login for that user. Thus, to lock a user out of the system,
57	one has only to set their password to an empty string, using either
58	the web interface or direct SQL manipulation of the USER table.
	@@ -116,24 +116,24 @@
116	only holds the SHA1 hash of the password, then only newer clients will be
117	able to authenticate to the server.
118
119	The client normally gets the login and password from the "remote URL".
120
121	<pre>
122	http://<span style="color:blue">login:password</span>@servername.org/path
123	</pre>
124
125	For older clients, the password is used for the shared secret as stated
126	in the URL and with no encoding.
127	For newer clients, the shared secret is derived from the password
128	by transformed the password using the SHA1 hash encoding
129	described above. However, if the first character of the password is
130	"" (ASCII 0x2a) then the "" is skipped and the rest of the password
131	is used directly as the share secret without the SHA1 encoding.
132
133	<pre>
134	http://<span style="color:blue">login:*password</span>@servername.org/path
135	</pre>
136
137	This *-before-the-password trick can be used by newer clients to
138	sync against a legacy server that does not understand the new SHA1
139	password encoding.
140

M www/quotes.wiki

+37 -37

		--- www/quotes.wiki
		+++ www/quotes.wiki
		@@ -2,115 +2,115 @@
2	2
3	3	The following are collected quotes from various forums and blogs about
4	4	Fossil, Git, and DVCSes in general. This collection is put together
5	5	by the creator of Fossil, so of course there is selection bias...
6	6
7		-<h2>On The Usability Of Git:</h2>
	7	+<h2>On The Usability Of Git</h2>
8	8
9	9	<ol>
10	10	<li>Git approaches the usability of iptables, which is to say, utterly
11	11	unusable unless you have the manpage tattooed on you arm.
12	12
13		-<blockquote>
	13	+<p class="local-indent">
14	14	<i>by mml at [http://news.ycombinator.com/item?id=1433387]</i>
15		-</blockquote>
	15	+</p>
16	16
17	17	<li><nowiki>It's simplest to think of the state of your [git] repository
18	18	as a point in a high-dimensional "code-space", in which branches are
19	19	represented as n-dimensional membranes, mapping the spatial loci of
20	20	successive commits onto the projected manifold of each cloned
21	21	repository.</nowiki>
22	22
23		-<blockquote>
	23	+<p class="local-indent">
24	24	<i>by Jonathan Hartley at
25	25	[https://www.tartley.com/posts/a-guide-to-git-using-spatial-analogies];
26	26	<br>Quoted here: [https://lwn.net/Articles/420152/].</i>
27		-</blockquote>
	27	+</p>
28	28
29	29	<li>Git is not a Prius. Git is a Model T.
30	30	Its plumbing and wiring sticks out all over the place.
31	31	You have to be a mechanic to operate it successfully or you'll be
32	32	stuck on the side of the road when it breaks down.
33	33	And it <b>will</b> break down.
34	34
35		-<blockquote>
	35	+<p class="local-indent">
36	36	<i>Nick Farina at [http://nfarina.com/post/9868516270/git-is-simpler]</i>
37		-</blockquote>
	37	+</p>
38	38
39	39	<li>Initial revision of "git", The information manager from hell
40	40
41		-<blockquote>
	41	+<p class="local-indent">
42	42	<i>Linus Torvalds - 2005-04-07 22:13:13<br>
43	43	Commit comment on the very first source-code check-in for git
44		-</blockquote>
	44	+</p>
45	45
46	46	<li>I've been experimenting a lot with git at work.
47	47	Damn, it's complicated.
48	48	It has things to trip you up with that sane people just wouldn't ever both with
49	49	including the ability to allow you to commit stuff in such a way that you can't find
50	50	it again afterwards (!!!)
51	51	Demented workflow complexity on acid?
52	52	<p>* dkf really wishes he could use fossil instead</p>
53		-<blockquote>
	53	+<p class="local-indent">
54	54	<i>by Donal K. Fellow (dkf) on the Tcl/Tk chatroom, 2013-04-09.</i>
55		-</blockquote>
	55	+</p>
56	56
57	57	<li>[G]it is <i>designed</i> to forget things.
58	58
59		-<blockquote>
	59	+<p class="local-indent">
60	60	<i>[http://www.cs.cmu.edu/~davide/howto/git_lose.html]
61		-</blockquote>
	61	+</p>
62	62
63	63	<li>[I]n nearly 31 years of using a computer i have, in total, lost more data to git
64	64	(while following the instructions!!!) than any other single piece of software.
65	65
66		-<blockquote>
	66	+<p class="local-indent">
67	67	<i>Stephan Beal on the [http://www.mail-archive.com/[email protected]/msg17181.html\|Fossil mailing list]
68	68	2014-09-01.</i>
69		-</blockquote>
	69	+</p>
70	70
71	71	<li>If programmers _really_ wanted to help scientists, they'd build a version control
72	72	system that was more usable than Git.
73	73
74		-<blockquote>
	74	+<p class="local-indent">
75	75	<i>Tweet by Greg Wilson @gvwilson on 2015-02-22 17:47</i>
76		-</blockquote>
	76	+</p>
77	77
78	78	<li><img src='xkcd-git.gif' align='top'>
79	79
80		-<blockquote><i>Randall Munroe. [http://xkcd.com/1597/]</i></blockquote>
	80	+<p class="local-indent"><i>Randall Munroe. [http://xkcd.com/1597/]</i><p>
81	81
82	82	</ol>
83	83
84		-<h2>On The Usability Of Fossil:</h2>
	84	+<h2>On The Usability Of Fossil</h2>
85	85
86	86	<ol>
87	87	<li value=11>
88	88	Fossil mesmerizes me with simplicity especially after I struggled to
89	89	get a bug-tracking system to work with mercurial.
90	90
91		-<blockquote>
	91	+<p class="local-indent">
92	92	<i>rawjeev at [https://stackoverflow.com/a/2100469/142454]</i>
93		-</blockquote>
	93	+</p>
94	94
95	95	<li>Fossil is the best thing to happen
96	96	to my development workflow this year, as I am pretty sure that using
97	97	Git has resulted in the premature death of too many of my brain cells.
98	98	I'm glad to be able to replace Git in every place that I possibly can
99	99	with Fossil.
100	100
101		-<blockquote>
	101	+<p class="local-indent">
102	102	<i>Joe Prostko at [http://www.mail-archive.com/[email protected]/msg16716.html]
103		-</blockquote>
	103	+</p>
104	104
105	105	<li>This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own
106	106	server, ticketing system, Wiki pages, and a very, very helpful timeline visualization. And
107	107	the entire program in a single file!
108	108
109		-<blockquote>
	109	+<p class="local-indent">
110	110	<i>thunderbong commenting on hacker news: [https://news.ycombinator.com/item?id=9131619]</i>
111		-</blockquote>
	111	+</p>
112	112
113	113
114	114	</ol>
115	115
116	116
		@@ -118,33 +118,33 @@
118	118
119	119	<ol>
120	120	<li value=14>
121	121	After prolonged exposure to fossil, i tend to get the jitters when I work with git...
122	122
123		-<blockquote>
	123	+<p class="local-indent">
124	124	<i>sriku - at [https://news.ycombinator.com/item?id=16104427]</i>
125		-</blockquote>
	125	+</p>
126	126
127	127
128	128	<li>
129	129	Just want to say thanks for fossil making my life easier....
130	130	Also <nowiki>[for]</nowiki> not having a misanthropic command line interface.
131	131
132		-<blockquote>
	132	+<p class="local-indent">
133	133	<i>Joshua Paine at [http://www.mail-archive.com/[email protected]/msg02736.html]</i>
134		-</blockquote>
	134	+</p>
135	135
136	136	<li>We use it at a large university to manage code that small teams write.
137	137	The runs everywhere, ease of installation and portability is something that
138	138	seems to be a good fit with the environment we have (highly ditrobuted,
139	139	sometimes very restrictive firewalls, OSX/Win/Linux). We are happy with it
140	140	and teaching a Msc/Phd student (read complete novice) fossil has just
141	141	been a smoother ride than Git was.
142	142
143		-<blockquote>
	143	+<p class="local-indent">
144	144	<i>viablepanic at [https://www.reddit.com/r/programming/comments/bxcto/why_not_fossil_scm/c0p30b4?utm_source=share&utm_medium=web2x&context=3]</i>
145		-</blockquote>
	145	+</p>
146	146
147	147	<li>In the fossil community - and hence in fossil itself - development history
148	148	is pretty much sacrosanct. The very name "fossil" was to chosen to
149	149	reflect the unchanging nature of things in that history.
150	150	<br><br>
		@@ -151,21 +151,21 @@
151	151	In git (or rather, the git community), the development history is part of
152	152	the published aspect of the project, so it provides tools for rearranging
153	153	that history so you can present what you "should" have done rather
154	154	than what you actually did.
155	155
156		-<blockquote>
	156	+<p class="local-indent">
157	157	<i>Mike Meyer on the Fossil mailing list, 2011-10-04</i>
158		-</blockquote>
	158	+</p>
159	159
160	160	<li>github is such a pale shadow of what fossil does.
161	161
162		-<blockquote>
	162	+<p class="local-indent">
163	163	<i>dkf on the Tcl chatroom, 2013-12-06</i>
164		-</blockquote>
	164	+</p>
165	165
166	166	<li>[With fossil] I actually enjoy keeping track of source files again.
167	167
168		-<blockquote>
	168	+<p class="local-indent">
169	169	<a href="https://wholesomedonut.prose.sh/using-fossil-not-git">https://wholesomedonut.prose.sh/using-fossil-not-git</a>
170		-</blockquote>
	170	+</p>
171	171	</ol>
172	172

	--- www/quotes.wiki
	+++ www/quotes.wiki
	@@ -2,115 +2,115 @@
2
3	The following are collected quotes from various forums and blogs about
4	Fossil, Git, and DVCSes in general. This collection is put together
5	by the creator of Fossil, so of course there is selection bias...
6
7	<h2>On The Usability Of Git:</h2>
8
9	<ol>
10	<li>Git approaches the usability of iptables, which is to say, utterly
11	unusable unless you have the manpage tattooed on you arm.
12
13	<blockquote>
14	<i>by mml at [http://news.ycombinator.com/item?id=1433387]</i>
15	</blockquote>
16
17	<li><nowiki>It's simplest to think of the state of your [git] repository
18	as a point in a high-dimensional "code-space", in which branches are
19	represented as n-dimensional membranes, mapping the spatial loci of
20	successive commits onto the projected manifold of each cloned
21	repository.</nowiki>
22
23	<blockquote>
24	<i>by Jonathan Hartley at
25	[https://www.tartley.com/posts/a-guide-to-git-using-spatial-analogies];
26	<br>Quoted here: [https://lwn.net/Articles/420152/].</i>
27	</blockquote>
28
29	<li>Git is not a Prius. Git is a Model T.
30	Its plumbing and wiring sticks out all over the place.
31	You have to be a mechanic to operate it successfully or you'll be
32	stuck on the side of the road when it breaks down.
33	And it <b>will</b> break down.
34
35	<blockquote>
36	<i>Nick Farina at [http://nfarina.com/post/9868516270/git-is-simpler]</i>
37	</blockquote>
38
39	<li>Initial revision of "git", The information manager from hell
40
41	<blockquote>
42	<i>Linus Torvalds - 2005-04-07 22:13:13<br>
43	Commit comment on the very first source-code check-in for git
44	</blockquote>
45
46	<li>I've been experimenting a lot with git at work.
47	Damn, it's complicated.
48	It has things to trip you up with that sane people just wouldn't ever both with
49	including the ability to allow you to commit stuff in such a way that you can't find
50	it again afterwards (!!!)
51	Demented workflow complexity on acid?
52	<p>* dkf really wishes he could use fossil instead</p>
53	<blockquote>
54	<i>by Donal K. Fellow (dkf) on the Tcl/Tk chatroom, 2013-04-09.</i>
55	</blockquote>
56
57	<li>[G]it is <i>designed</i> to forget things.
58
59	<blockquote>
60	<i>[http://www.cs.cmu.edu/~davide/howto/git_lose.html]
61	</blockquote>
62
63	<li>[I]n nearly 31 years of using a computer i have, in total, lost more data to git
64	(while following the instructions!!!) than any other single piece of software.
65
66	<blockquote>
67	<i>Stephan Beal on the [http://www.mail-archive.com/[email protected]/msg17181.html\|Fossil mailing list]
68	2014-09-01.</i>
69	</blockquote>
70
71	<li>If programmers _really_ wanted to help scientists, they'd build a version control
72	system that was more usable than Git.
73
74	<blockquote>
75	<i>Tweet by Greg Wilson @gvwilson on 2015-02-22 17:47</i>
76	</blockquote>
77
78	<li><img src='xkcd-git.gif' align='top'>
79
80	<blockquote><i>Randall Munroe. [http://xkcd.com/1597/]</i></blockquote>
81
82	</ol>
83
84	<h2>On The Usability Of Fossil:</h2>
85
86	<ol>
87	<li value=11>
88	Fossil mesmerizes me with simplicity especially after I struggled to
89	get a bug-tracking system to work with mercurial.
90
91	<blockquote>
92	<i>rawjeev at [https://stackoverflow.com/a/2100469/142454]</i>
93	</blockquote>
94
95	<li>Fossil is the best thing to happen
96	to my development workflow this year, as I am pretty sure that using
97	Git has resulted in the premature death of too many of my brain cells.
98	I'm glad to be able to replace Git in every place that I possibly can
99	with Fossil.
100
101	<blockquote>
102	<i>Joe Prostko at [http://www.mail-archive.com/[email protected]/msg16716.html]
103	</blockquote>
104
105	<li>This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own
106	server, ticketing system, Wiki pages, and a very, very helpful timeline visualization. And
107	the entire program in a single file!
108
109	<blockquote>
110	<i>thunderbong commenting on hacker news: [https://news.ycombinator.com/item?id=9131619]</i>
111	</blockquote>
112
113
114	</ol>
115
116
	@@ -118,33 +118,33 @@
118
119	<ol>
120	<li value=14>
121	After prolonged exposure to fossil, i tend to get the jitters when I work with git...
122
123	<blockquote>
124	<i>sriku - at [https://news.ycombinator.com/item?id=16104427]</i>
125	</blockquote>
126
127
128	<li>
129	Just want to say thanks for fossil making my life easier....
130	Also <nowiki>[for]</nowiki> not having a misanthropic command line interface.
131
132	<blockquote>
133	<i>Joshua Paine at [http://www.mail-archive.com/[email protected]/msg02736.html]</i>
134	</blockquote>
135
136	<li>We use it at a large university to manage code that small teams write.
137	The runs everywhere, ease of installation and portability is something that
138	seems to be a good fit with the environment we have (highly ditrobuted,
139	sometimes very restrictive firewalls, OSX/Win/Linux). We are happy with it
140	and teaching a Msc/Phd student (read complete novice) fossil has just
141	been a smoother ride than Git was.
142
143	<blockquote>
144	<i>viablepanic at [https://www.reddit.com/r/programming/comments/bxcto/why_not_fossil_scm/c0p30b4?utm_source=share&utm_medium=web2x&context=3]</i>
145	</blockquote>
146
147	<li>In the fossil community - and hence in fossil itself - development history
148	is pretty much sacrosanct. The very name "fossil" was to chosen to
149	reflect the unchanging nature of things in that history.
150	<br><br>
	@@ -151,21 +151,21 @@
151	In git (or rather, the git community), the development history is part of
152	the published aspect of the project, so it provides tools for rearranging
153	that history so you can present what you "should" have done rather
154	than what you actually did.
155
156	<blockquote>
157	<i>Mike Meyer on the Fossil mailing list, 2011-10-04</i>
158	</blockquote>
159
160	<li>github is such a pale shadow of what fossil does.
161
162	<blockquote>
163	<i>dkf on the Tcl chatroom, 2013-12-06</i>
164	</blockquote>
165
166	<li>[With fossil] I actually enjoy keeping track of source files again.
167
168	<blockquote>
169	<a href="https://wholesomedonut.prose.sh/using-fossil-not-git">https://wholesomedonut.prose.sh/using-fossil-not-git</a>
170	</blockquote>
171	</ol>
172

	--- www/quotes.wiki
	+++ www/quotes.wiki
	@@ -2,115 +2,115 @@
2
3	The following are collected quotes from various forums and blogs about
4	Fossil, Git, and DVCSes in general. This collection is put together
5	by the creator of Fossil, so of course there is selection bias...
6
7	<h2>On The Usability Of Git</h2>
8
9	<ol>
10	<li>Git approaches the usability of iptables, which is to say, utterly
11	unusable unless you have the manpage tattooed on you arm.
12
13	<p class="local-indent">
14	<i>by mml at [http://news.ycombinator.com/item?id=1433387]</i>
15	</p>
16
17	<li><nowiki>It's simplest to think of the state of your [git] repository
18	as a point in a high-dimensional "code-space", in which branches are
19	represented as n-dimensional membranes, mapping the spatial loci of
20	successive commits onto the projected manifold of each cloned
21	repository.</nowiki>
22
23	<p class="local-indent">
24	<i>by Jonathan Hartley at
25	[https://www.tartley.com/posts/a-guide-to-git-using-spatial-analogies];
26	<br>Quoted here: [https://lwn.net/Articles/420152/].</i>
27	</p>
28
29	<li>Git is not a Prius. Git is a Model T.
30	Its plumbing and wiring sticks out all over the place.
31	You have to be a mechanic to operate it successfully or you'll be
32	stuck on the side of the road when it breaks down.
33	And it <b>will</b> break down.
34
35	<p class="local-indent">
36	<i>Nick Farina at [http://nfarina.com/post/9868516270/git-is-simpler]</i>
37	</p>
38
39	<li>Initial revision of "git", The information manager from hell
40
41	<p class="local-indent">
42	<i>Linus Torvalds - 2005-04-07 22:13:13<br>
43	Commit comment on the very first source-code check-in for git
44	</p>
45
46	<li>I've been experimenting a lot with git at work.
47	Damn, it's complicated.
48	It has things to trip you up with that sane people just wouldn't ever both with
49	including the ability to allow you to commit stuff in such a way that you can't find
50	it again afterwards (!!!)
51	Demented workflow complexity on acid?
52	<p>* dkf really wishes he could use fossil instead</p>
53	<p class="local-indent">
54	<i>by Donal K. Fellow (dkf) on the Tcl/Tk chatroom, 2013-04-09.</i>
55	</p>
56
57	<li>[G]it is <i>designed</i> to forget things.
58
59	<p class="local-indent">
60	<i>[http://www.cs.cmu.edu/~davide/howto/git_lose.html]
61	</p>
62
63	<li>[I]n nearly 31 years of using a computer i have, in total, lost more data to git
64	(while following the instructions!!!) than any other single piece of software.
65
66	<p class="local-indent">
67	<i>Stephan Beal on the [http://www.mail-archive.com/[email protected]/msg17181.html\|Fossil mailing list]
68	2014-09-01.</i>
69	</p>
70
71	<li>If programmers _really_ wanted to help scientists, they'd build a version control
72	system that was more usable than Git.
73
74	<p class="local-indent">
75	<i>Tweet by Greg Wilson @gvwilson on 2015-02-22 17:47</i>
76	</p>
77
78	<li><img src='xkcd-git.gif' align='top'>
79
80	<p class="local-indent"><i>Randall Munroe. [http://xkcd.com/1597/]</i><p>
81
82	</ol>
83
84	<h2>On The Usability Of Fossil</h2>
85
86	<ol>
87	<li value=11>
88	Fossil mesmerizes me with simplicity especially after I struggled to
89	get a bug-tracking system to work with mercurial.
90
91	<p class="local-indent">
92	<i>rawjeev at [https://stackoverflow.com/a/2100469/142454]</i>
93	</p>
94
95	<li>Fossil is the best thing to happen
96	to my development workflow this year, as I am pretty sure that using
97	Git has resulted in the premature death of too many of my brain cells.
98	I'm glad to be able to replace Git in every place that I possibly can
99	with Fossil.
100
101	<p class="local-indent">
102	<i>Joe Prostko at [http://www.mail-archive.com/[email protected]/msg16716.html]
103	</p>
104
105	<li>This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own
106	server, ticketing system, Wiki pages, and a very, very helpful timeline visualization. And
107	the entire program in a single file!
108
109	<p class="local-indent">
110	<i>thunderbong commenting on hacker news: [https://news.ycombinator.com/item?id=9131619]</i>
111	</p>
112
113
114	</ol>
115
116
	@@ -118,33 +118,33 @@
118
119	<ol>
120	<li value=14>
121	After prolonged exposure to fossil, i tend to get the jitters when I work with git...
122
123	<p class="local-indent">
124	<i>sriku - at [https://news.ycombinator.com/item?id=16104427]</i>
125	</p>
126
127
128	<li>
129	Just want to say thanks for fossil making my life easier....
130	Also <nowiki>[for]</nowiki> not having a misanthropic command line interface.
131
132	<p class="local-indent">
133	<i>Joshua Paine at [http://www.mail-archive.com/[email protected]/msg02736.html]</i>
134	</p>
135
136	<li>We use it at a large university to manage code that small teams write.
137	The runs everywhere, ease of installation and portability is something that
138	seems to be a good fit with the environment we have (highly ditrobuted,
139	sometimes very restrictive firewalls, OSX/Win/Linux). We are happy with it
140	and teaching a Msc/Phd student (read complete novice) fossil has just
141	been a smoother ride than Git was.
142
143	<p class="local-indent">
144	<i>viablepanic at [https://www.reddit.com/r/programming/comments/bxcto/why_not_fossil_scm/c0p30b4?utm_source=share&utm_medium=web2x&context=3]</i>
145	</p>
146
147	<li>In the fossil community - and hence in fossil itself - development history
148	is pretty much sacrosanct. The very name "fossil" was to chosen to
149	reflect the unchanging nature of things in that history.
150	<br><br>
	@@ -151,21 +151,21 @@
151	In git (or rather, the git community), the development history is part of
152	the published aspect of the project, so it provides tools for rearranging
153	that history so you can present what you "should" have done rather
154	than what you actually did.
155
156	<p class="local-indent">
157	<i>Mike Meyer on the Fossil mailing list, 2011-10-04</i>
158	</p>
159
160	<li>github is such a pale shadow of what fossil does.
161
162	<p class="local-indent">
163	<i>dkf on the Tcl chatroom, 2013-12-06</i>
164	</p>
165
166	<li>[With fossil] I actually enjoy keeping track of source files again.
167
168	<p class="local-indent">
169	<a href="https://wholesomedonut.prose.sh/using-fossil-not-git">https://wholesomedonut.prose.sh/using-fossil-not-git</a>
170	</p>
171	</ol>
172

M www/scgi.wiki

+4 -4

		--- www/scgi.wiki
		+++ www/scgi.wiki
		@@ -2,26 +2,26 @@
2	2
3	3	To run Fossil using SCGI, start the [/help/server\|fossil server] command
4	4	with the --scgi command-line option. You will probably also want to
5	5	specific an alternative TCP/IP port using --port. For example:
6	6
7		-<blockquote><pre>
	7	+<pre>
8	8	fossil server $REPOSITORY --port 9000 --scgi
9		-</pre></blockquote>
	9	+</pre>
10	10
11	11	Then configure your SCGI-aware web-server to send SCGI requests to port
12	12	9000 on the machine where Fossil is running. A typical configuration for
13	13	this in Nginx is:
14	14
15		-<blockquote><pre>
	15	+<pre>
16	16	location ~ ^/demo_project/ {
17	17	include scgi_params;
18	18	scgi_pass localhost:9000;
19	19	scgi_param SCRIPT_NAME "/demo_project";
20	20	scgi_param HTTPS "on";
21	21	}
22		-</pre></blockquote>
	22	+</pre>
23	23
24	24	Note that Nginx does not normally send either the PATH_INFO or SCRIPT_NAME
25	25	variables via SCGI, but Fossil needs one or the other. So the configuration
26	26	above needs to add SCRIPT_NAME. If you do not do this, Fossil returns an
27	27	error.
28	28

	--- www/scgi.wiki
	+++ www/scgi.wiki
	@@ -2,26 +2,26 @@
2
3	To run Fossil using SCGI, start the [/help/server\|fossil server] command
4	with the --scgi command-line option. You will probably also want to
5	specific an alternative TCP/IP port using --port. For example:
6
7	<blockquote><pre>
8	fossil server $REPOSITORY --port 9000 --scgi
9	</pre></blockquote>
10
11	Then configure your SCGI-aware web-server to send SCGI requests to port
12	9000 on the machine where Fossil is running. A typical configuration for
13	this in Nginx is:
14
15	<blockquote><pre>
16	location ~ ^/demo_project/ {
17	include scgi_params;
18	scgi_pass localhost:9000;
19	scgi_param SCRIPT_NAME "/demo_project";
20	scgi_param HTTPS "on";
21	}
22	</pre></blockquote>
23
24	Note that Nginx does not normally send either the PATH_INFO or SCRIPT_NAME
25	variables via SCGI, but Fossil needs one or the other. So the configuration
26	above needs to add SCRIPT_NAME. If you do not do this, Fossil returns an
27	error.
28

	--- www/scgi.wiki
	+++ www/scgi.wiki
	@@ -2,26 +2,26 @@
2
3	To run Fossil using SCGI, start the [/help/server\|fossil server] command
4	with the --scgi command-line option. You will probably also want to
5	specific an alternative TCP/IP port using --port. For example:
6
7	<pre>
8	fossil server $REPOSITORY --port 9000 --scgi
9	</pre>
10
11	Then configure your SCGI-aware web-server to send SCGI requests to port
12	9000 on the machine where Fossil is running. A typical configuration for
13	this in Nginx is:
14
15	<pre>
16	location ~ ^/demo_project/ {
17	include scgi_params;
18	scgi_pass localhost:9000;
19	scgi_param SCRIPT_NAME "/demo_project";
20	scgi_param HTTPS "on";
21	}
22	</pre>
23
24	Note that Nginx does not normally send either the PATH_INFO or SCRIPT_NAME
25	variables via SCGI, but Fossil needs one or the other. So the configuration
26	above needs to add SCRIPT_NAME. If you do not do this, Fossil returns an
27	error.
28

M www/selfhost.wiki

+6 -6

		--- www/selfhost.wiki
		+++ www/selfhost.wiki
		@@ -30,14 +30,14 @@
30	30	Multiple fossil-based projects can easily be hosted on the same machine,
31	31	even if that machine is itself one of several dozen virtual machines on
32	32	single physical box. The CGI script that runs the canonical Fossil
33	33	self-hosting repository is as follows:
34	34
35		-<blockquote><pre>
	35	+<pre>
36	36	#!/usr/bin/fossil
37	37	repository: /fossil/fossil.fossil
38		-</pre></blockquote>
	38	+</pre>
39	39
40	40	Server (3) ran for 10 years as a CGI script on a shared hosting account at
41	41	<a href="http://www.he.net/">Hurricane Electric</a> in Fremont, CA.
42	42	This server demonstrated the ability of
43	43	Fossil to run on an economical shared-host web account with no
		@@ -48,14 +48,14 @@
48	48	that can run in
49	49	such a restricted environment. The CGI script that ran on the
50	50	Hurricane Electric server was the same as the CGI script shown above,
51	51	except that the pathnames are modified to suit the environment:
52	52
53		-<blockquote><pre>
	53	+<pre>
54	54	#!/home/hwaci/bin/fossil
55	55	repository: /home/hwaci/fossil/fossil.fossil
56		-</pre></blockquote>
	56	+</pre>
57	57
58	58	In recent years, virtual private servers have become a more flexible and
59	59	less expensive hosting option compared to shared hosting accounts.
60	60	So on 2017-07-25, server (3) was moved
61	61	onto a $5/month "droplet" [https://en.wikipedia.org/wiki/Virtual_private_server\|VPS]
		@@ -63,15 +63,15 @@
63	63	located in San Francisco.
64	64
65	65	Server (3) is synchronized with the canonical server (1) by running
66	66	a command similar to the following via cron:
67	67
68		-<blockquote><pre>
	68	+<pre>
69	69	/usr/local/bin/fossil all sync -u
70		-</pre></blockquote>
	70	+</pre>
71	71
72	72	Server (2) is a
73	73	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
74	74	and set up just like the canonical server (1) with the addition of a
75	75	cron job for synchronization. The same cron job also runs the
76	76	[/help?cmd=git\|fossil git export] command after each sync in order to
77	77	[./mirrortogithub.md#ex1\|mirror all changes to GitHub].
78	78

	--- www/selfhost.wiki
	+++ www/selfhost.wiki
	@@ -30,14 +30,14 @@
30	Multiple fossil-based projects can easily be hosted on the same machine,
31	even if that machine is itself one of several dozen virtual machines on
32	single physical box. The CGI script that runs the canonical Fossil
33	self-hosting repository is as follows:
34
35	<blockquote><pre>
36	#!/usr/bin/fossil
37	repository: /fossil/fossil.fossil
38	</pre></blockquote>
39
40	Server (3) ran for 10 years as a CGI script on a shared hosting account at
41	<a href="http://www.he.net/">Hurricane Electric</a> in Fremont, CA.
42	This server demonstrated the ability of
43	Fossil to run on an economical shared-host web account with no
	@@ -48,14 +48,14 @@
48	that can run in
49	such a restricted environment. The CGI script that ran on the
50	Hurricane Electric server was the same as the CGI script shown above,
51	except that the pathnames are modified to suit the environment:
52
53	<blockquote><pre>
54	#!/home/hwaci/bin/fossil
55	repository: /home/hwaci/fossil/fossil.fossil
56	</pre></blockquote>
57
58	In recent years, virtual private servers have become a more flexible and
59	less expensive hosting option compared to shared hosting accounts.
60	So on 2017-07-25, server (3) was moved
61	onto a $5/month "droplet" [https://en.wikipedia.org/wiki/Virtual_private_server\|VPS]
	@@ -63,15 +63,15 @@
63	located in San Francisco.
64
65	Server (3) is synchronized with the canonical server (1) by running
66	a command similar to the following via cron:
67
68	<blockquote><pre>
69	/usr/local/bin/fossil all sync -u
70	</pre></blockquote>
71
72	Server (2) is a
73	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
74	and set up just like the canonical server (1) with the addition of a
75	cron job for synchronization. The same cron job also runs the
76	[/help?cmd=git\|fossil git export] command after each sync in order to
77	[./mirrortogithub.md#ex1\|mirror all changes to GitHub].
78

	--- www/selfhost.wiki
	+++ www/selfhost.wiki
	@@ -30,14 +30,14 @@
30	Multiple fossil-based projects can easily be hosted on the same machine,
31	even if that machine is itself one of several dozen virtual machines on
32	single physical box. The CGI script that runs the canonical Fossil
33	self-hosting repository is as follows:
34
35	<pre>
36	#!/usr/bin/fossil
37	repository: /fossil/fossil.fossil
38	</pre>
39
40	Server (3) ran for 10 years as a CGI script on a shared hosting account at
41	<a href="http://www.he.net/">Hurricane Electric</a> in Fremont, CA.
42	This server demonstrated the ability of
43	Fossil to run on an economical shared-host web account with no
	@@ -48,14 +48,14 @@
48	that can run in
49	such a restricted environment. The CGI script that ran on the
50	Hurricane Electric server was the same as the CGI script shown above,
51	except that the pathnames are modified to suit the environment:
52
53	<pre>
54	#!/home/hwaci/bin/fossil
55	repository: /home/hwaci/fossil/fossil.fossil
56	</pre>
57
58	In recent years, virtual private servers have become a more flexible and
59	less expensive hosting option compared to shared hosting accounts.
60	So on 2017-07-25, server (3) was moved
61	onto a $5/month "droplet" [https://en.wikipedia.org/wiki/Virtual_private_server\|VPS]
	@@ -63,15 +63,15 @@
63	located in San Francisco.
64
65	Server (3) is synchronized with the canonical server (1) by running
66	a command similar to the following via cron:
67
68	<pre>
69	/usr/local/bin/fossil all sync -u
70	</pre>
71
72	Server (2) is a
73	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
74	and set up just like the canonical server (1) with the addition of a
75	cron job for synchronization. The same cron job also runs the
76	[/help?cmd=git\|fossil git export] command after each sync in order to
77	[./mirrortogithub.md#ex1\|mirror all changes to GitHub].
78

M www/server/openbsd/service.wiki

+22 -16

		--- www/server/openbsd/service.wiki
		+++ www/server/openbsd/service.wiki
		@@ -2,13 +2,14 @@
2	2
3	3	OpenBSD provides [https://man.openbsd.org/rc.subr.8\|rc.subr(8)],
4	4	a framework for writing [https://man.openbsd.org/rc.8\|rc(8)] scripts.
5	5
6	6	<h2>Creating the daemon</h2>
	7	+
7	8	Create the file /etc/rc.d/fossil with contents like the following.
8	9
9		-<blockquote><pre>
	10	+<pre>
10	11	#!/bin/ksh
11	12	daemon="/usr/local/bin/fossil" # fossil executable
12	13	daemon_user="_fossil" # user to run fossil as
13	14	daemon_flags="server /home/_fossil/example --repolist --port 8888" # fossil command
14	15
		@@ -15,56 +16,59 @@
15	16	. /etc/rc.d/rc.subr
16	17	# pexp="$daemon server .*" # See below.
17	18	rc_reload=NO # Unsupported by Fossil; 'rcctl reload fossil' kills the process.
18	19	rc_bg=YES # Run in the background, since fossil serve does not daemonize itself
19	20	rc_cmd $1
20		-</pre></blockquote>
	21	+</pre>
21	22
22	23	<h3>pexp</h3>
	24	+
23	25	You may need to uncomment the "pexp=". rc.subr typically
24	26	finds the daemon process based by matching the process name and argument list.
25	27	Without the "pexp=" line, rc.subr would look for this exact command:
26	28
27		-<blockquote><pre>
	29	+<pre>
28	30	/usr/local/bin/fossil server /home/_fossil/example --repolist --port 8888
29		-</pre></blockquote>
	31	+</pre>
30	32
31	33	Depending on the arguments and their order, fossil may rewrite the arguments
32	34	for display in the process listing ([https://man.openbsd.org/ps.1\|ps(1)]),
33	35	so rc.subr may fail to find the process through the default match. The example
34	36	above does not get rewritten, but the same commands in a different order can
35	37	be rewritten.
36	38	For example, when I switch the order of the arguments in "daemon_flags",
37	39
38		-<blockquote><pre>
	40	+<pre>
39	41	/usr/local/bin/fossil server --repolist --port 8888 /home/_fossil/example
40		-</pre></blockquote>
	42	+</pre>
41	43
42	44	the process command is changed to this.
43	45
44		-<blockquote><pre>
	46	+<pre>
45	47	/usr/local/bin/fossil server /home/_fossil/example /home/_fossil/example 8888 /home/_fossil/example
46		-</pre></blockquote>
	48	+</pre>
47	49
48	50	The commented "pexp=" line instructs rc.subr to choose the process whose
49	51	command and arguments text starts with this:
50	52
51		-<blockquote><pre>
	53	+<pre>
52	54	/usr/local/bin/fossil server
53		-</pre></blockquote>
	55	+</pre>
54	56
55	57	<h2>Enabling the daemon</h2>
	58	+
56	59	Once you have created /etc/rc.d/fossil, run these commands.
57	60
58		-<blockquote><pre>
	61	+<pre>
59	62	rcctl enable fossil # add fossil to pkg_scripts in /etc/rc.conf.local
60	63	rcctl start fossil # start the daemon now
61		-</pre></blockquote>
	64	+</pre>
62	65
63	66	The daemon should now be running and set to start at boot.
64	67
65	68	<h2>Multiple daemons</h2>
	69	+
66	70	You may want to serve multiple fossil instances with different options.
67	71	For example,
68	72
69	73	* If different users own different repositories, you may want different users
70	74	to serve different repositories.
		@@ -75,38 +79,40 @@
75	79	To run multiple fossil daemons, create multiple files in /etc/rc.d, and
76	80	enable each of them. Here are two approaches for creating
77	81	the files in /etc/rc.d: Symbolic links and copies.
78	82
79	83	<h3>Symbolic links</h3>
	84	+
80	85	Suppose you want to run one fossil daemon as user "user1" on port 8881
81	86	and another as user "user2" on port 8882. Create the files with
82	87	[https://man.openbsd.org/ln.1\|ln(1)], and configure them to run different
83	88	fossil commands.
84	89
85		-<blockquote><pre>
	90	+<pre>
86	91	cd /etc/rc.d
87	92	ln -s fossil fossil1
88	93	ln -s fossil fossil2
89	94	rcctl enable fossil1 fossil2
90	95	rcctl set fossil1 user user1
91	96	rcctl set fossil2 user user2
92	97	rcctl set fossil1 flags 'server /home/user1/repo1.fossil --port 8881'
93	98	rcctl set fossil2 flags 'server /home/user2/repo2.fossil --port 8882'
94	99	rcctl start fossil1 fossil2
95		-</pre></blockquote>
	100	+</pre>
96	101
97	102	<h3>Copies</h3>
	103	+
98	104	You may want to run fossil daemons that are too different to configure
99	105	just with [https://man.openbsd.org/rcctl.8\|rcctl(8)].
100	106	In particular, you can't change the "pexp" with rcctl.
101	107
102	108	If you want to run fossil commands that are more different,
103	109	you may prefer to create separate files in /etc/rc.d.
104	110	Replace "ln -s" above with "cp" to accomplish this.
105	111
106		-<blockquote><pre>
	112	+<pre>
107	113	cp /etc/rc.d/fossil /etc/rc.d/fossil-user1
108	114	cp /etc/rc.d/fossil /etc/rc.d/fossil-user2
109		-</pre></blockquote>
	115	+</pre>
110	116
111	117	You can still use commands like "rcctl set fossil-user1 flags", but you
112	118	can also edit the "/etc/rc.d/fossil-user1" file.
113	119

	--- www/server/openbsd/service.wiki
	+++ www/server/openbsd/service.wiki
	@@ -2,13 +2,14 @@
2
3	OpenBSD provides [https://man.openbsd.org/rc.subr.8\|rc.subr(8)],
4	a framework for writing [https://man.openbsd.org/rc.8\|rc(8)] scripts.
5
6	<h2>Creating the daemon</h2>

7	Create the file /etc/rc.d/fossil with contents like the following.
8
9	<blockquote><pre>
10	#!/bin/ksh
11	daemon="/usr/local/bin/fossil" # fossil executable
12	daemon_user="_fossil" # user to run fossil as
13	daemon_flags="server /home/_fossil/example --repolist --port 8888" # fossil command
14
	@@ -15,56 +16,59 @@
15	. /etc/rc.d/rc.subr
16	# pexp="$daemon server .*" # See below.
17	rc_reload=NO # Unsupported by Fossil; 'rcctl reload fossil' kills the process.
18	rc_bg=YES # Run in the background, since fossil serve does not daemonize itself
19	rc_cmd $1
20	</pre></blockquote>
21
22	<h3>pexp</h3>

23	You may need to uncomment the "pexp=". rc.subr typically
24	finds the daemon process based by matching the process name and argument list.
25	Without the "pexp=" line, rc.subr would look for this exact command:
26
27	<blockquote><pre>
28	/usr/local/bin/fossil server /home/_fossil/example --repolist --port 8888
29	</pre></blockquote>
30
31	Depending on the arguments and their order, fossil may rewrite the arguments
32	for display in the process listing ([https://man.openbsd.org/ps.1\|ps(1)]),
33	so rc.subr may fail to find the process through the default match. The example
34	above does not get rewritten, but the same commands in a different order can
35	be rewritten.
36	For example, when I switch the order of the arguments in "daemon_flags",
37
38	<blockquote><pre>
39	/usr/local/bin/fossil server --repolist --port 8888 /home/_fossil/example
40	</pre></blockquote>
41
42	the process command is changed to this.
43
44	<blockquote><pre>
45	/usr/local/bin/fossil server /home/_fossil/example /home/_fossil/example 8888 /home/_fossil/example
46	</pre></blockquote>
47
48	The commented "pexp=" line instructs rc.subr to choose the process whose
49	command and arguments text starts with this:
50
51	<blockquote><pre>
52	/usr/local/bin/fossil server
53	</pre></blockquote>
54
55	<h2>Enabling the daemon</h2>

56	Once you have created /etc/rc.d/fossil, run these commands.
57
58	<blockquote><pre>
59	rcctl enable fossil # add fossil to pkg_scripts in /etc/rc.conf.local
60	rcctl start fossil # start the daemon now
61	</pre></blockquote>
62
63	The daemon should now be running and set to start at boot.
64
65	<h2>Multiple daemons</h2>

66	You may want to serve multiple fossil instances with different options.
67	For example,
68
69	* If different users own different repositories, you may want different users
70	to serve different repositories.
	@@ -75,38 +79,40 @@
75	To run multiple fossil daemons, create multiple files in /etc/rc.d, and
76	enable each of them. Here are two approaches for creating
77	the files in /etc/rc.d: Symbolic links and copies.
78
79	<h3>Symbolic links</h3>

80	Suppose you want to run one fossil daemon as user "user1" on port 8881
81	and another as user "user2" on port 8882. Create the files with
82	[https://man.openbsd.org/ln.1\|ln(1)], and configure them to run different
83	fossil commands.
84
85	<blockquote><pre>
86	cd /etc/rc.d
87	ln -s fossil fossil1
88	ln -s fossil fossil2
89	rcctl enable fossil1 fossil2
90	rcctl set fossil1 user user1
91	rcctl set fossil2 user user2
92	rcctl set fossil1 flags 'server /home/user1/repo1.fossil --port 8881'
93	rcctl set fossil2 flags 'server /home/user2/repo2.fossil --port 8882'
94	rcctl start fossil1 fossil2
95	</pre></blockquote>
96
97	<h3>Copies</h3>

98	You may want to run fossil daemons that are too different to configure
99	just with [https://man.openbsd.org/rcctl.8\|rcctl(8)].
100	In particular, you can't change the "pexp" with rcctl.
101
102	If you want to run fossil commands that are more different,
103	you may prefer to create separate files in /etc/rc.d.
104	Replace "ln -s" above with "cp" to accomplish this.
105
106	<blockquote><pre>
107	cp /etc/rc.d/fossil /etc/rc.d/fossil-user1
108	cp /etc/rc.d/fossil /etc/rc.d/fossil-user2
109	</pre></blockquote>
110
111	You can still use commands like "rcctl set fossil-user1 flags", but you
112	can also edit the "/etc/rc.d/fossil-user1" file.
113

	--- www/server/openbsd/service.wiki
	+++ www/server/openbsd/service.wiki
	@@ -2,13 +2,14 @@
2
3	OpenBSD provides [https://man.openbsd.org/rc.subr.8\|rc.subr(8)],
4	a framework for writing [https://man.openbsd.org/rc.8\|rc(8)] scripts.
5
6	<h2>Creating the daemon</h2>
7
8	Create the file /etc/rc.d/fossil with contents like the following.
9
10	<pre>
11	#!/bin/ksh
12	daemon="/usr/local/bin/fossil" # fossil executable
13	daemon_user="_fossil" # user to run fossil as
14	daemon_flags="server /home/_fossil/example --repolist --port 8888" # fossil command
15
	@@ -15,56 +16,59 @@
16	. /etc/rc.d/rc.subr
17	# pexp="$daemon server .*" # See below.
18	rc_reload=NO # Unsupported by Fossil; 'rcctl reload fossil' kills the process.
19	rc_bg=YES # Run in the background, since fossil serve does not daemonize itself
20	rc_cmd $1
21	</pre>
22
23	<h3>pexp</h3>
24
25	You may need to uncomment the "pexp=". rc.subr typically
26	finds the daemon process based by matching the process name and argument list.
27	Without the "pexp=" line, rc.subr would look for this exact command:
28
29	<pre>
30	/usr/local/bin/fossil server /home/_fossil/example --repolist --port 8888
31	</pre>
32
33	Depending on the arguments and their order, fossil may rewrite the arguments
34	for display in the process listing ([https://man.openbsd.org/ps.1\|ps(1)]),
35	so rc.subr may fail to find the process through the default match. The example
36	above does not get rewritten, but the same commands in a different order can
37	be rewritten.
38	For example, when I switch the order of the arguments in "daemon_flags",
39
40	<pre>
41	/usr/local/bin/fossil server --repolist --port 8888 /home/_fossil/example
42	</pre>
43
44	the process command is changed to this.
45
46	<pre>
47	/usr/local/bin/fossil server /home/_fossil/example /home/_fossil/example 8888 /home/_fossil/example
48	</pre>
49
50	The commented "pexp=" line instructs rc.subr to choose the process whose
51	command and arguments text starts with this:
52
53	<pre>
54	/usr/local/bin/fossil server
55	</pre>
56
57	<h2>Enabling the daemon</h2>
58
59	Once you have created /etc/rc.d/fossil, run these commands.
60
61	<pre>
62	rcctl enable fossil # add fossil to pkg_scripts in /etc/rc.conf.local
63	rcctl start fossil # start the daemon now
64	</pre>
65
66	The daemon should now be running and set to start at boot.
67
68	<h2>Multiple daemons</h2>
69
70	You may want to serve multiple fossil instances with different options.
71	For example,
72
73	* If different users own different repositories, you may want different users
74	to serve different repositories.
	@@ -75,38 +79,40 @@
79	To run multiple fossil daemons, create multiple files in /etc/rc.d, and
80	enable each of them. Here are two approaches for creating
81	the files in /etc/rc.d: Symbolic links and copies.
82
83	<h3>Symbolic links</h3>
84
85	Suppose you want to run one fossil daemon as user "user1" on port 8881
86	and another as user "user2" on port 8882. Create the files with
87	[https://man.openbsd.org/ln.1\|ln(1)], and configure them to run different
88	fossil commands.
89
90	<pre>
91	cd /etc/rc.d
92	ln -s fossil fossil1
93	ln -s fossil fossil2
94	rcctl enable fossil1 fossil2
95	rcctl set fossil1 user user1
96	rcctl set fossil2 user user2
97	rcctl set fossil1 flags 'server /home/user1/repo1.fossil --port 8881'
98	rcctl set fossil2 flags 'server /home/user2/repo2.fossil --port 8882'
99	rcctl start fossil1 fossil2
100	</pre>
101
102	<h3>Copies</h3>
103
104	You may want to run fossil daemons that are too different to configure
105	just with [https://man.openbsd.org/rcctl.8\|rcctl(8)].
106	In particular, you can't change the "pexp" with rcctl.
107
108	If you want to run fossil commands that are more different,
109	you may prefer to create separate files in /etc/rc.d.
110	Replace "ln -s" above with "cp" to accomplish this.
111
112	<pre>
113	cp /etc/rc.d/fossil /etc/rc.d/fossil-user1
114	cp /etc/rc.d/fossil /etc/rc.d/fossil-user2
115	</pre>
116
117	You can still use commands like "rcctl set fossil-user1 flags", but you
118	can also edit the "/etc/rc.d/fossil-user1" file.
119

M www/serverext.wiki

+14 -14

		--- www/serverext.wiki
		+++ www/serverext.wiki
		@@ -31,13 +31,13 @@
31	31	[./server/index.html\|server setup].
32	32	If the Fossil server is itself run as
33	33	[./server/any/cgi.md\|CGI], then add a line to the
34	34	[./cgi.wiki#extroot\|CGI script file] that says:
35	35
36		-<blockquote><pre>
	36	+<pre>
37	37	extroot: <i>DIRECTORY</i>
38		-</pre></blockquote>
	38	+</pre>
39	39
40	40	Or, if the Fossil server is being run using the
41	41	"[./server/any/none.md\|fossil server]" or
42	42	"[./server/any/none.md\|fossil ui]" or
43	43	"[./server/any/inetd.md\|fossil http]" commands, then add an extra
		@@ -44,13 +44,13 @@
44	44	"--extroot <i>DIRECTORY</i>" option to that command.
45	45
46	46	The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
47	47	Files in the DOCUMENT_ROOT are accessed via URLs like this:
48	48
49		-<blockquote>
	49	+<pre>
50	50	https://example-project.org/ext/<i>FILENAME</i>
51		-</blockquote>
	51	+</pre>
52	52
53	53	In other words, access files in DOCUMENT_ROOT by appending the filename
54	54	relative to DOCUMENT_ROOT to the [/help?cmd=/ext\|/ext]
55	55	page of the Fossil server.
56	56	Files that are readable but not executable are returned as static
		@@ -60,16 +60,16 @@
60	60
61	61	The source code repository for SQLite is a Fossil server that is run
62	62	as CGI. The URL for the source code repository is [https://sqlite.org/src].
63	63	The CGI script looks like this:
64	64
65		-<blockquote><verbatim>
	65	+<verbatim>
66	66	#!/usr/bin/fossil
67	67	repository: /fossil/sqlite.fossil
68	68	errorlog: /logs/errors.txt
69	69	extroot: /sqlite-src-ext
70		-</verbatim></blockquote>
	70	+</verbatim>
71	71
72	72	The "extroot: /sqlite-src-ext" line tells Fossil that it should look for
73	73	extension CGIs in the /sqlite-src-ext directory. (All of this is happening
74	74	inside of a chroot jail, so putting the document root in a top-level
75	75	directory is a reasonable thing to do.)
		@@ -101,16 +101,16 @@
101	101	<h3>2.2 Example #2</h3>
102	102
103	103	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
104	104	a CGI that looks like this:
105	105
106		-<blockquote><verbatim>
	106	+<verbatim>
107	107	#!/usr/bin/fossil
108	108	repository: /fossil/fossil.fossil
109	109	errorlog: /logs/errors.txt
110	110	extroot: /fossil-extroot
111		-</verbatim></blockquote>
	111	+</verbatim>
112	112
113	113	The extroot for this Fossil server is /fossil-extroot and in that directory
114	114	is an executable file named "fileup1" - another [https://wapp.tcl.tk\|Wapp]
115	115	script. (The extension mechanism is not required to use Wapp. You can use
116	116	any kind of program you like. But the creator of SQLite and Fossil is fond
		@@ -201,13 +201,13 @@
201	201	the webpage. Any <script>...</script> elements within the
202	202	CGI output must include a nonce or else they will be suppressed by the
203	203	web browser. The FOSSIL_NONCE variable contains the value of that nonce.
204	204	So, in other words, to get javascript to work, it must be enclosed in:
205	205
206		-<blockquote><verbatim>
	206	+<verbatim>
207	207	<script nonce='$FOSSIL_NONCE'>...</script>
208		-</verbatim></blockquote>
	208	+</verbatim>
209	209
210	210	Except, of course, the $FOSSIL_NONCE is replaced by the value of the
211	211	FOSSIL_NONCE environment variable.
212	212
213	213	<h3>3.1 Input Content</h3>
		@@ -223,14 +223,14 @@
223	223	few lines of output are parameters intended for the web server that invoked
224	224	the CGI. These are followed by a blank line and then the content.
225	225
226	226	Typical parameter output looks like this:
227	227
228		-<blockquote><verbatim>
	228	+<verbatim>
229	229	Status: 200 OK
230	230	Content-Type: text/html
231		-</verbatim></blockquote>
	231	+</verbatim>
232	232
233	233	CGI programs can return any content type they want - they are not restricted
234	234	to text replies. It is OK for a CGI program to return (for example)
235	235	image/png.
236	236
		@@ -244,15 +244,15 @@
244	244	[/md_rules\|Markdown] into HTML, adding its
245	245	own header and footer text according to the repository skin. Content
246	246	of type "text/html" is normally passed straight through
247	247	unchanged. However, if the text/html content is of the form:
248	248
249		-<blockquote><verbatim>
	249	+<verbatim>
250	250	<div class='fossil-doc' data-title='DOCUMENT TITLE'>
251	251	... HTML content there ...
252	252	</div>
253		-</verbatim></blockquote>
	253	+</verbatim>
254	254
255	255	In other words, if the outer-most markup of the HTML is a <div>
256	256	element with a single class of "fossil-doc",
257	257	then Fossil will adds its own header and footer to the HTML. The
258	258	page title contained in the added header will be extracted from the
259	259

	--- www/serverext.wiki
	+++ www/serverext.wiki
	@@ -31,13 +31,13 @@
31	[./server/index.html\|server setup].
32	If the Fossil server is itself run as
33	[./server/any/cgi.md\|CGI], then add a line to the
34	[./cgi.wiki#extroot\|CGI script file] that says:
35
36	<blockquote><pre>
37	extroot: <i>DIRECTORY</i>
38	</pre></blockquote>
39
40	Or, if the Fossil server is being run using the
41	"[./server/any/none.md\|fossil server]" or
42	"[./server/any/none.md\|fossil ui]" or
43	"[./server/any/inetd.md\|fossil http]" commands, then add an extra
	@@ -44,13 +44,13 @@
44	"--extroot <i>DIRECTORY</i>" option to that command.
45
46	The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
47	Files in the DOCUMENT_ROOT are accessed via URLs like this:
48
49	<blockquote>
50	https://example-project.org/ext/<i>FILENAME</i>
51	</blockquote>
52
53	In other words, access files in DOCUMENT_ROOT by appending the filename
54	relative to DOCUMENT_ROOT to the [/help?cmd=/ext\|/ext]
55	page of the Fossil server.
56	Files that are readable but not executable are returned as static
	@@ -60,16 +60,16 @@
60
61	The source code repository for SQLite is a Fossil server that is run
62	as CGI. The URL for the source code repository is [https://sqlite.org/src].
63	The CGI script looks like this:
64
65	<blockquote><verbatim>
66	#!/usr/bin/fossil
67	repository: /fossil/sqlite.fossil
68	errorlog: /logs/errors.txt
69	extroot: /sqlite-src-ext
70	</verbatim></blockquote>
71
72	The "extroot: /sqlite-src-ext" line tells Fossil that it should look for
73	extension CGIs in the /sqlite-src-ext directory. (All of this is happening
74	inside of a chroot jail, so putting the document root in a top-level
75	directory is a reasonable thing to do.)
	@@ -101,16 +101,16 @@
101	<h3>2.2 Example #2</h3>
102
103	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
104	a CGI that looks like this:
105
106	<blockquote><verbatim>
107	#!/usr/bin/fossil
108	repository: /fossil/fossil.fossil
109	errorlog: /logs/errors.txt
110	extroot: /fossil-extroot
111	</verbatim></blockquote>
112
113	The extroot for this Fossil server is /fossil-extroot and in that directory
114	is an executable file named "fileup1" - another [https://wapp.tcl.tk\|Wapp]
115	script. (The extension mechanism is not required to use Wapp. You can use
116	any kind of program you like. But the creator of SQLite and Fossil is fond
	@@ -201,13 +201,13 @@
201	the webpage. Any <script>...</script> elements within the
202	CGI output must include a nonce or else they will be suppressed by the
203	web browser. The FOSSIL_NONCE variable contains the value of that nonce.
204	So, in other words, to get javascript to work, it must be enclosed in:
205
206	<blockquote><verbatim>
207	<script nonce='$FOSSIL_NONCE'>...</script>
208	</verbatim></blockquote>
209
210	Except, of course, the $FOSSIL_NONCE is replaced by the value of the
211	FOSSIL_NONCE environment variable.
212
213	<h3>3.1 Input Content</h3>
	@@ -223,14 +223,14 @@
223	few lines of output are parameters intended for the web server that invoked
224	the CGI. These are followed by a blank line and then the content.
225
226	Typical parameter output looks like this:
227
228	<blockquote><verbatim>
229	Status: 200 OK
230	Content-Type: text/html
231	</verbatim></blockquote>
232
233	CGI programs can return any content type they want - they are not restricted
234	to text replies. It is OK for a CGI program to return (for example)
235	image/png.
236
	@@ -244,15 +244,15 @@
244	[/md_rules\|Markdown] into HTML, adding its
245	own header and footer text according to the repository skin. Content
246	of type "text/html" is normally passed straight through
247	unchanged. However, if the text/html content is of the form:
248
249	<blockquote><verbatim>
250	<div class='fossil-doc' data-title='DOCUMENT TITLE'>
251	... HTML content there ...
252	</div>
253	</verbatim></blockquote>
254
255	In other words, if the outer-most markup of the HTML is a <div>
256	element with a single class of "fossil-doc",
257	then Fossil will adds its own header and footer to the HTML. The
258	page title contained in the added header will be extracted from the
259

	--- www/serverext.wiki
	+++ www/serverext.wiki
	@@ -31,13 +31,13 @@
31	[./server/index.html\|server setup].
32	If the Fossil server is itself run as
33	[./server/any/cgi.md\|CGI], then add a line to the
34	[./cgi.wiki#extroot\|CGI script file] that says:
35
36	<pre>
37	extroot: <i>DIRECTORY</i>
38	</pre>
39
40	Or, if the Fossil server is being run using the
41	"[./server/any/none.md\|fossil server]" or
42	"[./server/any/none.md\|fossil ui]" or
43	"[./server/any/inetd.md\|fossil http]" commands, then add an extra
	@@ -44,13 +44,13 @@
44	"--extroot <i>DIRECTORY</i>" option to that command.
45
46	The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
47	Files in the DOCUMENT_ROOT are accessed via URLs like this:
48
49	<pre>
50	https://example-project.org/ext/<i>FILENAME</i>
51	</pre>
52
53	In other words, access files in DOCUMENT_ROOT by appending the filename
54	relative to DOCUMENT_ROOT to the [/help?cmd=/ext\|/ext]
55	page of the Fossil server.
56	Files that are readable but not executable are returned as static
	@@ -60,16 +60,16 @@
60
61	The source code repository for SQLite is a Fossil server that is run
62	as CGI. The URL for the source code repository is [https://sqlite.org/src].
63	The CGI script looks like this:
64
65	<verbatim>
66	#!/usr/bin/fossil
67	repository: /fossil/sqlite.fossil
68	errorlog: /logs/errors.txt
69	extroot: /sqlite-src-ext
70	</verbatim>
71
72	The "extroot: /sqlite-src-ext" line tells Fossil that it should look for
73	extension CGIs in the /sqlite-src-ext directory. (All of this is happening
74	inside of a chroot jail, so putting the document root in a top-level
75	directory is a reasonable thing to do.)
	@@ -101,16 +101,16 @@
101	<h3>2.2 Example #2</h3>
102
103	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
104	a CGI that looks like this:
105
106	<verbatim>
107	#!/usr/bin/fossil
108	repository: /fossil/fossil.fossil
109	errorlog: /logs/errors.txt
110	extroot: /fossil-extroot
111	</verbatim>
112
113	The extroot for this Fossil server is /fossil-extroot and in that directory
114	is an executable file named "fileup1" - another [https://wapp.tcl.tk\|Wapp]
115	script. (The extension mechanism is not required to use Wapp. You can use
116	any kind of program you like. But the creator of SQLite and Fossil is fond
	@@ -201,13 +201,13 @@
201	the webpage. Any <script>...</script> elements within the
202	CGI output must include a nonce or else they will be suppressed by the
203	web browser. The FOSSIL_NONCE variable contains the value of that nonce.
204	So, in other words, to get javascript to work, it must be enclosed in:
205
206	<verbatim>
207	<script nonce='$FOSSIL_NONCE'>...</script>
208	</verbatim>
209
210	Except, of course, the $FOSSIL_NONCE is replaced by the value of the
211	FOSSIL_NONCE environment variable.
212
213	<h3>3.1 Input Content</h3>
	@@ -223,14 +223,14 @@
223	few lines of output are parameters intended for the web server that invoked
224	the CGI. These are followed by a blank line and then the content.
225
226	Typical parameter output looks like this:
227
228	<verbatim>
229	Status: 200 OK
230	Content-Type: text/html
231	</verbatim>
232
233	CGI programs can return any content type they want - they are not restricted
234	to text replies. It is OK for a CGI program to return (for example)
235	image/png.
236
	@@ -244,15 +244,15 @@
244	[/md_rules\|Markdown] into HTML, adding its
245	own header and footer text according to the repository skin. Content
246	of type "text/html" is normally passed straight through
247	unchanged. However, if the text/html content is of the form:
248
249	<verbatim>
250	<div class='fossil-doc' data-title='DOCUMENT TITLE'>
251	... HTML content there ...
252	</div>
253	</verbatim>
254
255	In other words, if the outer-most markup of the HTML is a <div>
256	element with a single class of "fossil-doc",
257	then Fossil will adds its own header and footer to the HTML. The
258	page title contained in the added header will be extracted from the
259

M www/tickets.wiki

+2 -2

		--- www/tickets.wiki
		+++ www/tickets.wiki
		@@ -47,11 +47,11 @@
47	47
48	48	The two ticket tables are called TICKET and TICKETCHNG.
49	49	The default schema (as of this writing) for these two tables is shown
50	50	below:
51	51
52		-<blockquote><verbatim>
	52	+<verbatim>
53	53	CREATE TABLE ticket(
54	54	-- Do not change any column that begins with tkt_
55	55	tkt_id INTEGER PRIMARY KEY,
56	56	tkt_uuid TEXT UNIQUE,
57	57	tkt_mtime DATE,
		@@ -78,11 +78,11 @@
78	78	username TEXT,
79	79	mimetype TEXT,
80	80	icomment TEXT
81	81	);
82	82	CREATE INDEX ticketchng_idx1 ON ticketchng(tkt_id, tkt_mtime);
83		-</verbatim></blockquote>
	83	+</verbatim>
84	84
85	85	Generally speaking, there is one row in the TICKETCHNG table for each
86	86	change to each ticket. In other words, there is one row in the
87	87	TICKETCHNG table for each low-level ticket change artifact. The
88	88	TICKET table, on the other hand, contains a summary of the current
89	89

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -47,11 +47,11 @@
47
48	The two ticket tables are called TICKET and TICKETCHNG.
49	The default schema (as of this writing) for these two tables is shown
50	below:
51
52	<blockquote><verbatim>
53	CREATE TABLE ticket(
54	-- Do not change any column that begins with tkt_
55	tkt_id INTEGER PRIMARY KEY,
56	tkt_uuid TEXT UNIQUE,
57	tkt_mtime DATE,
	@@ -78,11 +78,11 @@
78	username TEXT,
79	mimetype TEXT,
80	icomment TEXT
81	);
82	CREATE INDEX ticketchng_idx1 ON ticketchng(tkt_id, tkt_mtime);
83	</verbatim></blockquote>
84
85	Generally speaking, there is one row in the TICKETCHNG table for each
86	change to each ticket. In other words, there is one row in the
87	TICKETCHNG table for each low-level ticket change artifact. The
88	TICKET table, on the other hand, contains a summary of the current
89

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -47,11 +47,11 @@
47
48	The two ticket tables are called TICKET and TICKETCHNG.
49	The default schema (as of this writing) for these two tables is shown
50	below:
51
52	<verbatim>
53	CREATE TABLE ticket(
54	-- Do not change any column that begins with tkt_
55	tkt_id INTEGER PRIMARY KEY,
56	tkt_uuid TEXT UNIQUE,
57	tkt_mtime DATE,
	@@ -78,11 +78,11 @@
78	username TEXT,
79	mimetype TEXT,
80	icomment TEXT
81	);
82	CREATE INDEX ticketchng_idx1 ON ticketchng(tkt_id, tkt_mtime);
83	</verbatim>
84
85	Generally speaking, there is one row in the TICKETCHNG table for each
86	change to each ticket. In other words, there is one row in the
87	TICKETCHNG table for each low-level ticket change artifact. The
88	TICKET table, on the other hand, contains a summary of the current
89

M www/unvers.wiki

+6 -6

		--- www/unvers.wiki
		+++ www/unvers.wiki
		@@ -33,15 +33,15 @@
33	33	<h2>Syncing Unversioned Files</h2>
34	34
35	35	Unversioned content does not sync between repositories by default.
36	36	One must request it via commands such as:
37	37
38		-<blockquote><pre>
	38	+<pre>
39	39	fossil sync <b>-u</b>
40	40	fossil clone <b>-u</b> <i>URL local-repo-name</i>
41	41	fossil unversioned sync
42		-</pre></blockquote>
	42	+</pre>
43	43
44	44	The [/help?cmd=sync\|fossil sync] and [/help?cmd=clone\|fossil clone]
45	45	commands will synchronize unversioned content if and only if they're
46	46	given the "-u" (or "--unversioned") command-line option. The
47	47	[/help?cmd=unversioned\|fossil unversioned sync] command synchronizes the
		@@ -71,11 +71,11 @@
71	71	files. This is not an interface spec and hence subject to change.)</i>
72	72
73	73	Unversioned content is stored in the repository in the
74	74	"unversioned" table:
75	75
76		-<blockquote><pre>
	76	+<pre>
77	77	CREATE TABLE unversioned(
78	78	uvid INTEGER PRIMARY KEY AUTOINCREMENT, -- unique ID for this file
79	79	name TEXT UNIQUE, -- Name of the file
80	80	rcvid INTEGER, -- From whence this file was received
81	81	mtime DATETIME, -- Last change (seconds since 1970)
		@@ -82,21 +82,21 @@
82	82	hash TEXT, -- SHA1 or SHA3-256 hash of uncompressed content
83	83	sz INTEGER, -- Size of uncompressed content
84	84	encoding INT, -- 0: plaintext 1: zlib compressed
85	85	content BLOB -- File content
86	86	);
87		-</pre></blockquote>
	87	+</pre>
88	88
89	89	Fossil does not create the table ahead of need.
90	90	If there are no unversioned files in the repository, the
91	91	"unversioned" table will not exist. Consequently,
92	92	one simple way to purge all unversioned content from a repository
93	93	is to run:
94	94
95		-<blockquote><pre>
	95	+<pre>
96	96	fossil sql "DROP TABLE unversioned; VACUUM;"
97		-</pre></blockquote>
	97	+</pre>
98	98
99	99	Lacking history for unversioned files, Fossil does not attempt delta
100	100	compression on them.
101	101
102	102	Fossil servers exchange unversioned content whole; it does not attempt
103	103

	--- www/unvers.wiki
	+++ www/unvers.wiki
	@@ -33,15 +33,15 @@
33	<h2>Syncing Unversioned Files</h2>
34
35	Unversioned content does not sync between repositories by default.
36	One must request it via commands such as:
37
38	<blockquote><pre>
39	fossil sync <b>-u</b>
40	fossil clone <b>-u</b> <i>URL local-repo-name</i>
41	fossil unversioned sync
42	</pre></blockquote>
43
44	The [/help?cmd=sync\|fossil sync] and [/help?cmd=clone\|fossil clone]
45	commands will synchronize unversioned content if and only if they're
46	given the "-u" (or "--unversioned") command-line option. The
47	[/help?cmd=unversioned\|fossil unversioned sync] command synchronizes the
	@@ -71,11 +71,11 @@
71	files. This is not an interface spec and hence subject to change.)</i>
72
73	Unversioned content is stored in the repository in the
74	"unversioned" table:
75
76	<blockquote><pre>
77	CREATE TABLE unversioned(
78	uvid INTEGER PRIMARY KEY AUTOINCREMENT, -- unique ID for this file
79	name TEXT UNIQUE, -- Name of the file
80	rcvid INTEGER, -- From whence this file was received
81	mtime DATETIME, -- Last change (seconds since 1970)
	@@ -82,21 +82,21 @@
82	hash TEXT, -- SHA1 or SHA3-256 hash of uncompressed content
83	sz INTEGER, -- Size of uncompressed content
84	encoding INT, -- 0: plaintext 1: zlib compressed
85	content BLOB -- File content
86	);
87	</pre></blockquote>
88
89	Fossil does not create the table ahead of need.
90	If there are no unversioned files in the repository, the
91	"unversioned" table will not exist. Consequently,
92	one simple way to purge all unversioned content from a repository
93	is to run:
94
95	<blockquote><pre>
96	fossil sql "DROP TABLE unversioned; VACUUM;"
97	</pre></blockquote>
98
99	Lacking history for unversioned files, Fossil does not attempt delta
100	compression on them.
101
102	Fossil servers exchange unversioned content whole; it does not attempt
103

	--- www/unvers.wiki
	+++ www/unvers.wiki
	@@ -33,15 +33,15 @@
33	<h2>Syncing Unversioned Files</h2>
34
35	Unversioned content does not sync between repositories by default.
36	One must request it via commands such as:
37
38	<pre>
39	fossil sync <b>-u</b>
40	fossil clone <b>-u</b> <i>URL local-repo-name</i>
41	fossil unversioned sync
42	</pre>
43
44	The [/help?cmd=sync\|fossil sync] and [/help?cmd=clone\|fossil clone]
45	commands will synchronize unversioned content if and only if they're
46	given the "-u" (or "--unversioned") command-line option. The
47	[/help?cmd=unversioned\|fossil unversioned sync] command synchronizes the
	@@ -71,11 +71,11 @@
71	files. This is not an interface spec and hence subject to change.)</i>
72
73	Unversioned content is stored in the repository in the
74	"unversioned" table:
75
76	<pre>
77	CREATE TABLE unversioned(
78	uvid INTEGER PRIMARY KEY AUTOINCREMENT, -- unique ID for this file
79	name TEXT UNIQUE, -- Name of the file
80	rcvid INTEGER, -- From whence this file was received
81	mtime DATETIME, -- Last change (seconds since 1970)
	@@ -82,21 +82,21 @@
82	hash TEXT, -- SHA1 or SHA3-256 hash of uncompressed content
83	sz INTEGER, -- Size of uncompressed content
84	encoding INT, -- 0: plaintext 1: zlib compressed
85	content BLOB -- File content
86	);
87	</pre>
88
89	Fossil does not create the table ahead of need.
90	If there are no unversioned files in the repository, the
91	"unversioned" table will not exist. Consequently,
92	one simple way to purge all unversioned content from a repository
93	is to run:
94
95	<pre>
96	fossil sql "DROP TABLE unversioned; VACUUM;"
97	</pre>
98
99	Lacking history for unversioned files, Fossil does not attempt delta
100	compression on them.
101
102	Fossil servers exchange unversioned content whole; it does not attempt
103

Fossil SCM

Keyboard Shortcuts