93cee1f56e5… — Fossil SCM

M www/aboutcgi.wiki

+1 -1

		--- www/aboutcgi.wiki
		+++ www/aboutcgi.wiki
		@@ -184,11 +184,11 @@
184	184	a repository. The PATH_INFO is shortened by removing
185	185	"subdir/three/" leaving it at just "timeline".
186	186	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
187	187	requested is "timeline".
188	188	</ol>
189		-<a name="cgivar"></a>
	189	+<a id="cgivar"></a>
190	190	The web server sets many environment variables in step 2 in addition
191	191	to just PATH_INFO. The following diagram shows a few of these variables
192	192	and their relationship to the request URL:
193	193	<pre>
194	194	REQUEST_URI
195	195

	--- www/aboutcgi.wiki
	+++ www/aboutcgi.wiki
	@@ -184,11 +184,11 @@
184	a repository. The PATH_INFO is shortened by removing
185	"subdir/three/" leaving it at just "timeline".
186	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
187	requested is "timeline".
188	</ol>
189	<a name="cgivar"></a>
190	The web server sets many environment variables in step 2 in addition
191	to just PATH_INFO. The following diagram shows a few of these variables
192	and their relationship to the request URL:
193	<pre>
194	REQUEST_URI
195

	--- www/aboutcgi.wiki
	+++ www/aboutcgi.wiki
	@@ -184,11 +184,11 @@
184	a repository. The PATH_INFO is shortened by removing
185	"subdir/three/" leaving it at just "timeline".
186	<li> Fossil looks at the rest of PATH_INFO to see that the webpage
187	requested is "timeline".
188	</ol>
189	<a id="cgivar"></a>
190	The web server sets many environment variables in step 2 in addition
191	to just PATH_INFO. The following diagram shows a few of these variables
192	and their relationship to the request URL:
193	<pre>
194	REQUEST_URI
195

M www/adding_code.wiki

+2 -4

		--- www/adding_code.wiki
		+++ www/adding_code.wiki
		@@ -102,12 +102,11 @@
102	102	It is recommended that you try this.
103	103
104	104	Be sure to [/help/add\|fossil add] your new source file to the self-hosting
105	105	Fossil repository and then [/help/commit\|commit] your changes!
106	106
107		-<a name="newcmd"></a>
108		-<h2>4.0 Creating A New Command</h2>
	107	+<h2 id="newcmd">4.0 Creating A New Command</h2>
109	108
110	109	By "commands" we mean the keywords that follow "fossil" when invoking
111	110	Fossil from the command-line. So, for example, in
112	111
113	112	<b>fossil diff xyzzy.c</b>
		@@ -168,12 +167,11 @@
168	167	the working check-out. Study implementations of existing commands
169	168	to get an idea of how things are done. You can easily find the implementations
170	169	of existing commands by searching for "COMMAND: <i>name</i>" in the
171	170	files of the "src/" directory.
172	171
173		-<a name="newpage"></a>
174		-<h2>5.0 Creating A New Web Page</h2>
	172	+<h2 id="newpage">5.0 Creating A New Web Page</h2>
175	173
176	174	As with commands, new webpages can be added simply by inserting a function
177	175	that generates the webpage together with a special header comment. A
178	176	template follows:
179	177
180	178

	--- www/adding_code.wiki
	+++ www/adding_code.wiki
	@@ -102,12 +102,11 @@
102	It is recommended that you try this.
103
104	Be sure to [/help/add\|fossil add] your new source file to the self-hosting
105	Fossil repository and then [/help/commit\|commit] your changes!
106
107	<a name="newcmd"></a>
108	<h2>4.0 Creating A New Command</h2>
109
110	By "commands" we mean the keywords that follow "fossil" when invoking
111	Fossil from the command-line. So, for example, in
112
113	<b>fossil diff xyzzy.c</b>
	@@ -168,12 +167,11 @@
168	the working check-out. Study implementations of existing commands
169	to get an idea of how things are done. You can easily find the implementations
170	of existing commands by searching for "COMMAND: <i>name</i>" in the
171	files of the "src/" directory.
172
173	<a name="newpage"></a>
174	<h2>5.0 Creating A New Web Page</h2>
175
176	As with commands, new webpages can be added simply by inserting a function
177	that generates the webpage together with a special header comment. A
178	template follows:
179
180

	--- www/adding_code.wiki
	+++ www/adding_code.wiki
	@@ -102,12 +102,11 @@
102	It is recommended that you try this.
103
104	Be sure to [/help/add\|fossil add] your new source file to the self-hosting
105	Fossil repository and then [/help/commit\|commit] your changes!
106
107	<h2 id="newcmd">4.0 Creating A New Command</h2>

108
109	By "commands" we mean the keywords that follow "fossil" when invoking
110	Fossil from the command-line. So, for example, in
111
112	<b>fossil diff xyzzy.c</b>
	@@ -168,12 +167,11 @@
167	the working check-out. Study implementations of existing commands
168	to get an idea of how things are done. You can easily find the implementations
169	of existing commands by searching for "COMMAND: <i>name</i>" in the
170	files of the "src/" directory.
171
172	<h2 id="newpage">5.0 Creating A New Web Page</h2>

173
174	As with commands, new webpages can be added simply by inserting a function
175	that generates the webpage together with a special header comment. A
176	template follows:
177
178

M www/caps/admin-v-setup.md

+11 -11

		--- www/caps/admin-v-setup.md
		+++ www/caps/admin-v-setup.md
		@@ -7,11 +7,11 @@
7	7	* [How Moderation Works](../forum.wiki#moderation)
8	8	* [Users vs Subscribers](../alerts.md#uvs)
9	9	* [Defense Against Spiders](../antibot.wiki)
10	10
11	11
12		-## <a name="philosophy"></a>Philosophical Core
	12	+## <a id="philosophy"></a>Philosophical Core
13	13
14	14	The Setup user "owns" the Fossil repository and may delegate a subset of
15	15	that power to one or more Admin users.
16	16
17	17	The Setup user can grant Admin capability and take it away, but Admin
		@@ -57,11 +57,11 @@
57	57	[bc]: ../blockchain.md
58	58	[ucap]: ./index.md#ucap
59	59	[uv]: ../unvers.wiki
60	60
61	61
62		-## <a name="binary"></a>No Granularity
	62	+## <a id="binary"></a>No Granularity
63	63
64	64	Fossil doesn’t make any distinction between these two user types beyond
65	65	this binary choice: Setup or Admin.
66	66
67	67	A few features of Fossil are broken down so that only part of the
		@@ -91,17 +91,17 @@
91	91	assign one more each to the five sections of a skin? (Header, Footer,
92	92	CSS, JavaScript, and Details.) It quickly becomes unmanageable.
93	93
94	94
95	95
96		-## <a name="capgroups"></a>Capability Groups
	96	+## <a id="capgroups"></a>Capability Groups
97	97
98	98	We can break up the set of powers the Admin user capability grants into
99	99	several groups, then defend each group as a coherent whole.
100	100
101	101
102		-### <a name="security"></a>Security
	102	+### <a id="security"></a>Security
103	103
104	104	While establishing the Fossil repository's security policy is a task for
105	105	the Setup user, maintaining that policy is something that Fossil
106	106	allows a Setup user to delegate to trustworthy users via the Admin user
107	107	capability:
		@@ -134,11 +134,11 @@
134	134	Admin-only users have these abilities. Think of a large IT organization:
135	135	if the CIO hires a [tiger team][tt] to test the company's internal IT
136	136	defenses, the line grunts fix the reported problems, not the CIO.
137	137
138	138
139		-### <a name="administrivia"></a>Administrivia
	139	+### <a id="administrivia"></a>Administrivia
140	140
141	141	It is perfectly fine for a Fossil repository to only have Setup users,
142	142	no Admin users. The smaller the repository, the more likely the
143	143	repository has no Admin-only users. If the Setup user neither needs nor
144	144	wants to grant Admin power to others, there is no requirement in Fossil
		@@ -204,11 +204,11 @@
204	204
205	205	[ale]: ../alerts.md
206	206	[shun]: ../shunning.wiki
207	207
208	208
209		-### <a name="cosmetics"></a>Cosmetics
	209	+### <a id="cosmetics"></a>Cosmetics
210	210
211	211	While the Setup user is responsible for setting up the initial "look" of
212	212	a Fossil repository, the Setup user entrusts Admin users with
213	213	maintaining that look. An Admin-only user therefore has the following
214	214	special abilities:
		@@ -227,11 +227,11 @@
227	227	possibly even the back-end finances of a project. This is why we began
228	228	this document with a philosophical discussion: if you cannot entrust a
229	229	user with these powers, you should not grant that user Admin capability.
230	230
231	231
232		-## <a name="clones"></a>Clones and Backups
	232	+## <a id="clones"></a>Clones and Backups
233	233
234	234	Fossil is a distributed version control system, which has direct
235	235	effects on the “Setup user” concept in the face of clones. When you
236	236	clone a repository, your local user becomes a Setup user on the local
237	237	clone even if you are not one on the remote repository. This may be
		@@ -248,11 +248,11 @@
248	248	fidelity of clone-as-backup, which we cover [elsewhere](../backup.md).
249	249	We strongly encourage you to read that document if you expect to use a
250	250	clone as a complete replacement for the remote repository.
251	251
252	252
253		-## <a name="apsu"></a>The All-Powerful Setup User
	253	+## <a id="apsu"></a>The All-Powerful Setup User
254	254
255	255	Setup users get [every user capability](./ref.html) of Fossil except for
256	256	[two exceptionally dangerous capabilities](#dcap), which they can later
257	257	grant to themselves or to others.
258	258
		@@ -384,19 +384,19 @@
384	384	where you do not have Setup caps. This is why `ui` always binds to
385	385	`localhost` without needing the `--localhost` flag: in this mode, anyone
386	386	who can connect to that repo’s web UI has full power over that repo.
387	387
388	388
389		-## <a name="dcap"></a>Dangerous Capabilities Initially Denied to Everyone
	389	+## <a id="dcap"></a>Dangerous Capabilities Initially Denied to Everyone
390	390
391	391	There are two capabilities that Fossil doesn’t grant by default to Setup
392	392	or Admin users automatically. They are exceptionally dangerous, so
393	393	Fossil makes these users grant themselves (or others) these capabilities
394	394	deliberately, hopefully after careful consideration.
395	395
396	396
397		-### <a name="y"></a>Write Unversioned
	397	+### <a id="y"></a>Write Unversioned
398	398
399	399	Fossil currently doesn’t distinguish the sub-operations of
400	400	[`fossil uv`](/help?cmd=uv); they’re all covered by [WrUnver][capy]
401	401	(“y”) capability. Since some of these operations are unconditionally
402	402	destructive due to the nature of unversioned content, and since this
		@@ -412,11 +412,11 @@
412	412	affairs will continue until your user either gets cap “y” and syncs that
413	413	content with its parent or you say `fossil uv revert` to make your local
414	414	unversioned content table match that of its parent repo.
415	415
416	416
417		-### <a name="x"></a>Private Branch Push
	417	+### <a id="x"></a>Private Branch Push
418	418
419	419	For private branches to remain private, they must never be accidentally
420	420	pushed to a public repository. It can be [difficult to impossible][shun]
421	421	to recover from such a mistake, so nobody gets [Private][capx] (“x”)
422	422	capability on a Fossil repo by default, not even Admin or Setup users.
423	423

	--- www/caps/admin-v-setup.md
	+++ www/caps/admin-v-setup.md
	@@ -7,11 +7,11 @@
7	* [How Moderation Works](../forum.wiki#moderation)
8	* [Users vs Subscribers](../alerts.md#uvs)
9	* [Defense Against Spiders](../antibot.wiki)
10
11
12	## <a name="philosophy"></a>Philosophical Core
13
14	The Setup user "owns" the Fossil repository and may delegate a subset of
15	that power to one or more Admin users.
16
17	The Setup user can grant Admin capability and take it away, but Admin
	@@ -57,11 +57,11 @@
57	[bc]: ../blockchain.md
58	[ucap]: ./index.md#ucap
59	[uv]: ../unvers.wiki
60
61
62	## <a name="binary"></a>No Granularity
63
64	Fossil doesn’t make any distinction between these two user types beyond
65	this binary choice: Setup or Admin.
66
67	A few features of Fossil are broken down so that only part of the
	@@ -91,17 +91,17 @@
91	assign one more each to the five sections of a skin? (Header, Footer,
92	CSS, JavaScript, and Details.) It quickly becomes unmanageable.
93
94
95
96	## <a name="capgroups"></a>Capability Groups
97
98	We can break up the set of powers the Admin user capability grants into
99	several groups, then defend each group as a coherent whole.
100
101
102	### <a name="security"></a>Security
103
104	While establishing the Fossil repository's security policy is a task for
105	the Setup user, maintaining that policy is something that Fossil
106	allows a Setup user to delegate to trustworthy users via the Admin user
107	capability:
	@@ -134,11 +134,11 @@
134	Admin-only users have these abilities. Think of a large IT organization:
135	if the CIO hires a [tiger team][tt] to test the company's internal IT
136	defenses, the line grunts fix the reported problems, not the CIO.
137
138
139	### <a name="administrivia"></a>Administrivia
140
141	It is perfectly fine for a Fossil repository to only have Setup users,
142	no Admin users. The smaller the repository, the more likely the
143	repository has no Admin-only users. If the Setup user neither needs nor
144	wants to grant Admin power to others, there is no requirement in Fossil
	@@ -204,11 +204,11 @@
204
205	[ale]: ../alerts.md
206	[shun]: ../shunning.wiki
207
208
209	### <a name="cosmetics"></a>Cosmetics
210
211	While the Setup user is responsible for setting up the initial "look" of
212	a Fossil repository, the Setup user entrusts Admin users with
213	maintaining that look. An Admin-only user therefore has the following
214	special abilities:
	@@ -227,11 +227,11 @@
227	possibly even the back-end finances of a project. This is why we began
228	this document with a philosophical discussion: if you cannot entrust a
229	user with these powers, you should not grant that user Admin capability.
230
231
232	## <a name="clones"></a>Clones and Backups
233
234	Fossil is a distributed version control system, which has direct
235	effects on the “Setup user” concept in the face of clones. When you
236	clone a repository, your local user becomes a Setup user on the local
237	clone even if you are not one on the remote repository. This may be
	@@ -248,11 +248,11 @@
248	fidelity of clone-as-backup, which we cover [elsewhere](../backup.md).
249	We strongly encourage you to read that document if you expect to use a
250	clone as a complete replacement for the remote repository.
251
252
253	## <a name="apsu"></a>The All-Powerful Setup User
254
255	Setup users get [every user capability](./ref.html) of Fossil except for
256	[two exceptionally dangerous capabilities](#dcap), which they can later
257	grant to themselves or to others.
258
	@@ -384,19 +384,19 @@
384	where you do not have Setup caps. This is why `ui` always binds to
385	`localhost` without needing the `--localhost` flag: in this mode, anyone
386	who can connect to that repo’s web UI has full power over that repo.
387
388
389	## <a name="dcap"></a>Dangerous Capabilities Initially Denied to Everyone
390
391	There are two capabilities that Fossil doesn’t grant by default to Setup
392	or Admin users automatically. They are exceptionally dangerous, so
393	Fossil makes these users grant themselves (or others) these capabilities
394	deliberately, hopefully after careful consideration.
395
396
397	### <a name="y"></a>Write Unversioned
398
399	Fossil currently doesn’t distinguish the sub-operations of
400	[`fossil uv`](/help?cmd=uv); they’re all covered by [WrUnver][capy]
401	(“y”) capability. Since some of these operations are unconditionally
402	destructive due to the nature of unversioned content, and since this
	@@ -412,11 +412,11 @@
412	affairs will continue until your user either gets cap “y” and syncs that
413	content with its parent or you say `fossil uv revert` to make your local
414	unversioned content table match that of its parent repo.
415
416
417	### <a name="x"></a>Private Branch Push
418
419	For private branches to remain private, they must never be accidentally
420	pushed to a public repository. It can be [difficult to impossible][shun]
421	to recover from such a mistake, so nobody gets [Private][capx] (“x”)
422	capability on a Fossil repo by default, not even Admin or Setup users.
423

	--- www/caps/admin-v-setup.md
	+++ www/caps/admin-v-setup.md
	@@ -7,11 +7,11 @@
7	* [How Moderation Works](../forum.wiki#moderation)
8	* [Users vs Subscribers](../alerts.md#uvs)
9	* [Defense Against Spiders](../antibot.wiki)
10
11
12	## <a id="philosophy"></a>Philosophical Core
13
14	The Setup user "owns" the Fossil repository and may delegate a subset of
15	that power to one or more Admin users.
16
17	The Setup user can grant Admin capability and take it away, but Admin
	@@ -57,11 +57,11 @@
57	[bc]: ../blockchain.md
58	[ucap]: ./index.md#ucap
59	[uv]: ../unvers.wiki
60
61
62	## <a id="binary"></a>No Granularity
63
64	Fossil doesn’t make any distinction between these two user types beyond
65	this binary choice: Setup or Admin.
66
67	A few features of Fossil are broken down so that only part of the
	@@ -91,17 +91,17 @@
91	assign one more each to the five sections of a skin? (Header, Footer,
92	CSS, JavaScript, and Details.) It quickly becomes unmanageable.
93
94
95
96	## <a id="capgroups"></a>Capability Groups
97
98	We can break up the set of powers the Admin user capability grants into
99	several groups, then defend each group as a coherent whole.
100
101
102	### <a id="security"></a>Security
103
104	While establishing the Fossil repository's security policy is a task for
105	the Setup user, maintaining that policy is something that Fossil
106	allows a Setup user to delegate to trustworthy users via the Admin user
107	capability:
	@@ -134,11 +134,11 @@
134	Admin-only users have these abilities. Think of a large IT organization:
135	if the CIO hires a [tiger team][tt] to test the company's internal IT
136	defenses, the line grunts fix the reported problems, not the CIO.
137
138
139	### <a id="administrivia"></a>Administrivia
140
141	It is perfectly fine for a Fossil repository to only have Setup users,
142	no Admin users. The smaller the repository, the more likely the
143	repository has no Admin-only users. If the Setup user neither needs nor
144	wants to grant Admin power to others, there is no requirement in Fossil
	@@ -204,11 +204,11 @@
204
205	[ale]: ../alerts.md
206	[shun]: ../shunning.wiki
207
208
209	### <a id="cosmetics"></a>Cosmetics
210
211	While the Setup user is responsible for setting up the initial "look" of
212	a Fossil repository, the Setup user entrusts Admin users with
213	maintaining that look. An Admin-only user therefore has the following
214	special abilities:
	@@ -227,11 +227,11 @@
227	possibly even the back-end finances of a project. This is why we began
228	this document with a philosophical discussion: if you cannot entrust a
229	user with these powers, you should not grant that user Admin capability.
230
231
232	## <a id="clones"></a>Clones and Backups
233
234	Fossil is a distributed version control system, which has direct
235	effects on the “Setup user” concept in the face of clones. When you
236	clone a repository, your local user becomes a Setup user on the local
237	clone even if you are not one on the remote repository. This may be
	@@ -248,11 +248,11 @@
248	fidelity of clone-as-backup, which we cover [elsewhere](../backup.md).
249	We strongly encourage you to read that document if you expect to use a
250	clone as a complete replacement for the remote repository.
251
252
253	## <a id="apsu"></a>The All-Powerful Setup User
254
255	Setup users get [every user capability](./ref.html) of Fossil except for
256	[two exceptionally dangerous capabilities](#dcap), which they can later
257	grant to themselves or to others.
258
	@@ -384,19 +384,19 @@
384	where you do not have Setup caps. This is why `ui` always binds to
385	`localhost` without needing the `--localhost` flag: in this mode, anyone
386	who can connect to that repo’s web UI has full power over that repo.
387
388
389	## <a id="dcap"></a>Dangerous Capabilities Initially Denied to Everyone
390
391	There are two capabilities that Fossil doesn’t grant by default to Setup
392	or Admin users automatically. They are exceptionally dangerous, so
393	Fossil makes these users grant themselves (or others) these capabilities
394	deliberately, hopefully after careful consideration.
395
396
397	### <a id="y"></a>Write Unversioned
398
399	Fossil currently doesn’t distinguish the sub-operations of
400	[`fossil uv`](/help?cmd=uv); they’re all covered by [WrUnver][capy]
401	(“y”) capability. Since some of these operations are unconditionally
402	destructive due to the nature of unversioned content, and since this
	@@ -412,11 +412,11 @@
412	affairs will continue until your user either gets cap “y” and syncs that
413	content with its parent or you say `fossil uv revert` to make your local
414	unversioned content table match that of its parent repo.
415
416
417	### <a id="x"></a>Private Branch Push
418
419	For private branches to remain private, they must never be accidentally
420	pushed to a public repository. It can be [difficult to impossible][shun]
421	to recover from such a mistake, so nobody gets [Private][capx] (“x”)
422	capability on a Fossil repo by default, not even Admin or Setup users.
423

M www/caps/impl.md

+3 -3

		--- www/caps/impl.md
		+++ www/caps/impl.md
		@@ -1,8 +1,8 @@
1	1	# Implementation Details of User Capabilities
2	2
3		-## <a name="choices"></a>Capability Letter Choices
	3	+## <a id="choices"></a>Capability Letter Choices
4	4
5	5	We [assigned][ref] user capability characters using only lowercase ASCII
6	6	letters at first, so those are the most important within Fossil: they
7	7	control the functions most core to Fossil’s operation. Once we used up
8	8	most of the lowercase letters, we started using uppercase, and then
		@@ -19,11 +19,11 @@
19	19	lots of letters to choose from. There is still hope for good future
20	20	mnemonic assignments among the uppercase letters, which are mostly still
21	21	unused.
22	22
23	23
24		-## <a name="bitfield"></a>Why Not Bitfields?
	24	+## <a id="bitfield"></a>Why Not Bitfields?
25	25
26	26	Some may question the use of ASCII character strings for [capability
27	27	sets][ucap] instead of bitfields, which are more efficient, both in
28	28	terms of storage and processing time.
29	29
		@@ -43,11 +43,11 @@
43	43
44	44	In exchange for this immeasurable cost per hit, we get human-readable
45	45	capability sets.
46	46
47	47
48		-## <a name="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync?
	48	+## <a id="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync?
49	49
50	50	Fossil is more trusting about the content it receives from a remote
51	51	clone during sync than you might expect. Common manifestations of this
52	52	design choice are:
53	53
54	54

	--- www/caps/impl.md
	+++ www/caps/impl.md
	@@ -1,8 +1,8 @@
1	# Implementation Details of User Capabilities
2
3	## <a name="choices"></a>Capability Letter Choices
4
5	We [assigned][ref] user capability characters using only lowercase ASCII
6	letters at first, so those are the most important within Fossil: they
7	control the functions most core to Fossil’s operation. Once we used up
8	most of the lowercase letters, we started using uppercase, and then
	@@ -19,11 +19,11 @@
19	lots of letters to choose from. There is still hope for good future
20	mnemonic assignments among the uppercase letters, which are mostly still
21	unused.
22
23
24	## <a name="bitfield"></a>Why Not Bitfields?
25
26	Some may question the use of ASCII character strings for [capability
27	sets][ucap] instead of bitfields, which are more efficient, both in
28	terms of storage and processing time.
29
	@@ -43,11 +43,11 @@
43
44	In exchange for this immeasurable cost per hit, we get human-readable
45	capability sets.
46
47
48	## <a name="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync?
49
50	Fossil is more trusting about the content it receives from a remote
51	clone during sync than you might expect. Common manifestations of this
52	design choice are:
53
54

	--- www/caps/impl.md
	+++ www/caps/impl.md
	@@ -1,8 +1,8 @@
1	# Implementation Details of User Capabilities
2
3	## <a id="choices"></a>Capability Letter Choices
4
5	We [assigned][ref] user capability characters using only lowercase ASCII
6	letters at first, so those are the most important within Fossil: they
7	control the functions most core to Fossil’s operation. Once we used up
8	most of the lowercase letters, we started using uppercase, and then
	@@ -19,11 +19,11 @@
19	lots of letters to choose from. There is still hope for good future
20	mnemonic assignments among the uppercase letters, which are mostly still
21	unused.
22
23
24	## <a id="bitfield"></a>Why Not Bitfields?
25
26	Some may question the use of ASCII character strings for [capability
27	sets][ucap] instead of bitfields, which are more efficient, both in
28	terms of storage and processing time.
29
	@@ -43,11 +43,11 @@
43
44	In exchange for this immeasurable cost per hit, we get human-readable
45	capability sets.
46
47
48	## <a id="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync?
49
50	Fossil is more trusting about the content it receives from a remote
51	clone during sync than you might expect. Common manifestations of this
52	design choice are:
53
54

M www/caps/index.md

+10 -10

		--- www/caps/index.md
		+++ www/caps/index.md
		@@ -20,11 +20,11 @@
20	20	[avs]: ./admin-v-setup.md
21	21	[lg]: ./login-groups.md
22	22	[rbac]: https://en.wikipedia.org/wiki/Role-based_access_control
23	23
24	24
25		-## <a name="ucat"></a>User Categories
	25	+## <a id="ucat"></a>User Categories
26	26
27	27	Before we explain individual user capabilities and their proper
28	28	administration, we want to talk about an oft-overlooked and
29	29	misunderstood feature of Fossil: user categories.
30	30
		@@ -82,11 +82,11 @@
82	82	There is currently no way to define custom user categories.
83	83
84	84	[svr]: ../server/
85	85
86	86
87		-## <a name="ucap"></a>Individual User Capabilities
	87	+## <a id="ucap"></a>Individual User Capabilities
88	88
89	89	When one or more users need to be different from the basic capabilities
90	90	defined in user categories, you can assign caps to individual users. You
91	91	may want to have the [cap reference][ref] open when doing such work.
92	92
		@@ -118,11 +118,11 @@
118	118
119	119	[apsu]: ./admin-v-setup.md#apsu
120	120	[avsp]: ./admin-v-setup.md#philosophy
121	121
122	122
123		-## <a name="new"></a>New Repository Defaults
	123	+## <a id="new"></a>New Repository Defaults
124	124
125	125	Fossil creates one user account in new repos, which is named after your
126	126	OS user name [by default](#defuser).
127	127
128	128	Fossil gives the initial repository user the [all-powerful Setup
		@@ -157,11 +157,11 @@
157	157	sensitive user material and check in changes.
158	158
159	159	[bot]: ../antibot.wiki
160	160
161	161
162		-## <a name="pvt"></a>Consequences of Taking a Repository Private
	162	+## <a id="pvt"></a>Consequences of Taking a Repository Private
163	163
164	164	When you click Admin → Security-Audit → “Take it private,” one of the
165	165	things it does is set the user capabilities for the “nobody” and
166	166	“anonymous” user categories to blank, so that users who haven’t logged
167	167	in can’t even see your project’s home page, and the option to log in as
		@@ -178,11 +178,11 @@
178	178	If you will have non-Setup users in your private repo, you should parcel
179	179	out some subset of the capability set the “nobody” and “anonymous”
180	180	categories had to other categories or to individual users first.
181	181
182	182
183		-## <a name="read-v-clone"></a>Reading vs. Cloning
	183	+## <a id="read-v-clone"></a>Reading vs. Cloning
184	184
185	185	Fossil has two capabilities that are often confused:
186	186	[Read](./ref.html#o) and [Clone](./ref.html#g).
187	187
188	188	The Read capability has nothing to do with reading data from a local
		@@ -206,11 +206,11 @@
206	206	denied the bulk Clone capability.
207	207
208	208	[edoc]: ../embeddeddoc.wiki
209	209
210	210
211		-## <a name="defuser"></a>Default User Name
	211	+## <a id="defuser"></a>Default User Name
212	212
213	213	By default, Fossil assumes your OS user account name is the same as the
214	214	one you use in any Fossil repository. It is the [default for a new
215	215	repository](#new), though you can override this with [the `--admin-user`
216	216	option][auo]. Fossil has other ways of overriding this in other contexts
		@@ -234,11 +234,11 @@
234	234	[fos]: ./impl.md#filter
235	235	[shun]: ../shunning.wiki
236	236
237	237
238	238
239		-## <a name="utclone"></a>Cloning the User Table
	239	+## <a id="utclone"></a>Cloning the User Table
240	240
241	241	When cloning over HTTP, the initial user table in the local clone is set
242	242	to its “[new state:](#new)” only one user with Setup capability, named
243	243	after either your OS user account, per the default above, or after the
244	244	user given in the clone URL.
		@@ -254,11 +254,11 @@
254	254	get a complete clone, including the parent repo’s complete user table.
255	255
256	256	All of the above applies to [login groups][lg] as well.
257	257
258	258
259		-## <a name="webonly"></a>Caps Affect Web Interfaces Only
	259	+## <a id="webonly"></a>Caps Affect Web Interfaces Only
260	260
261	261	Fossil’s user capability system only affects accesses over `http[s]://`
262	262	URLs. This includes clone, sync/push/pull, the [UI pages][wp], and [the
263	263	JSON API][japi]. For everything else, the user caps aren’t consulted at
264	264	all.
		@@ -319,11 +319,11 @@
319	319	when done over an `http[s]://` URL.
320	320
321	321	[sxycap]: /file?ci=ec5efceb8aac6cb4&name=src/main.c&ln=2748-2752
322	322
323	323
324		-## <a name="pubpg"></a>Public Pages
	324	+## <a id="pubpg"></a>Public Pages
325	325
326	326	In Admin → Access, there is an option for giving a list of [globs][glob]
327	327	to name URLs which get treated as if the visitor had [the default cap
328	328	set](#defcap). For example, you could take the [Read][o] capability
329	329	away from the “nobody” user category, who has it by default, to prevent
		@@ -331,11 +331,11 @@
331	331	artifact at a time, yet give those users the ability to read the project
332	332	documentation by setting the glob to match your [embedded
333	333	documentation][edoc]’s URL root.
334	334
335	335
336		-## <a name="defcap"></a>Default User Capability Set
	336	+## <a id="defcap"></a>Default User Capability Set
337	337
338	338	In Admin → Access, you can define a default user capability set, which
339	339	is used as:
340	340
341	341	1. the default caps for users newly created by an Admin or Setup user
342	342

	--- www/caps/index.md
	+++ www/caps/index.md
	@@ -20,11 +20,11 @@
20	[avs]: ./admin-v-setup.md
21	[lg]: ./login-groups.md
22	[rbac]: https://en.wikipedia.org/wiki/Role-based_access_control
23
24
25	## <a name="ucat"></a>User Categories
26
27	Before we explain individual user capabilities and their proper
28	administration, we want to talk about an oft-overlooked and
29	misunderstood feature of Fossil: user categories.
30
	@@ -82,11 +82,11 @@
82	There is currently no way to define custom user categories.
83
84	[svr]: ../server/
85
86
87	## <a name="ucap"></a>Individual User Capabilities
88
89	When one or more users need to be different from the basic capabilities
90	defined in user categories, you can assign caps to individual users. You
91	may want to have the [cap reference][ref] open when doing such work.
92
	@@ -118,11 +118,11 @@
118
119	[apsu]: ./admin-v-setup.md#apsu
120	[avsp]: ./admin-v-setup.md#philosophy
121
122
123	## <a name="new"></a>New Repository Defaults
124
125	Fossil creates one user account in new repos, which is named after your
126	OS user name [by default](#defuser).
127
128	Fossil gives the initial repository user the [all-powerful Setup
	@@ -157,11 +157,11 @@
157	sensitive user material and check in changes.
158
159	[bot]: ../antibot.wiki
160
161
162	## <a name="pvt"></a>Consequences of Taking a Repository Private
163
164	When you click Admin → Security-Audit → “Take it private,” one of the
165	things it does is set the user capabilities for the “nobody” and
166	“anonymous” user categories to blank, so that users who haven’t logged
167	in can’t even see your project’s home page, and the option to log in as
	@@ -178,11 +178,11 @@
178	If you will have non-Setup users in your private repo, you should parcel
179	out some subset of the capability set the “nobody” and “anonymous”
180	categories had to other categories or to individual users first.
181
182
183	## <a name="read-v-clone"></a>Reading vs. Cloning
184
185	Fossil has two capabilities that are often confused:
186	[Read](./ref.html#o) and [Clone](./ref.html#g).
187
188	The Read capability has nothing to do with reading data from a local
	@@ -206,11 +206,11 @@
206	denied the bulk Clone capability.
207
208	[edoc]: ../embeddeddoc.wiki
209
210
211	## <a name="defuser"></a>Default User Name
212
213	By default, Fossil assumes your OS user account name is the same as the
214	one you use in any Fossil repository. It is the [default for a new
215	repository](#new), though you can override this with [the `--admin-user`
216	option][auo]. Fossil has other ways of overriding this in other contexts
	@@ -234,11 +234,11 @@
234	[fos]: ./impl.md#filter
235	[shun]: ../shunning.wiki
236
237
238
239	## <a name="utclone"></a>Cloning the User Table
240
241	When cloning over HTTP, the initial user table in the local clone is set
242	to its “[new state:](#new)” only one user with Setup capability, named
243	after either your OS user account, per the default above, or after the
244	user given in the clone URL.
	@@ -254,11 +254,11 @@
254	get a complete clone, including the parent repo’s complete user table.
255
256	All of the above applies to [login groups][lg] as well.
257
258
259	## <a name="webonly"></a>Caps Affect Web Interfaces Only
260
261	Fossil’s user capability system only affects accesses over `http[s]://`
262	URLs. This includes clone, sync/push/pull, the [UI pages][wp], and [the
263	JSON API][japi]. For everything else, the user caps aren’t consulted at
264	all.
	@@ -319,11 +319,11 @@
319	when done over an `http[s]://` URL.
320
321	[sxycap]: /file?ci=ec5efceb8aac6cb4&name=src/main.c&ln=2748-2752
322
323
324	## <a name="pubpg"></a>Public Pages
325
326	In Admin → Access, there is an option for giving a list of [globs][glob]
327	to name URLs which get treated as if the visitor had [the default cap
328	set](#defcap). For example, you could take the [Read][o] capability
329	away from the “nobody” user category, who has it by default, to prevent
	@@ -331,11 +331,11 @@
331	artifact at a time, yet give those users the ability to read the project
332	documentation by setting the glob to match your [embedded
333	documentation][edoc]’s URL root.
334
335
336	## <a name="defcap"></a>Default User Capability Set
337
338	In Admin → Access, you can define a default user capability set, which
339	is used as:
340
341	1. the default caps for users newly created by an Admin or Setup user
342

	--- www/caps/index.md
	+++ www/caps/index.md
	@@ -20,11 +20,11 @@
20	[avs]: ./admin-v-setup.md
21	[lg]: ./login-groups.md
22	[rbac]: https://en.wikipedia.org/wiki/Role-based_access_control
23
24
25	## <a id="ucat"></a>User Categories
26
27	Before we explain individual user capabilities and their proper
28	administration, we want to talk about an oft-overlooked and
29	misunderstood feature of Fossil: user categories.
30
	@@ -82,11 +82,11 @@
82	There is currently no way to define custom user categories.
83
84	[svr]: ../server/
85
86
87	## <a id="ucap"></a>Individual User Capabilities
88
89	When one or more users need to be different from the basic capabilities
90	defined in user categories, you can assign caps to individual users. You
91	may want to have the [cap reference][ref] open when doing such work.
92
	@@ -118,11 +118,11 @@
118
119	[apsu]: ./admin-v-setup.md#apsu
120	[avsp]: ./admin-v-setup.md#philosophy
121
122
123	## <a id="new"></a>New Repository Defaults
124
125	Fossil creates one user account in new repos, which is named after your
126	OS user name [by default](#defuser).
127
128	Fossil gives the initial repository user the [all-powerful Setup
	@@ -157,11 +157,11 @@
157	sensitive user material and check in changes.
158
159	[bot]: ../antibot.wiki
160
161
162	## <a id="pvt"></a>Consequences of Taking a Repository Private
163
164	When you click Admin → Security-Audit → “Take it private,” one of the
165	things it does is set the user capabilities for the “nobody” and
166	“anonymous” user categories to blank, so that users who haven’t logged
167	in can’t even see your project’s home page, and the option to log in as
	@@ -178,11 +178,11 @@
178	If you will have non-Setup users in your private repo, you should parcel
179	out some subset of the capability set the “nobody” and “anonymous”
180	categories had to other categories or to individual users first.
181
182
183	## <a id="read-v-clone"></a>Reading vs. Cloning
184
185	Fossil has two capabilities that are often confused:
186	[Read](./ref.html#o) and [Clone](./ref.html#g).
187
188	The Read capability has nothing to do with reading data from a local
	@@ -206,11 +206,11 @@
206	denied the bulk Clone capability.
207
208	[edoc]: ../embeddeddoc.wiki
209
210
211	## <a id="defuser"></a>Default User Name
212
213	By default, Fossil assumes your OS user account name is the same as the
214	one you use in any Fossil repository. It is the [default for a new
215	repository](#new), though you can override this with [the `--admin-user`
216	option][auo]. Fossil has other ways of overriding this in other contexts
	@@ -234,11 +234,11 @@
234	[fos]: ./impl.md#filter
235	[shun]: ../shunning.wiki
236
237
238
239	## <a id="utclone"></a>Cloning the User Table
240
241	When cloning over HTTP, the initial user table in the local clone is set
242	to its “[new state:](#new)” only one user with Setup capability, named
243	after either your OS user account, per the default above, or after the
244	user given in the clone URL.
	@@ -254,11 +254,11 @@
254	get a complete clone, including the parent repo’s complete user table.
255
256	All of the above applies to [login groups][lg] as well.
257
258
259	## <a id="webonly"></a>Caps Affect Web Interfaces Only
260
261	Fossil’s user capability system only affects accesses over `http[s]://`
262	URLs. This includes clone, sync/push/pull, the [UI pages][wp], and [the
263	JSON API][japi]. For everything else, the user caps aren’t consulted at
264	all.
	@@ -319,11 +319,11 @@
319	when done over an `http[s]://` URL.
320
321	[sxycap]: /file?ci=ec5efceb8aac6cb4&name=src/main.c&ln=2748-2752
322
323
324	## <a id="pubpg"></a>Public Pages
325
326	In Admin → Access, there is an option for giving a list of [globs][glob]
327	to name URLs which get treated as if the visitor had [the default cap
328	set](#defcap). For example, you could take the [Read][o] capability
329	away from the “nobody” user category, who has it by default, to prevent
	@@ -331,11 +331,11 @@
331	artifact at a time, yet give those users the ability to read the project
332	documentation by setting the glob to match your [embedded
333	documentation][edoc]’s URL root.
334
335
336	## <a id="defcap"></a>Default User Capability Set
337
338	In Admin → Access, you can define a default user capability set, which
339	is used as:
340
341	1. the default caps for users newly created by an Admin or Setup user
342

M www/changes.wiki

+27 -54

		--- www/changes.wiki
		+++ www/changes.wiki
		@@ -1,9 +1,8 @@
1	1	<title>Change Log</title>
2	2
3		-<a name='v2_17'></a>
4		-<h2>Changes for version 2.17 (pending)</h2>
	3	+<h2 id='v2_17'>Changes for version 2.17 (pending)</h2>
5	4	* Added new options to the various
6	5	[/help?cmd=diff\|diff commands]: --by, -b, --webpage, --json, --tcl.
7	6	* Performance and display improvements to the internal diff engine, including
8	7	partial-line matching for unified diffs and improved partial line matching for
9	8	side-by-side diffs.
		@@ -32,12 +31,11 @@
32	31	of <pre> and <script> is passed through verbatim.
33	32	* The [/help?cmd=wiki\|wiki list command] no longer lists "deleted"
34	33	pages by default. Use the new <tt>--all</tt> option to include deleted
35	34	pages in the output.
36	35
37		-<a name='v2_16'></a>
38		-<h2>Changes for Version 2.16 (2021-07-02)</h2>
	36	+<h2 id='v2_16'>Changes for Version 2.16 (2021-07-02)</h2>
39	37	* <b>Security:</b> Fix the client-side TLS so that it verifies that the
40	38	server hostname matches its certificate.
41	39	* The default "ssh" command on Windows is changed to "ssh" instead of the
42	40	legacy "plink", as ssh is now generally available on Windows systems.
43	41	Installations that still need to use the legacy "plink" can make that
		@@ -79,12 +77,11 @@
79	77	[/timeline?c=c717f1ef9a1a4c91\|can DROP] a VIEW or an INDEX provided
80	78	that its name starts with '<code>ticket</code>' or '<code>fx_</code>'.
81	79	* Update the built-in SQLite to version 3.36.0.
82	80	* Numerous other minor enhancements.
83	81
84		-<a name='v2_15'></a>
85		-<h2>Changes for Version 2.15 (2021-03-26) and Patch 2.15.1 on (2021-04-07)
	82	+<h2 id='v2_15'>Changes for Version 2.15 (2021-03-26) and Patch 2.15.1 on (2021-04-07)
86	83	and 2.15.2 on (2021-06-15)</h2>
87	84	* <b>Patch 2.15.2:</b> Fix the client-side TLS so that it verifies that the
88	85	server hostname matches its certificate. <b>Upgrading to
89	86	the patch is recommended.</b>
90	87	* <b>Patch 2.15.1:</b> Fix a data exfiltration bug in the server. <b>Upgrading to
		@@ -164,12 +161,11 @@
164	161	gained client-side UI to help with comparison between two arbitrary
165	162	versions of a wiki (by the means of anchoring a "baseline" version)
166	163	and the ability to squeeze several sequential edits made by the same
167	164	user into a single "recycled" row (the latest edit in that sequence).
168	165
169		-<a name='v2_14'></a>
170		-<h2>Changes for Version 2.14 (2021-01-20) and Patch 2.14.1 on (2021-04-07)
	166	+<h2 id='v2_14'>Changes for Version 2.14 (2021-01-20) and Patch 2.14.1 on (2021-04-07)
171	167	and 2.14.2 on (2021-06-15)</h2>
172	168	* <b>Patch 2.14.2:</b> Fix the client-side TLS so that it verifies that the
173	169	server hostname matches its certificate. <b>Upgrading to
174	170	the patch is recommended.</b><
175	171	* <b>Patch 2.14.1:</b> Fix a data exfiltration bug in the server.
		@@ -231,12 +227,11 @@
231	227	performance optimizations, especially performance associated with
232	228	startup, and minor improvements to the CLI.
233	229	* Performance optimizations to Fossil itself.
234	230	* Countless improvements and enhancements to the documentation
235	231
236		-<a name='v2_13'></a>
237		-<h2>Changes for Version 2.13 (2020-11-01)</h2>
	232	+<h2 id='v2_13'>Changes for Version 2.13 (2020-11-01)</h2>
238	233
239	234	* Added support for [./interwiki.md\|interwiki links].
240	235	* Enable <del> and <ins> markup in wiki.
241	236	* Improvements to the Forum threading display.
242	237	* Added support for embedding [./pikchr.md\|pikchr]
		@@ -262,12 +257,11 @@
262	257	/finfo change in the previous bullet depends on enhancements to
263	258	recursive common table expressions that are only available in
264	259	SQLite 3.34.0 and later.
265	260	* Countless other minor refinements and documentation improvements.
266	261
267		-<a name='v2_12'></a>
268		-<h2>Changes for Version 2.12.1 (2020-08-20)</h2>
	262	+<h2 id='v2_12'>Changes for Version 2.12.1 (2020-08-20)</h2>
269	263
270	264	* (2.12.1): Fix client-side vulnerabilities discovered by Max Justicz.
271	265	* Security fix in the "[/help?cmd=git\|fossil git export]" command.
272	266	The same fix is also backported to version 2.10.1 and 2.11.1.
273	267	New "safety-net" features were added to prevent similar problems
		@@ -345,12 +339,11 @@
345	339	* The [/help?cmd=allow-symlinks\|allow-symlinks setting] no longer
346	340	syncs. It must be activated individually on any clones which require
347	341	symlinks.
348	342	* Countless documentation enhancements.
349	343
350		-<a name='v2_11'></a>
351		-<h2>Changes for Version 2.11 (2020-05-25)</h2>
	344	+<h2 id='v2_11'>Changes for Version 2.11 (2020-05-25)</h2>
352	345
353	346	* (2.11.2): Backport security fixes from 2.12.1
354	347	* (2.11.1): Backport security fix for the "fossil git export" command.
355	348	* Support [/md_rules\|Markdown] in the default ticket configuration.
356	349	* Timestamp strings in [./checkin_names.wiki\|object names]
		@@ -436,12 +429,11 @@
436	429	* Update internal Unicode character tables, used in regular expression
437	430	handling, from version 12.1 to 13.
438	431	* Many documentation enhancements.
439	432	* Many minor enhancements to existing features.
440	433
441		-<a name='v2_10'></a>
442		-<h2>Changes for Version 2.10 (2019-10-04)</h2>
	434	+<h2 id='v2_10'>Changes for Version 2.10 (2019-10-04)</h2>
443	435
444	436	* (2.10.2): backport security fixes from 2.12.1
445	437	* (2.10.1): backport security fix for the "fossil git export" command.
446	438	* Added support for [./serverext.wiki\|CGI-based Server Extensions].
447	439	* Added the [/help?cmd=repolist-skin\|repolist-skin] setting used to
		@@ -473,12 +465,11 @@
473	465	An additional check for conflicts is added after interactive
474	466	check-in comment entry, to compensate for the reduced lock interval.
475	467	* Performance optimizations.
476	468	* Many documentation improvements.
477	469
478		-<a name='v2_9'></a>
479		-<h2>Changes for Version 2.9 (2019-07-13)</h2>
	470	+<h2 id='v2_9'>Changes for Version 2.9 (2019-07-13)</h2>
480	471
481	472	* Added the [/help?cmd=git\|fossil git export] command and instructions
482	473	for [./mirrortogithub.md\|creating a GitHub mirror of a Fossil project].
483	474	* Improved handling of relative hyperlinks on the
484	475	[/help?cmd=/artifact\|/artifact] pages for wiki. For example,
		@@ -544,12 +535,11 @@
544	535	that can cause repository databases to be overwritten with debugging
545	536	output, thus corrupting the repository. This is only a factor when
546	537	CGI debugging is enabled, and even then is a rare occurrence, but it is
547	538	obviously an important fix.
548	539
549		-<a name='v2_8'></a>
550		-<h2>Changes for Version 2.8 (2019-02-20)</h2>
	540	+<h2 id='v2_8'>Changes for Version 2.8 (2019-02-20)</h2>
551	541
552	542	* Show cherry-pick merges as dotted lines on the timeline graph.
553	543	→ The "fossil rebuild" command must be run to create and
554	544	populate the new "cherrypick" table in the repository in order
555	545	for this feature to operate.
		@@ -611,12 +601,11 @@
611	601	backoffice feature.
612	602	* Update the built-in SQLite to version 3.27.1.
613	603	* Various other small enhancements to webpages and documentation.
614	604
615	605
616		-<a name='v2_7'></a>
617		-<h2>Changes for Version 2.7 (2018-09-22)</h2>
	606	+<h2 id='v2_7'>Changes for Version 2.7 (2018-09-22)</h2>
618	607
619	608	* Add the [./alerts.md\|email alerts] feature for commits, ticket
620	609	changes, wiki changes, forum posts, and announcements. This is
621	610	still a work in progress. It is functional, but it is not as easy to
622	611	setup and use as it ought to be.
		@@ -654,12 +643,11 @@
654	643	<tt>./configure --with-legacy-mv-rm</tt> to make it available. The
655	644	setting remains disabled by default, however, so you must still say
656	645	<tt>fossil set mv-rm-files 1</tt> to enable it on each repository
657	646	where you want hard <tt>mv/rm</tt> behavior.
658	647
659		-<a name='v2_6'></a>
660		-<h2>Changes for Version 2.6 (2018-05-04)</h2>
	648	+<h2 id='v2_6'>Changes for Version 2.6 (2018-05-04)</h2>
661	649
662	650	* Fix a bug that was causing crashes while trying to clone the TCL
663	651	repository. This fix is the main reason for the current release.
664	652	* Added the new "Classic" timeline viewing mode. "Classic" is the
665	653	same as "Verbose" in the previous release. The "Verbose" mode is
		@@ -683,12 +671,11 @@
683	671	tarballs that have been accessed more than once.
684	672	* Additional defenses against web-based attacks. There have not been
685	673	any known vulnerabilities. We are just being paranoid.
686	674	* Update the built-in SQLite to an alpha version of 3.24.0.
687	675
688		-<a name='v2_5'></a>
689		-<h2>Changes for Version 2.5 (2018-02-07)</h2>
	676	+<h2 id='v2_5'>Changes for Version 2.5 (2018-02-07)</h2>
690	677
691	678	* Numerous enhancements to the look and feel of the web interface.
692	679	Especially: Added separate "Modern", "Compact", "Verbose", and
693	680	"Columnar" view options on timelines.
694	681	* Common display settings (such as the "view" option and the number
		@@ -719,12 +706,11 @@
719	706	road toward supporting a strict Content Security Policy. More work
720	707	is to be done.
721	708	* Initial infrastructure is in place to make use of the pledge()
722	709	system call in OpenBSD. More work is to be done.
723	710
724		-<a name='v2_4'></a>
725		-<h2>Changes for Version 2.4 (2017-11-03)</h2>
	711	+<h2 id='v2_4'>Changes for Version 2.4 (2017-11-03)</h2>
726	712
727	713	* New feature: URL Aliases. URL Aliases allow an administrator
728	714	to define their own URLs on the web interface that are rewritten to
729	715	built-in URLs with specific parameters. Create and configure URL Aliases
730	716	using the /Setup/URL_Aliases menu option in the web interface.
		@@ -759,12 +745,11 @@
759	745	directory.
760	746	* The admin-log and access-log settings are now on by default for
761	747	new repositories.
762	748	* Update the built-in SQLite to version 3.21.0.
763	749
764		-<a name='v2_3'></a>
765		-<h2>Changes for Version 2.3 (2017-07-21)</h2>
	750	+<h2 id='v2_3'>Changes for Version 2.3 (2017-07-21)</h2>
766	751
767	752	* Update the built-in SQLite to version 3.20.0 (beta).
768	753	* Update internal Unicode character tables, used in regular expression
769	754	handling, from version 9.0 to 10.0.
770	755	* Show the last-sync-URL on the [/help?cmd=/urllist\|/urllist] page.
		@@ -780,12 +765,11 @@
780	765	* Fix "database locked" warnings caused by "PRAGMA optimize".
781	766	* Fix a potential XSS vulnerability on the
782	767	[/help?cmd=/help\|/help] webpage.
783	768	* Documentation updates
784	769
785		-<a name='v2_2'></a>
786		-<h2>Changes for Version 2.2 (2017-04-11)</h2>
	770	+<h2 id='v2_2'>Changes for Version 2.2 (2017-04-11)</h2>
787	771
788	772	* GIT comment tags are now handled by Fossil during import/export.
789	773	* Show the content of README files on directory listings.
790	774	([/file/skins\|example])
791	775	* Support for Basic Authentication if enabled (default off).
		@@ -797,23 +781,21 @@
797	781	is still accepted for backwards compatibility.
798	782	* Update the built-in SQLite to version 3.18.0.
799	783	* Run "[https://www.sqlite.org/pragma.html#pragma_optimize\|PRAGMA optimize]"
800	784	on the database connection as it is closing.
801	785
802		-<a name='v2_1'></a>
803		-<h2>Changes for Version 2.1 (2017-03-10)</h2>
	786	+<h2 id='v2_1'>Changes for Version 2.1 (2017-03-10)</h2>
804	787
805	788	* Add support for [./hashpolicy.wiki\|hash policies] that control which
806	789	of the Hardened-SHA1 or SHA3-256 algorithms is used to name new
807	790	artifacts.
808	791	* Add the "gshow" and "gcat" subcommands to [/help?cmd=stash\|fossil stash].
809	792	* Add the [/help?cmd=/juvlist\|/juvlist] web page and use it to construct
810	793	the [/uv/download.html\|Download Page] of the Fossil self-hosting website
811	794	using Ajax.
812	795
813		-<a name='v2_0'></a>
814		-<h2>Changes for Version 2.0 (2017-03-03)</h2>
	796	+<h2 id='v2_0'>Changes for Version 2.0 (2017-03-03)</h2>
815	797
816	798	* Use the
817	799	[https://github.com/cr-marcstevens/sha1collisiondetection\|hardened SHA1]
818	800	implementation by Marc Stevens and Dan Shumow.
819	801	* Add the ability to read and understand
		@@ -820,12 +802,11 @@
820	802	[./fileformat.wiki#names\|artifact names] that are based on SHA3-256
821	803	rather than SHA1, but do not actually generate any such names.
822	804	* Added the [/help?cmd=sha3sum\|sha3sum] command.
823	805	* Update the built-in SQLite to version 3.17.0.
824	806
825		-<a name='v1_37'></a>
826		-<h2>Changes for Version 1.37 (2017-01-16)</h2>
	807	+<h2 id='v1_37'>Changes for Version 1.37 (2017-01-16)</h2>
827	808
828	809	* Add checkbox widgets to various web pages. See [/technote/8d18bf27e9\|
829	810	this technote] for more information. To get the checkboxes to look as
830	811	intended, you must update the CSS in your repository and all clones.
831	812	* Add the [/help/all\|fossil all ui] command
		@@ -858,12 +839,11 @@
858	839	[./encryptedrepos.wiki\|encrypted repositories].
859	840	* Update the built-in SQLite to version 3.16.2.
860	841	* Update the built-in Zlib to version 1.2.11.
861	842
862	843
863		-<a name='v1_36'></a>
864		-<h2>Changes for Version 1.36 (2016-10-24)</h2>
	844	+<h2 id='v1_36'>Changes for Version 1.36 (2016-10-24)</h2>
865	845
866	846	* Add support for [./unvers.wiki\|unversioned content],
867	847	the [/help?cmd=unversioned\|fossil unversioned] command and the
868	848	[/help?cmd=/uv\|/uv] and [/uvlist] web pages.
869	849	* The [/uv/download.html\|download page] is moved into
		@@ -889,12 +869,11 @@
889	869	able to pull from their parent but not push.
890	870	* Added the -nocomplain option to the TH1 "query" command.
891	871	* Added support for the chng=GLOBLIST query parameter on the
892	872	[/help?cmd=/timeline\|/timeline] webpage.
893	873
894		-<a name='v1_35'></a>
895		-<h2>Changes for Version 1.35 (2016-06-14)</h2>
	874	+<h2 id='v1_35'>Changes for Version 1.35 (2016-06-14)</h2>
896	875
897	876	* Enable symlinks by default on all non-Windows platforms.
898	877	* Enhance the [/md_rules\|Markdown formatting] so that hyperlinks that begin
899	878	with "/" are relative to the root of the Fossil repository.
900	879	* Rework the [/help?cmd=/setup_ulist\|/setup_list page] (the User List page)
		@@ -933,12 +912,11 @@
933	912	names in place of getpass() to read passwords and passphrases
934	913	* Option --baseurl now works on Windows.
935	914	* Numerous documentation improvements.
936	915	* Update the built-in SQLite to version 3.13.0.
937	916
938		-<a name='v1_34'></a>
939		-<h2>Changes for Version 1.34 (2015-11-02)</h2>
	917	+<h2 id='v1_34'>Changes for Version 1.34 (2015-11-02)</h2>
940	918
941	919	* Make the [/help?cmd=clean\|fossil clean] command undoable for files less
942	920	than 10MiB.
943	921	* Update internal Unicode character tables, used in regular expression
944	922	handling, from version 7.0 to 8.0.
		@@ -969,12 +947,11 @@
969	947	* Change the mimetype for ".n" and ".man" files to text/plain.
970	948	* Display improvements in the [/help?cmd=bisect\|fossil bisect chart] command.
971	949	* Updated the built-in SQLite to version 3.9.1 and activated JSON1 and FTS5
972	950	support (both currently unused within Fossil).
973	951
974		-<a name='v1_33'></a>
975		-<h2>Changes for Version 1.33 (2015-05-23)</h2>
	952	+<h2 id='v1_33'>Changes for Version 1.33 (2015-05-23)</h2>
976	953	* Improved fork detection on [/help?cmd=update\|fossil update],
977	954	[/help?cmd=status\|fossil status] and related commands.
978	955	* Change the default skin to what used to be called "San Francisco Modern".
979	956	* Add the [/repo-tabsize] web page
980	957	* Add [/help?cmd=import\|fossil import --svn], for importing a subversion
		@@ -1019,12 +996,11 @@
1019	996	field for direct entry of the user name to each applicable report.
1020	997	* Create parent directories of [/help?cmd=settings\|empty-dirs] if they don't
1021	998	already exist.
1022	999	* Inhibit timeline links to wiki pages that have been deleted.
1023	1000
1024		-<a name='v1_33'></a>
1025		-<h2>Changes for Version 1.32 (2015-03-14)</h2>
	1001	+<h2 id='v1_33'>Changes for Version 1.32 (2015-03-14)</h2>
1026	1002	* When creating a new repository using [/help?cmd=init\|fossil init], ensure
1027	1003	that the new repository is fully compatible with historical versions of
1028	1004	Fossil by having a valid manifest as RID 1.
1029	1005	* Anti-aliased rendering of arrowheads on timeline graphs.
1030	1006	* Added vi/less-style key bindings to the --tk diff GUI.
		@@ -1036,12 +1012,11 @@
1036	1012	* Enhance the "ln=" query parameter on artifact displays to accept multiple
1037	1013	ranges, separate by spaces (or "+" when URL-encoded).
1038	1014	* Added [/help?cmd=forget\|fossil forget] as an alias for
1039	1015	[/help?cmd=rm\|fossil rm].
1040	1016
1041		-<a name='v1_31'></a>
1042		-<h2>Changes For Version 1.31 (2015-02-23)</h2>
	1017	+<h2 id='v1_31'>Changes For Version 1.31 (2015-02-23)</h2>
1043	1018	* Change the auxiliary schema by adding columns MLINK.ISAUX and MLINK.PMID
1044	1019	columns to the schema, to support better drawing of file change graphs.
1045	1020	A [/help?cmd=rebuild\|fossil rebuild] is recommended but is not required.
1046	1021	so that the new graph drawing logic can work effectively.
1047	1022	* Added [/search\|search] over Check-in comments, Documents, Tickets and
		@@ -1088,12 +1063,11 @@
1088	1063	* Allow the user of Common Table Expressions in the SQL that defaults
1089	1064	ticket reports.
1090	1065	* Break out the components (css, footer, and header) for the
1091	1066	various built-in skins into separate files in the source tree.
1092	1067
1093		-<a name='v1_30'></a>
1094		-<h2>Changes For Version 1.30 (2015-01-19)</h2>
	1068	+<h2 id='v1_30'>Changes For Version 1.30 (2015-01-19)</h2>
1095	1069	* Added the [/help?cmd=bundle\|fossil bundle] command.
1096	1070	* Added the [/help?cmd=purge\|fossil purge] command.
1097	1071	* Added the [/help?cmd=publish\|fossil publish] command.
1098	1072	* Added the [/help?cmd=unpublished\|fossil unpublished] command.
1099	1073	* Enhance the [/tree] webpage to show the age of each file with the option
		@@ -1159,12 +1133,11 @@
1159	1133	the correctness of printf-style formatting strings.
1160	1134	* Fix CVE-2014-3566, also known as the POODLE SSL 3.0 vulnerability.
1161	1135	* Numerous documentation fixes and improvements.
1162	1136	* Other obscure and minor bug fixes - see the timeline for details.
1163	1137
1164		-<a name='v1_29'></a>
1165		-<h2>Changes For Version 1.29 (2014-06-12)</h2>
	1138	+<h2 id='v1_29'>Changes For Version 1.29 (2014-06-12)</h2>
1166	1139	* Add the ability to display content, diffs and annotations for UTF16
1167	1140	text files in the web interface.
1168	1141	* Add the "SaveAs..." and "Invert" buttons
1169	1142	to the graphical diff display that results
1170	1143	from using the --tk option with the [/help/diff \| fossil diff] command.
1171	1144

	--- www/changes.wiki
	+++ www/changes.wiki
	@@ -1,9 +1,8 @@
1	<title>Change Log</title>
2
3	<a name='v2_17'></a>
4	<h2>Changes for version 2.17 (pending)</h2>
5	* Added new options to the various
6	[/help?cmd=diff\|diff commands]: --by, -b, --webpage, --json, --tcl.
7	* Performance and display improvements to the internal diff engine, including
8	partial-line matching for unified diffs and improved partial line matching for
9	side-by-side diffs.
	@@ -32,12 +31,11 @@
32	of <pre> and <script> is passed through verbatim.
33	* The [/help?cmd=wiki\|wiki list command] no longer lists "deleted"
34	pages by default. Use the new <tt>--all</tt> option to include deleted
35	pages in the output.
36
37	<a name='v2_16'></a>
38	<h2>Changes for Version 2.16 (2021-07-02)</h2>
39	* <b>Security:</b> Fix the client-side TLS so that it verifies that the
40	server hostname matches its certificate.
41	* The default "ssh" command on Windows is changed to "ssh" instead of the
42	legacy "plink", as ssh is now generally available on Windows systems.
43	Installations that still need to use the legacy "plink" can make that
	@@ -79,12 +77,11 @@
79	[/timeline?c=c717f1ef9a1a4c91\|can DROP] a VIEW or an INDEX provided
80	that its name starts with '<code>ticket</code>' or '<code>fx_</code>'.
81	* Update the built-in SQLite to version 3.36.0.
82	* Numerous other minor enhancements.
83
84	<a name='v2_15'></a>
85	<h2>Changes for Version 2.15 (2021-03-26) and Patch 2.15.1 on (2021-04-07)
86	and 2.15.2 on (2021-06-15)</h2>
87	* <b>Patch 2.15.2:</b> Fix the client-side TLS so that it verifies that the
88	server hostname matches its certificate. <b>Upgrading to
89	the patch is recommended.</b>
90	* <b>Patch 2.15.1:</b> Fix a data exfiltration bug in the server. <b>Upgrading to
	@@ -164,12 +161,11 @@
164	gained client-side UI to help with comparison between two arbitrary
165	versions of a wiki (by the means of anchoring a "baseline" version)
166	and the ability to squeeze several sequential edits made by the same
167	user into a single "recycled" row (the latest edit in that sequence).
168
169	<a name='v2_14'></a>
170	<h2>Changes for Version 2.14 (2021-01-20) and Patch 2.14.1 on (2021-04-07)
171	and 2.14.2 on (2021-06-15)</h2>
172	* <b>Patch 2.14.2:</b> Fix the client-side TLS so that it verifies that the
173	server hostname matches its certificate. <b>Upgrading to
174	the patch is recommended.</b><
175	* <b>Patch 2.14.1:</b> Fix a data exfiltration bug in the server.
	@@ -231,12 +227,11 @@
231	performance optimizations, especially performance associated with
232	startup, and minor improvements to the CLI.
233	* Performance optimizations to Fossil itself.
234	* Countless improvements and enhancements to the documentation
235
236	<a name='v2_13'></a>
237	<h2>Changes for Version 2.13 (2020-11-01)</h2>
238
239	* Added support for [./interwiki.md\|interwiki links].
240	* Enable <del> and <ins> markup in wiki.
241	* Improvements to the Forum threading display.
242	* Added support for embedding [./pikchr.md\|pikchr]
	@@ -262,12 +257,11 @@
262	/finfo change in the previous bullet depends on enhancements to
263	recursive common table expressions that are only available in
264	SQLite 3.34.0 and later.
265	* Countless other minor refinements and documentation improvements.
266
267	<a name='v2_12'></a>
268	<h2>Changes for Version 2.12.1 (2020-08-20)</h2>
269
270	* (2.12.1): Fix client-side vulnerabilities discovered by Max Justicz.
271	* Security fix in the "[/help?cmd=git\|fossil git export]" command.
272	The same fix is also backported to version 2.10.1 and 2.11.1.
273	New "safety-net" features were added to prevent similar problems
	@@ -345,12 +339,11 @@
345	* The [/help?cmd=allow-symlinks\|allow-symlinks setting] no longer
346	syncs. It must be activated individually on any clones which require
347	symlinks.
348	* Countless documentation enhancements.
349
350	<a name='v2_11'></a>
351	<h2>Changes for Version 2.11 (2020-05-25)</h2>
352
353	* (2.11.2): Backport security fixes from 2.12.1
354	* (2.11.1): Backport security fix for the "fossil git export" command.
355	* Support [/md_rules\|Markdown] in the default ticket configuration.
356	* Timestamp strings in [./checkin_names.wiki\|object names]
	@@ -436,12 +429,11 @@
436	* Update internal Unicode character tables, used in regular expression
437	handling, from version 12.1 to 13.
438	* Many documentation enhancements.
439	* Many minor enhancements to existing features.
440
441	<a name='v2_10'></a>
442	<h2>Changes for Version 2.10 (2019-10-04)</h2>
443
444	* (2.10.2): backport security fixes from 2.12.1
445	* (2.10.1): backport security fix for the "fossil git export" command.
446	* Added support for [./serverext.wiki\|CGI-based Server Extensions].
447	* Added the [/help?cmd=repolist-skin\|repolist-skin] setting used to
	@@ -473,12 +465,11 @@
473	An additional check for conflicts is added after interactive
474	check-in comment entry, to compensate for the reduced lock interval.
475	* Performance optimizations.
476	* Many documentation improvements.
477
478	<a name='v2_9'></a>
479	<h2>Changes for Version 2.9 (2019-07-13)</h2>
480
481	* Added the [/help?cmd=git\|fossil git export] command and instructions
482	for [./mirrortogithub.md\|creating a GitHub mirror of a Fossil project].
483	* Improved handling of relative hyperlinks on the
484	[/help?cmd=/artifact\|/artifact] pages for wiki. For example,
	@@ -544,12 +535,11 @@
544	that can cause repository databases to be overwritten with debugging
545	output, thus corrupting the repository. This is only a factor when
546	CGI debugging is enabled, and even then is a rare occurrence, but it is
547	obviously an important fix.
548
549	<a name='v2_8'></a>
550	<h2>Changes for Version 2.8 (2019-02-20)</h2>
551
552	* Show cherry-pick merges as dotted lines on the timeline graph.
553	→ The "fossil rebuild" command must be run to create and
554	populate the new "cherrypick" table in the repository in order
555	for this feature to operate.
	@@ -611,12 +601,11 @@
611	backoffice feature.
612	* Update the built-in SQLite to version 3.27.1.
613	* Various other small enhancements to webpages and documentation.
614
615
616	<a name='v2_7'></a>
617	<h2>Changes for Version 2.7 (2018-09-22)</h2>
618
619	* Add the [./alerts.md\|email alerts] feature for commits, ticket
620	changes, wiki changes, forum posts, and announcements. This is
621	still a work in progress. It is functional, but it is not as easy to
622	setup and use as it ought to be.
	@@ -654,12 +643,11 @@
654	<tt>./configure --with-legacy-mv-rm</tt> to make it available. The
655	setting remains disabled by default, however, so you must still say
656	<tt>fossil set mv-rm-files 1</tt> to enable it on each repository
657	where you want hard <tt>mv/rm</tt> behavior.
658
659	<a name='v2_6'></a>
660	<h2>Changes for Version 2.6 (2018-05-04)</h2>
661
662	* Fix a bug that was causing crashes while trying to clone the TCL
663	repository. This fix is the main reason for the current release.
664	* Added the new "Classic" timeline viewing mode. "Classic" is the
665	same as "Verbose" in the previous release. The "Verbose" mode is
	@@ -683,12 +671,11 @@
683	tarballs that have been accessed more than once.
684	* Additional defenses against web-based attacks. There have not been
685	any known vulnerabilities. We are just being paranoid.
686	* Update the built-in SQLite to an alpha version of 3.24.0.
687
688	<a name='v2_5'></a>
689	<h2>Changes for Version 2.5 (2018-02-07)</h2>
690
691	* Numerous enhancements to the look and feel of the web interface.
692	Especially: Added separate "Modern", "Compact", "Verbose", and
693	"Columnar" view options on timelines.
694	* Common display settings (such as the "view" option and the number
	@@ -719,12 +706,11 @@
719	road toward supporting a strict Content Security Policy. More work
720	is to be done.
721	* Initial infrastructure is in place to make use of the pledge()
722	system call in OpenBSD. More work is to be done.
723
724	<a name='v2_4'></a>
725	<h2>Changes for Version 2.4 (2017-11-03)</h2>
726
727	* New feature: URL Aliases. URL Aliases allow an administrator
728	to define their own URLs on the web interface that are rewritten to
729	built-in URLs with specific parameters. Create and configure URL Aliases
730	using the /Setup/URL_Aliases menu option in the web interface.
	@@ -759,12 +745,11 @@
759	directory.
760	* The admin-log and access-log settings are now on by default for
761	new repositories.
762	* Update the built-in SQLite to version 3.21.0.
763
764	<a name='v2_3'></a>
765	<h2>Changes for Version 2.3 (2017-07-21)</h2>
766
767	* Update the built-in SQLite to version 3.20.0 (beta).
768	* Update internal Unicode character tables, used in regular expression
769	handling, from version 9.0 to 10.0.
770	* Show the last-sync-URL on the [/help?cmd=/urllist\|/urllist] page.
	@@ -780,12 +765,11 @@
780	* Fix "database locked" warnings caused by "PRAGMA optimize".
781	* Fix a potential XSS vulnerability on the
782	[/help?cmd=/help\|/help] webpage.
783	* Documentation updates
784
785	<a name='v2_2'></a>
786	<h2>Changes for Version 2.2 (2017-04-11)</h2>
787
788	* GIT comment tags are now handled by Fossil during import/export.
789	* Show the content of README files on directory listings.
790	([/file/skins\|example])
791	* Support for Basic Authentication if enabled (default off).
	@@ -797,23 +781,21 @@
797	is still accepted for backwards compatibility.
798	* Update the built-in SQLite to version 3.18.0.
799	* Run "[https://www.sqlite.org/pragma.html#pragma_optimize\|PRAGMA optimize]"
800	on the database connection as it is closing.
801
802	<a name='v2_1'></a>
803	<h2>Changes for Version 2.1 (2017-03-10)</h2>
804
805	* Add support for [./hashpolicy.wiki\|hash policies] that control which
806	of the Hardened-SHA1 or SHA3-256 algorithms is used to name new
807	artifacts.
808	* Add the "gshow" and "gcat" subcommands to [/help?cmd=stash\|fossil stash].
809	* Add the [/help?cmd=/juvlist\|/juvlist] web page and use it to construct
810	the [/uv/download.html\|Download Page] of the Fossil self-hosting website
811	using Ajax.
812
813	<a name='v2_0'></a>
814	<h2>Changes for Version 2.0 (2017-03-03)</h2>
815
816	* Use the
817	[https://github.com/cr-marcstevens/sha1collisiondetection\|hardened SHA1]
818	implementation by Marc Stevens and Dan Shumow.
819	* Add the ability to read and understand
	@@ -820,12 +802,11 @@
820	[./fileformat.wiki#names\|artifact names] that are based on SHA3-256
821	rather than SHA1, but do not actually generate any such names.
822	* Added the [/help?cmd=sha3sum\|sha3sum] command.
823	* Update the built-in SQLite to version 3.17.0.
824
825	<a name='v1_37'></a>
826	<h2>Changes for Version 1.37 (2017-01-16)</h2>
827
828	* Add checkbox widgets to various web pages. See [/technote/8d18bf27e9\|
829	this technote] for more information. To get the checkboxes to look as
830	intended, you must update the CSS in your repository and all clones.
831	* Add the [/help/all\|fossil all ui] command
	@@ -858,12 +839,11 @@
858	[./encryptedrepos.wiki\|encrypted repositories].
859	* Update the built-in SQLite to version 3.16.2.
860	* Update the built-in Zlib to version 1.2.11.
861
862
863	<a name='v1_36'></a>
864	<h2>Changes for Version 1.36 (2016-10-24)</h2>
865
866	* Add support for [./unvers.wiki\|unversioned content],
867	the [/help?cmd=unversioned\|fossil unversioned] command and the
868	[/help?cmd=/uv\|/uv] and [/uvlist] web pages.
869	* The [/uv/download.html\|download page] is moved into
	@@ -889,12 +869,11 @@
889	able to pull from their parent but not push.
890	* Added the -nocomplain option to the TH1 "query" command.
891	* Added support for the chng=GLOBLIST query parameter on the
892	[/help?cmd=/timeline\|/timeline] webpage.
893
894	<a name='v1_35'></a>
895	<h2>Changes for Version 1.35 (2016-06-14)</h2>
896
897	* Enable symlinks by default on all non-Windows platforms.
898	* Enhance the [/md_rules\|Markdown formatting] so that hyperlinks that begin
899	with "/" are relative to the root of the Fossil repository.
900	* Rework the [/help?cmd=/setup_ulist\|/setup_list page] (the User List page)
	@@ -933,12 +912,11 @@
933	names in place of getpass() to read passwords and passphrases
934	* Option --baseurl now works on Windows.
935	* Numerous documentation improvements.
936	* Update the built-in SQLite to version 3.13.0.
937
938	<a name='v1_34'></a>
939	<h2>Changes for Version 1.34 (2015-11-02)</h2>
940
941	* Make the [/help?cmd=clean\|fossil clean] command undoable for files less
942	than 10MiB.
943	* Update internal Unicode character tables, used in regular expression
944	handling, from version 7.0 to 8.0.
	@@ -969,12 +947,11 @@
969	* Change the mimetype for ".n" and ".man" files to text/plain.
970	* Display improvements in the [/help?cmd=bisect\|fossil bisect chart] command.
971	* Updated the built-in SQLite to version 3.9.1 and activated JSON1 and FTS5
972	support (both currently unused within Fossil).
973
974	<a name='v1_33'></a>
975	<h2>Changes for Version 1.33 (2015-05-23)</h2>
976	* Improved fork detection on [/help?cmd=update\|fossil update],
977	[/help?cmd=status\|fossil status] and related commands.
978	* Change the default skin to what used to be called "San Francisco Modern".
979	* Add the [/repo-tabsize] web page
980	* Add [/help?cmd=import\|fossil import --svn], for importing a subversion
	@@ -1019,12 +996,11 @@
1019	field for direct entry of the user name to each applicable report.
1020	* Create parent directories of [/help?cmd=settings\|empty-dirs] if they don't
1021	already exist.
1022	* Inhibit timeline links to wiki pages that have been deleted.
1023
1024	<a name='v1_33'></a>
1025	<h2>Changes for Version 1.32 (2015-03-14)</h2>
1026	* When creating a new repository using [/help?cmd=init\|fossil init], ensure
1027	that the new repository is fully compatible with historical versions of
1028	Fossil by having a valid manifest as RID 1.
1029	* Anti-aliased rendering of arrowheads on timeline graphs.
1030	* Added vi/less-style key bindings to the --tk diff GUI.
	@@ -1036,12 +1012,11 @@
1036	* Enhance the "ln=" query parameter on artifact displays to accept multiple
1037	ranges, separate by spaces (or "+" when URL-encoded).
1038	* Added [/help?cmd=forget\|fossil forget] as an alias for
1039	[/help?cmd=rm\|fossil rm].
1040
1041	<a name='v1_31'></a>
1042	<h2>Changes For Version 1.31 (2015-02-23)</h2>
1043	* Change the auxiliary schema by adding columns MLINK.ISAUX and MLINK.PMID
1044	columns to the schema, to support better drawing of file change graphs.
1045	A [/help?cmd=rebuild\|fossil rebuild] is recommended but is not required.
1046	so that the new graph drawing logic can work effectively.
1047	* Added [/search\|search] over Check-in comments, Documents, Tickets and
	@@ -1088,12 +1063,11 @@
1088	* Allow the user of Common Table Expressions in the SQL that defaults
1089	ticket reports.
1090	* Break out the components (css, footer, and header) for the
1091	various built-in skins into separate files in the source tree.
1092
1093	<a name='v1_30'></a>
1094	<h2>Changes For Version 1.30 (2015-01-19)</h2>
1095	* Added the [/help?cmd=bundle\|fossil bundle] command.
1096	* Added the [/help?cmd=purge\|fossil purge] command.
1097	* Added the [/help?cmd=publish\|fossil publish] command.
1098	* Added the [/help?cmd=unpublished\|fossil unpublished] command.
1099	* Enhance the [/tree] webpage to show the age of each file with the option
	@@ -1159,12 +1133,11 @@
1159	the correctness of printf-style formatting strings.
1160	* Fix CVE-2014-3566, also known as the POODLE SSL 3.0 vulnerability.
1161	* Numerous documentation fixes and improvements.
1162	* Other obscure and minor bug fixes - see the timeline for details.
1163
1164	<a name='v1_29'></a>
1165	<h2>Changes For Version 1.29 (2014-06-12)</h2>
1166	* Add the ability to display content, diffs and annotations for UTF16
1167	text files in the web interface.
1168	* Add the "SaveAs..." and "Invert" buttons
1169	to the graphical diff display that results
1170	from using the --tk option with the [/help/diff \| fossil diff] command.
1171

	--- www/changes.wiki
	+++ www/changes.wiki
	@@ -1,9 +1,8 @@
1	<title>Change Log</title>
2
3	<h2 id='v2_17'>Changes for version 2.17 (pending)</h2>

4	* Added new options to the various
5	[/help?cmd=diff\|diff commands]: --by, -b, --webpage, --json, --tcl.
6	* Performance and display improvements to the internal diff engine, including
7	partial-line matching for unified diffs and improved partial line matching for
8	side-by-side diffs.
	@@ -32,12 +31,11 @@
31	of <pre> and <script> is passed through verbatim.
32	* The [/help?cmd=wiki\|wiki list command] no longer lists "deleted"
33	pages by default. Use the new <tt>--all</tt> option to include deleted
34	pages in the output.
35
36	<h2 id='v2_16'>Changes for Version 2.16 (2021-07-02)</h2>

37	* <b>Security:</b> Fix the client-side TLS so that it verifies that the
38	server hostname matches its certificate.
39	* The default "ssh" command on Windows is changed to "ssh" instead of the
40	legacy "plink", as ssh is now generally available on Windows systems.
41	Installations that still need to use the legacy "plink" can make that
	@@ -79,12 +77,11 @@
77	[/timeline?c=c717f1ef9a1a4c91\|can DROP] a VIEW or an INDEX provided
78	that its name starts with '<code>ticket</code>' or '<code>fx_</code>'.
79	* Update the built-in SQLite to version 3.36.0.
80	* Numerous other minor enhancements.
81
82	<h2 id='v2_15'>Changes for Version 2.15 (2021-03-26) and Patch 2.15.1 on (2021-04-07)

83	and 2.15.2 on (2021-06-15)</h2>
84	* <b>Patch 2.15.2:</b> Fix the client-side TLS so that it verifies that the
85	server hostname matches its certificate. <b>Upgrading to
86	the patch is recommended.</b>
87	* <b>Patch 2.15.1:</b> Fix a data exfiltration bug in the server. <b>Upgrading to
	@@ -164,12 +161,11 @@
161	gained client-side UI to help with comparison between two arbitrary
162	versions of a wiki (by the means of anchoring a "baseline" version)
163	and the ability to squeeze several sequential edits made by the same
164	user into a single "recycled" row (the latest edit in that sequence).
165
166	<h2 id='v2_14'>Changes for Version 2.14 (2021-01-20) and Patch 2.14.1 on (2021-04-07)

167	and 2.14.2 on (2021-06-15)</h2>
168	* <b>Patch 2.14.2:</b> Fix the client-side TLS so that it verifies that the
169	server hostname matches its certificate. <b>Upgrading to
170	the patch is recommended.</b><
171	* <b>Patch 2.14.1:</b> Fix a data exfiltration bug in the server.
	@@ -231,12 +227,11 @@
227	performance optimizations, especially performance associated with
228	startup, and minor improvements to the CLI.
229	* Performance optimizations to Fossil itself.
230	* Countless improvements and enhancements to the documentation
231
232	<h2 id='v2_13'>Changes for Version 2.13 (2020-11-01)</h2>

233
234	* Added support for [./interwiki.md\|interwiki links].
235	* Enable <del> and <ins> markup in wiki.
236	* Improvements to the Forum threading display.
237	* Added support for embedding [./pikchr.md\|pikchr]
	@@ -262,12 +257,11 @@
257	/finfo change in the previous bullet depends on enhancements to
258	recursive common table expressions that are only available in
259	SQLite 3.34.0 and later.
260	* Countless other minor refinements and documentation improvements.
261
262	<h2 id='v2_12'>Changes for Version 2.12.1 (2020-08-20)</h2>

263
264	* (2.12.1): Fix client-side vulnerabilities discovered by Max Justicz.
265	* Security fix in the "[/help?cmd=git\|fossil git export]" command.
266	The same fix is also backported to version 2.10.1 and 2.11.1.
267	New "safety-net" features were added to prevent similar problems
	@@ -345,12 +339,11 @@
339	* The [/help?cmd=allow-symlinks\|allow-symlinks setting] no longer
340	syncs. It must be activated individually on any clones which require
341	symlinks.
342	* Countless documentation enhancements.
343
344	<h2 id='v2_11'>Changes for Version 2.11 (2020-05-25)</h2>

345
346	* (2.11.2): Backport security fixes from 2.12.1
347	* (2.11.1): Backport security fix for the "fossil git export" command.
348	* Support [/md_rules\|Markdown] in the default ticket configuration.
349	* Timestamp strings in [./checkin_names.wiki\|object names]
	@@ -436,12 +429,11 @@
429	* Update internal Unicode character tables, used in regular expression
430	handling, from version 12.1 to 13.
431	* Many documentation enhancements.
432	* Many minor enhancements to existing features.
433
434	<h2 id='v2_10'>Changes for Version 2.10 (2019-10-04)</h2>

435
436	* (2.10.2): backport security fixes from 2.12.1
437	* (2.10.1): backport security fix for the "fossil git export" command.
438	* Added support for [./serverext.wiki\|CGI-based Server Extensions].
439	* Added the [/help?cmd=repolist-skin\|repolist-skin] setting used to
	@@ -473,12 +465,11 @@
465	An additional check for conflicts is added after interactive
466	check-in comment entry, to compensate for the reduced lock interval.
467	* Performance optimizations.
468	* Many documentation improvements.
469
470	<h2 id='v2_9'>Changes for Version 2.9 (2019-07-13)</h2>

471
472	* Added the [/help?cmd=git\|fossil git export] command and instructions
473	for [./mirrortogithub.md\|creating a GitHub mirror of a Fossil project].
474	* Improved handling of relative hyperlinks on the
475	[/help?cmd=/artifact\|/artifact] pages for wiki. For example,
	@@ -544,12 +535,11 @@
535	that can cause repository databases to be overwritten with debugging
536	output, thus corrupting the repository. This is only a factor when
537	CGI debugging is enabled, and even then is a rare occurrence, but it is
538	obviously an important fix.
539
540	<h2 id='v2_8'>Changes for Version 2.8 (2019-02-20)</h2>

541
542	* Show cherry-pick merges as dotted lines on the timeline graph.
543	→ The "fossil rebuild" command must be run to create and
544	populate the new "cherrypick" table in the repository in order
545	for this feature to operate.
	@@ -611,12 +601,11 @@
601	backoffice feature.
602	* Update the built-in SQLite to version 3.27.1.
603	* Various other small enhancements to webpages and documentation.
604
605
606	<h2 id='v2_7'>Changes for Version 2.7 (2018-09-22)</h2>

607
608	* Add the [./alerts.md\|email alerts] feature for commits, ticket
609	changes, wiki changes, forum posts, and announcements. This is
610	still a work in progress. It is functional, but it is not as easy to
611	setup and use as it ought to be.
	@@ -654,12 +643,11 @@
643	<tt>./configure --with-legacy-mv-rm</tt> to make it available. The
644	setting remains disabled by default, however, so you must still say
645	<tt>fossil set mv-rm-files 1</tt> to enable it on each repository
646	where you want hard <tt>mv/rm</tt> behavior.
647
648	<h2 id='v2_6'>Changes for Version 2.6 (2018-05-04)</h2>

649
650	* Fix a bug that was causing crashes while trying to clone the TCL
651	repository. This fix is the main reason for the current release.
652	* Added the new "Classic" timeline viewing mode. "Classic" is the
653	same as "Verbose" in the previous release. The "Verbose" mode is
	@@ -683,12 +671,11 @@
671	tarballs that have been accessed more than once.
672	* Additional defenses against web-based attacks. There have not been
673	any known vulnerabilities. We are just being paranoid.
674	* Update the built-in SQLite to an alpha version of 3.24.0.
675
676	<h2 id='v2_5'>Changes for Version 2.5 (2018-02-07)</h2>

677
678	* Numerous enhancements to the look and feel of the web interface.
679	Especially: Added separate "Modern", "Compact", "Verbose", and
680	"Columnar" view options on timelines.
681	* Common display settings (such as the "view" option and the number
	@@ -719,12 +706,11 @@
706	road toward supporting a strict Content Security Policy. More work
707	is to be done.
708	* Initial infrastructure is in place to make use of the pledge()
709	system call in OpenBSD. More work is to be done.
710
711	<h2 id='v2_4'>Changes for Version 2.4 (2017-11-03)</h2>

712
713	* New feature: URL Aliases. URL Aliases allow an administrator
714	to define their own URLs on the web interface that are rewritten to
715	built-in URLs with specific parameters. Create and configure URL Aliases
716	using the /Setup/URL_Aliases menu option in the web interface.
	@@ -759,12 +745,11 @@
745	directory.
746	* The admin-log and access-log settings are now on by default for
747	new repositories.
748	* Update the built-in SQLite to version 3.21.0.
749
750	<h2 id='v2_3'>Changes for Version 2.3 (2017-07-21)</h2>

751
752	* Update the built-in SQLite to version 3.20.0 (beta).
753	* Update internal Unicode character tables, used in regular expression
754	handling, from version 9.0 to 10.0.
755	* Show the last-sync-URL on the [/help?cmd=/urllist\|/urllist] page.
	@@ -780,12 +765,11 @@
765	* Fix "database locked" warnings caused by "PRAGMA optimize".
766	* Fix a potential XSS vulnerability on the
767	[/help?cmd=/help\|/help] webpage.
768	* Documentation updates
769
770	<h2 id='v2_2'>Changes for Version 2.2 (2017-04-11)</h2>

771
772	* GIT comment tags are now handled by Fossil during import/export.
773	* Show the content of README files on directory listings.
774	([/file/skins\|example])
775	* Support for Basic Authentication if enabled (default off).
	@@ -797,23 +781,21 @@
781	is still accepted for backwards compatibility.
782	* Update the built-in SQLite to version 3.18.0.
783	* Run "[https://www.sqlite.org/pragma.html#pragma_optimize\|PRAGMA optimize]"
784	on the database connection as it is closing.
785
786	<h2 id='v2_1'>Changes for Version 2.1 (2017-03-10)</h2>

787
788	* Add support for [./hashpolicy.wiki\|hash policies] that control which
789	of the Hardened-SHA1 or SHA3-256 algorithms is used to name new
790	artifacts.
791	* Add the "gshow" and "gcat" subcommands to [/help?cmd=stash\|fossil stash].
792	* Add the [/help?cmd=/juvlist\|/juvlist] web page and use it to construct
793	the [/uv/download.html\|Download Page] of the Fossil self-hosting website
794	using Ajax.
795
796	<h2 id='v2_0'>Changes for Version 2.0 (2017-03-03)</h2>

797
798	* Use the
799	[https://github.com/cr-marcstevens/sha1collisiondetection\|hardened SHA1]
800	implementation by Marc Stevens and Dan Shumow.
801	* Add the ability to read and understand
	@@ -820,12 +802,11 @@
802	[./fileformat.wiki#names\|artifact names] that are based on SHA3-256
803	rather than SHA1, but do not actually generate any such names.
804	* Added the [/help?cmd=sha3sum\|sha3sum] command.
805	* Update the built-in SQLite to version 3.17.0.
806
807	<h2 id='v1_37'>Changes for Version 1.37 (2017-01-16)</h2>

808
809	* Add checkbox widgets to various web pages. See [/technote/8d18bf27e9\|
810	this technote] for more information. To get the checkboxes to look as
811	intended, you must update the CSS in your repository and all clones.
812	* Add the [/help/all\|fossil all ui] command
	@@ -858,12 +839,11 @@
839	[./encryptedrepos.wiki\|encrypted repositories].
840	* Update the built-in SQLite to version 3.16.2.
841	* Update the built-in Zlib to version 1.2.11.
842
843
844	<h2 id='v1_36'>Changes for Version 1.36 (2016-10-24)</h2>

845
846	* Add support for [./unvers.wiki\|unversioned content],
847	the [/help?cmd=unversioned\|fossil unversioned] command and the
848	[/help?cmd=/uv\|/uv] and [/uvlist] web pages.
849	* The [/uv/download.html\|download page] is moved into
	@@ -889,12 +869,11 @@
869	able to pull from their parent but not push.
870	* Added the -nocomplain option to the TH1 "query" command.
871	* Added support for the chng=GLOBLIST query parameter on the
872	[/help?cmd=/timeline\|/timeline] webpage.
873
874	<h2 id='v1_35'>Changes for Version 1.35 (2016-06-14)</h2>

875
876	* Enable symlinks by default on all non-Windows platforms.
877	* Enhance the [/md_rules\|Markdown formatting] so that hyperlinks that begin
878	with "/" are relative to the root of the Fossil repository.
879	* Rework the [/help?cmd=/setup_ulist\|/setup_list page] (the User List page)
	@@ -933,12 +912,11 @@
912	names in place of getpass() to read passwords and passphrases
913	* Option --baseurl now works on Windows.
914	* Numerous documentation improvements.
915	* Update the built-in SQLite to version 3.13.0.
916
917	<h2 id='v1_34'>Changes for Version 1.34 (2015-11-02)</h2>

918
919	* Make the [/help?cmd=clean\|fossil clean] command undoable for files less
920	than 10MiB.
921	* Update internal Unicode character tables, used in regular expression
922	handling, from version 7.0 to 8.0.
	@@ -969,12 +947,11 @@
947	* Change the mimetype for ".n" and ".man" files to text/plain.
948	* Display improvements in the [/help?cmd=bisect\|fossil bisect chart] command.
949	* Updated the built-in SQLite to version 3.9.1 and activated JSON1 and FTS5
950	support (both currently unused within Fossil).
951
952	<h2 id='v1_33'>Changes for Version 1.33 (2015-05-23)</h2>

953	* Improved fork detection on [/help?cmd=update\|fossil update],
954	[/help?cmd=status\|fossil status] and related commands.
955	* Change the default skin to what used to be called "San Francisco Modern".
956	* Add the [/repo-tabsize] web page
957	* Add [/help?cmd=import\|fossil import --svn], for importing a subversion
	@@ -1019,12 +996,11 @@
996	field for direct entry of the user name to each applicable report.
997	* Create parent directories of [/help?cmd=settings\|empty-dirs] if they don't
998	already exist.
999	* Inhibit timeline links to wiki pages that have been deleted.
1000
1001	<h2 id='v1_33'>Changes for Version 1.32 (2015-03-14)</h2>

1002	* When creating a new repository using [/help?cmd=init\|fossil init], ensure
1003	that the new repository is fully compatible with historical versions of
1004	Fossil by having a valid manifest as RID 1.
1005	* Anti-aliased rendering of arrowheads on timeline graphs.
1006	* Added vi/less-style key bindings to the --tk diff GUI.
	@@ -1036,12 +1012,11 @@
1012	* Enhance the "ln=" query parameter on artifact displays to accept multiple
1013	ranges, separate by spaces (or "+" when URL-encoded).
1014	* Added [/help?cmd=forget\|fossil forget] as an alias for
1015	[/help?cmd=rm\|fossil rm].
1016
1017	<h2 id='v1_31'>Changes For Version 1.31 (2015-02-23)</h2>

1018	* Change the auxiliary schema by adding columns MLINK.ISAUX and MLINK.PMID
1019	columns to the schema, to support better drawing of file change graphs.
1020	A [/help?cmd=rebuild\|fossil rebuild] is recommended but is not required.
1021	so that the new graph drawing logic can work effectively.
1022	* Added [/search\|search] over Check-in comments, Documents, Tickets and
	@@ -1088,12 +1063,11 @@
1063	* Allow the user of Common Table Expressions in the SQL that defaults
1064	ticket reports.
1065	* Break out the components (css, footer, and header) for the
1066	various built-in skins into separate files in the source tree.
1067
1068	<h2 id='v1_30'>Changes For Version 1.30 (2015-01-19)</h2>

1069	* Added the [/help?cmd=bundle\|fossil bundle] command.
1070	* Added the [/help?cmd=purge\|fossil purge] command.
1071	* Added the [/help?cmd=publish\|fossil publish] command.
1072	* Added the [/help?cmd=unpublished\|fossil unpublished] command.
1073	* Enhance the [/tree] webpage to show the age of each file with the option
	@@ -1159,12 +1133,11 @@
1133	the correctness of printf-style formatting strings.
1134	* Fix CVE-2014-3566, also known as the POODLE SSL 3.0 vulnerability.
1135	* Numerous documentation fixes and improvements.
1136	* Other obscure and minor bug fixes - see the timeline for details.
1137
1138	<h2 id='v1_29'>Changes For Version 1.29 (2014-06-12)</h2>

1139	* Add the ability to display content, diffs and annotations for UTF16
1140	text files in the web interface.
1141	* Add the "SaveAs..." and "Invert" buttons
1142	to the graphical diff display that results
1143	from using the --tk option with the [/help/diff \| fossil diff] command.
1144

M www/concepts.wiki

+3 -5

		--- www/concepts.wiki
		+++ www/concepts.wiki
		@@ -96,11 +96,11 @@
96	96	Communication between repositories is via HTTP. Remote
97	97	repositories are identified by URL. You can also point a web browser
98	98	at a repository and get human-readable status, history, and tracking
99	99	information about the project.
100	100
101		-<h3><a id="artifacts"></a>2.1 Identification Of Artifacts</h3>
	101	+<h3 id="artifacts">2.1 Identification Of Artifacts</h3>
102	102
103	103	A particular version of a particular file is called an "artifact". Each
104	104	artifact has a universally unique name which is the <a
105	105	href="http://en.wikipedia.org/wiki/SHA1">SHA1</a> or <a
106	106	href="http://en.wikipedia.org/wiki/SHA3">SHA3-256</a> hash of the
		@@ -182,12 +182,11 @@
182	182	and links to other check-ins from which the current check-in
183	183	is derived. There is also a couple of checksums used to verify
184	184	the integrity of the check-in. And the whole manifest might
185	185	be PGP clearsigned.</p>
186	186
187		-<a name="keyconc"></a>
188		-<h3>2.3 Key concepts</h3>
	187	+<h3 id="keyconc">2.3 Key concepts</h3>
189	188
190	189	<ul>
191	190	<li>A <b>check-in</b> is a set of files arranged
192	191	in a hierarchy.</li>
193	192	<li>A <b>repository</b> keeps a record of historical check-ins.</li>
		@@ -247,12 +246,11 @@
247	246
248	247	In the next section, when we say things like "use the <b>help</b>
249	248	command" we mean to use the command name "help" as the first
250	249	token after the name of the Fossil executable, as shown above.
251	250
252		-<a name="workflow"></a>
253		-<h2>4.0 Workflow</h2>
	251	+<h2 id="workflow">4.0 Workflow</h2>
254	252
255	253	<verbatim type="pikchr float-right">
256	254	down
257	255	R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70%
258	256	move 150%
259	257

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -96,11 +96,11 @@
96	Communication between repositories is via HTTP. Remote
97	repositories are identified by URL. You can also point a web browser
98	at a repository and get human-readable status, history, and tracking
99	information about the project.
100
101	<h3><a id="artifacts"></a>2.1 Identification Of Artifacts</h3>
102
103	A particular version of a particular file is called an "artifact". Each
104	artifact has a universally unique name which is the <a
105	href="http://en.wikipedia.org/wiki/SHA1">SHA1</a> or <a
106	href="http://en.wikipedia.org/wiki/SHA3">SHA3-256</a> hash of the
	@@ -182,12 +182,11 @@
182	and links to other check-ins from which the current check-in
183	is derived. There is also a couple of checksums used to verify
184	the integrity of the check-in. And the whole manifest might
185	be PGP clearsigned.</p>
186
187	<a name="keyconc"></a>
188	<h3>2.3 Key concepts</h3>
189
190	<ul>
191	<li>A <b>check-in</b> is a set of files arranged
192	in a hierarchy.</li>
193	<li>A <b>repository</b> keeps a record of historical check-ins.</li>
	@@ -247,12 +246,11 @@
247
248	In the next section, when we say things like "use the <b>help</b>
249	command" we mean to use the command name "help" as the first
250	token after the name of the Fossil executable, as shown above.
251
252	<a name="workflow"></a>
253	<h2>4.0 Workflow</h2>
254
255	<verbatim type="pikchr float-right">
256	down
257	R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70%
258	move 150%
259

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -96,11 +96,11 @@
96	Communication between repositories is via HTTP. Remote
97	repositories are identified by URL. You can also point a web browser
98	at a repository and get human-readable status, history, and tracking
99	information about the project.
100
101	<h3 id="artifacts">2.1 Identification Of Artifacts</h3>
102
103	A particular version of a particular file is called an "artifact". Each
104	artifact has a universally unique name which is the <a
105	href="http://en.wikipedia.org/wiki/SHA1">SHA1</a> or <a
106	href="http://en.wikipedia.org/wiki/SHA3">SHA3-256</a> hash of the
	@@ -182,12 +182,11 @@
182	and links to other check-ins from which the current check-in
183	is derived. There is also a couple of checksums used to verify
184	the integrity of the check-in. And the whole manifest might
185	be PGP clearsigned.</p>
186
187	<h3 id="keyconc">2.3 Key concepts</h3>

188
189	<ul>
190	<li>A <b>check-in</b> is a set of files arranged
191	in a hierarchy.</li>
192	<li>A <b>repository</b> keeps a record of historical check-ins.</li>
	@@ -247,12 +246,11 @@
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
251	<h2 id="workflow">4.0 Workflow</h2>

252
253	<verbatim type="pikchr float-right">
254	down
255	R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70%
256	move 150%
257

M www/customskin.md

+8 -8

		--- www/customskin.md
		+++ www/customskin.md
		@@ -3,11 +3,11 @@
3	3	The Fossil web interface comes with a pre-configured look and feel. The default
4	4	look and feel works fine in many situations. However, you may want to change
5	5	the look and feel (the "skin") of Fossil to better suite your own individual tastes.
6	6	This document provides background information to aid you in that task.
7	7
8		-## <a name="builtin"></a>Built-in Skins
	8	+## <a id="builtin"></a>Built-in Skins
9	9
10	10	Fossil comes with [multiple built-in skins](/skins). If the default skin does not
11	11	suite your tastes, perhaps one of the other built-in skins will work better.
12	12	If nothing else, the built-in skins can serve as examples or templates that
13	13	you can use to develop your own custom skin.
		@@ -25,11 +25,11 @@
25	25	* js.txt
26	26
27	27	Try out the built-in skins by using the --skin option on the
28	28	[fossil ui](/help?cmd=ui) or [fossil server](/help?cmd=server) commands.
29	29
30		-## <a name="sharing"></a>Sharing Skins
	30	+## <a id="sharing"></a>Sharing Skins
31	31
32	32	The skin of a repository is not part of the versioned state and does not
33	33	"push" or "pull" like checked-in files. The skin is local to the
34	34	repository. However, skins can be shared between repositories using
35	35	the [fossil config](/help?cmd=configuration) command.
		@@ -135,11 +135,11 @@
135	135	to close out the generated HTML:
136	136
137	137	</body>
138	138	</html>
139	139
140		-## <a name="mainmenu"></a>Changing the Main Menu Contents
	140	+## <a id="mainmenu"></a>Changing the Main Menu Contents
141	141
142	142	As of Fossil 2.15, the actual text content of the skin’s main menu is no
143	143	longer part of the skin proper if you’re using one of the stock skins.
144	144	If you look at the Header section of the skin, you’ll find a
145	145	`<div class="mainmenu">` element whose contents are set by a short
		@@ -152,11 +152,11 @@
152	152
153	153	See the [`capexpr`](./th1.md#capexpr) section of the TH1 docs for help
154	154	on interpreting the default contents of this block.
155	155
156	156
157		-## <a name="override"></a>Overriding the HTML Header and Footer
	157	+## <a id="override"></a>Overriding the HTML Header and Footer
158	158
159	159	Notice that the `<html>`, `<head>`, and opening `<body>`
160	160	elements at the beginning of the document,
161	161	and the closing `</body>` and `</html>` elements at the end are automatically
162	162	generated by Fossil. This is recommended.
		@@ -316,11 +316,11 @@
316	316	under development and press "Reload" only to find that the display
317	317	did not change. After you have finished work your skin, the
318	318	caches should synchronize with your new design and you can reactivate
319	319	your web browser's cache and take it out of developer mode.
320	320
321		-## <a name="headfoot"></a>Header and Footer Processing
	321	+## <a id="headfoot"></a>Header and Footer Processing
322	322
323	323	The `header.txt` and `footer.txt` control files of a skin are the HTML text
324	324	of the Content Header and Content Footer, except that before being inserted
325	325	into the output stream, the text is run through a
326	326	[TH1 interpreter](./th1.md) that might adjust the text as follows:
		@@ -348,11 +348,11 @@
348	348
349	349	The same TH1 interpreter is used for both the header and the footer
350	350	and for all scripts contained within them both. Hence, any global
351	351	TH1 variables that are set by the header are available to the footer.
352	352
353		-## <a name="menu"></a>Customizing the ≡ Hamburger Menu
	353	+## <a id="menu"></a>Customizing the ≡ Hamburger Menu
354	354
355	355	The menu bar of the default skin has an entry to open a drop-down menu with
356	356	additional navigation links, represented by the ≡ button (hence the name
357	357	"hamburger menu"). The Javascript logic to open and close the hamburger menu
358	358	when the button is clicked is usually handled by a script named
		@@ -412,11 +412,11 @@
412	412	the Javascript logic to override the default menu animation duration of 400 ms.
413	413	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
414	414	animation is disabled by setting the attribute to `"0"`.
415	415
416	416
417		-## <a name="vars"></a>TH1 Variables
	417	+## <a id="vars"></a>TH1 Variables
418	418
419	419	Before expanding the TH1 within the header and footer, Fossil first
420	420	initializes a number of TH1 variables to values that depend on
421	421	repository settings and the specific page being generated.
422	422
		@@ -489,11 +489,11 @@
489	489	footer is free to change or erase them. But they should probably be treated
490	490	as constants. New predefined values are likely to be added in future
491	491	releases of Fossil.
492	492
493	493
494		-## <a name="procedure"></a>Suggested Skin Customization Procedure
	494	+## <a id="procedure"></a>Suggested Skin Customization Procedure
495	495
496	496	Developers are free, of course, to develop new skins using any method they
497	497	want, but the following is a technique that has worked well in the past and
498	498	can serve as a starting point for future work:
499	499
500	500

	--- www/customskin.md
	+++ www/customskin.md
	@@ -3,11 +3,11 @@
3	The Fossil web interface comes with a pre-configured look and feel. The default
4	look and feel works fine in many situations. However, you may want to change
5	the look and feel (the "skin") of Fossil to better suite your own individual tastes.
6	This document provides background information to aid you in that task.
7
8	## <a name="builtin"></a>Built-in Skins
9
10	Fossil comes with [multiple built-in skins](/skins). If the default skin does not
11	suite your tastes, perhaps one of the other built-in skins will work better.
12	If nothing else, the built-in skins can serve as examples or templates that
13	you can use to develop your own custom skin.
	@@ -25,11 +25,11 @@
25	* js.txt
26
27	Try out the built-in skins by using the --skin option on the
28	[fossil ui](/help?cmd=ui) or [fossil server](/help?cmd=server) commands.
29
30	## <a name="sharing"></a>Sharing Skins
31
32	The skin of a repository is not part of the versioned state and does not
33	"push" or "pull" like checked-in files. The skin is local to the
34	repository. However, skins can be shared between repositories using
35	the [fossil config](/help?cmd=configuration) command.
	@@ -135,11 +135,11 @@
135	to close out the generated HTML:
136
137	</body>
138	</html>
139
140	## <a name="mainmenu"></a>Changing the Main Menu Contents
141
142	As of Fossil 2.15, the actual text content of the skin’s main menu is no
143	longer part of the skin proper if you’re using one of the stock skins.
144	If you look at the Header section of the skin, you’ll find a
145	`<div class="mainmenu">` element whose contents are set by a short
	@@ -152,11 +152,11 @@
152
153	See the [`capexpr`](./th1.md#capexpr) section of the TH1 docs for help
154	on interpreting the default contents of this block.
155
156
157	## <a name="override"></a>Overriding the HTML Header and Footer
158
159	Notice that the `<html>`, `<head>`, and opening `<body>`
160	elements at the beginning of the document,
161	and the closing `</body>` and `</html>` elements at the end are automatically
162	generated by Fossil. This is recommended.
	@@ -316,11 +316,11 @@
316	under development and press "Reload" only to find that the display
317	did not change. After you have finished work your skin, the
318	caches should synchronize with your new design and you can reactivate
319	your web browser's cache and take it out of developer mode.
320
321	## <a name="headfoot"></a>Header and Footer Processing
322
323	The `header.txt` and `footer.txt` control files of a skin are the HTML text
324	of the Content Header and Content Footer, except that before being inserted
325	into the output stream, the text is run through a
326	[TH1 interpreter](./th1.md) that might adjust the text as follows:
	@@ -348,11 +348,11 @@
348
349	The same TH1 interpreter is used for both the header and the footer
350	and for all scripts contained within them both. Hence, any global
351	TH1 variables that are set by the header are available to the footer.
352
353	## <a name="menu"></a>Customizing the ≡ Hamburger Menu
354
355	The menu bar of the default skin has an entry to open a drop-down menu with
356	additional navigation links, represented by the ≡ button (hence the name
357	"hamburger menu"). The Javascript logic to open and close the hamburger menu
358	when the button is clicked is usually handled by a script named
	@@ -412,11 +412,11 @@
412	the Javascript logic to override the default menu animation duration of 400 ms.
413	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
414	animation is disabled by setting the attribute to `"0"`.
415
416
417	## <a name="vars"></a>TH1 Variables
418
419	Before expanding the TH1 within the header and footer, Fossil first
420	initializes a number of TH1 variables to values that depend on
421	repository settings and the specific page being generated.
422
	@@ -489,11 +489,11 @@
489	footer is free to change or erase them. But they should probably be treated
490	as constants. New predefined values are likely to be added in future
491	releases of Fossil.
492
493
494	## <a name="procedure"></a>Suggested Skin Customization Procedure
495
496	Developers are free, of course, to develop new skins using any method they
497	want, but the following is a technique that has worked well in the past and
498	can serve as a starting point for future work:
499
500

	--- www/customskin.md
	+++ www/customskin.md
	@@ -3,11 +3,11 @@
3	The Fossil web interface comes with a pre-configured look and feel. The default
4	look and feel works fine in many situations. However, you may want to change
5	the look and feel (the "skin") of Fossil to better suite your own individual tastes.
6	This document provides background information to aid you in that task.
7
8	## <a id="builtin"></a>Built-in Skins
9
10	Fossil comes with [multiple built-in skins](/skins). If the default skin does not
11	suite your tastes, perhaps one of the other built-in skins will work better.
12	If nothing else, the built-in skins can serve as examples or templates that
13	you can use to develop your own custom skin.
	@@ -25,11 +25,11 @@
25	* js.txt
26
27	Try out the built-in skins by using the --skin option on the
28	[fossil ui](/help?cmd=ui) or [fossil server](/help?cmd=server) commands.
29
30	## <a id="sharing"></a>Sharing Skins
31
32	The skin of a repository is not part of the versioned state and does not
33	"push" or "pull" like checked-in files. The skin is local to the
34	repository. However, skins can be shared between repositories using
35	the [fossil config](/help?cmd=configuration) command.
	@@ -135,11 +135,11 @@
135	to close out the generated HTML:
136
137	</body>
138	</html>
139
140	## <a id="mainmenu"></a>Changing the Main Menu Contents
141
142	As of Fossil 2.15, the actual text content of the skin’s main menu is no
143	longer part of the skin proper if you’re using one of the stock skins.
144	If you look at the Header section of the skin, you’ll find a
145	`<div class="mainmenu">` element whose contents are set by a short
	@@ -152,11 +152,11 @@
152
153	See the [`capexpr`](./th1.md#capexpr) section of the TH1 docs for help
154	on interpreting the default contents of this block.
155
156
157	## <a id="override"></a>Overriding the HTML Header and Footer
158
159	Notice that the `<html>`, `<head>`, and opening `<body>`
160	elements at the beginning of the document,
161	and the closing `</body>` and `</html>` elements at the end are automatically
162	generated by Fossil. This is recommended.
	@@ -316,11 +316,11 @@
316	under development and press "Reload" only to find that the display
317	did not change. After you have finished work your skin, the
318	caches should synchronize with your new design and you can reactivate
319	your web browser's cache and take it out of developer mode.
320
321	## <a id="headfoot"></a>Header and Footer Processing
322
323	The `header.txt` and `footer.txt` control files of a skin are the HTML text
324	of the Content Header and Content Footer, except that before being inserted
325	into the output stream, the text is run through a
326	[TH1 interpreter](./th1.md) that might adjust the text as follows:
	@@ -348,11 +348,11 @@
348
349	The same TH1 interpreter is used for both the header and the footer
350	and for all scripts contained within them both. Hence, any global
351	TH1 variables that are set by the header are available to the footer.
352
353	## <a id="menu"></a>Customizing the ≡ Hamburger Menu
354
355	The menu bar of the default skin has an entry to open a drop-down menu with
356	additional navigation links, represented by the ≡ button (hence the name
357	"hamburger menu"). The Javascript logic to open and close the hamburger menu
358	when the button is clicked is usually handled by a script named
	@@ -412,11 +412,11 @@
412	the Javascript logic to override the default menu animation duration of 400 ms.
413	A faster animation duration of 80-200 ms may be preferred for smaller menus. The
414	animation is disabled by setting the attribute to `"0"`.
415
416
417	## <a id="vars"></a>TH1 Variables
418
419	Before expanding the TH1 within the header and footer, Fossil first
420	initializes a number of TH1 variables to values that depend on
421	repository settings and the specific page being generated.
422
	@@ -489,11 +489,11 @@
489	footer is free to change or erase them. But they should probably be treated
490	as constants. New predefined values are likely to be added in future
491	releases of Fossil.
492
493
494	## <a id="procedure"></a>Suggested Skin Customization Procedure
495
496	Developers are free, of course, to develop new skins using any method they
497	want, but the following is a technique that has worked well in the past and
498	can serve as a starting point for future work:
499
500

M www/defcsp.md

+12 -12

		--- www/defcsp.md
		+++ www/defcsp.md
		@@ -40,11 +40,11 @@
40	40	default-src *;
41	41	</pre>
42	42
43	43	The following sections detail the maining of the default CSP setting.
44	44
45		-### <a name="base"></a> default-src 'self' data:
	45	+### <a id="base"></a> default-src 'self' data:
46	46
47	47	This policy means mixed-origin content isn’t allowed, so you can’t refer
48	48	to resources on other web domains. Browsers will ignore a link like the
49	49	one in the following Markdown under our default CSP:
50	50
		@@ -77,11 +77,11 @@
77	77
78	78	[b64]: https://en.wikipedia.org/wiki/Base64
79	79	[svr]: ./server/
80	80
81	81
82		-### <a name="img"></a> img-src * data:
	82	+### <a id="img"></a> img-src * data:
83	83
84	84	As of Fossil 2.15, we don’t restrict the source of inline images at all.
85	85	You can pull them in from remote systems as well as pull them from
86	86	within the Fossil repository itself, or use `data:` URIs.
87	87
		@@ -90,11 +90,11 @@
90	90	decoders, system dialog box spoofing, etc. — by changing this to
91	91	“`img-src 'self'`” possibly followed by “`data:`” if you will also use
92	92	`data:` URIs.
93	93
94	94
95		-### <a name="style"></a> style-src 'self' 'unsafe-inline'
	95	+### <a id="style"></a> style-src 'self' 'unsafe-inline'
96	96
97	97	This policy allows CSS information to come from separate files hosted
98	98	under the Fossil repo server’s Internet domain. It also allows inline CSS
99	99	`<style>` tags within the document text.
100	100
		@@ -111,11 +111,11 @@
111	111	less than the harm possible with injected javascript. And so the
112	112	`'unsafe-inline'` compromise is accepted for now, though it might
113	113	go away in some future release of Fossil.
114	114
115	115
116		-### <a name="script"></a> script-src 'self' 'nonce-%s'
	116	+### <a id="script"></a> script-src 'self' 'nonce-%s'
117	117
118	118	This policy disables in-line JavaScript and only allows `<script>`
119	119	elements if the `<script>` includes a `nonce` attribute that matches the
120	120	one declared by the CSP. That nonce is a large random number, unique for
121	121	each HTTP page generated by Fossil, so an attacker cannot guess the
		@@ -154,11 +154,11 @@
154	154
155	155	[ext]: ./serverext.wiki
156	156	[su]: ./caps/admin-v-setup.md#apsu
157	157
158	158
159		-#### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities
	159	+#### <a id="xss"></a>Cross-Site Scripting via Ordinary User Capabilities
160	160
161	161	We’re so restrictive about how we treat JavaScript because it can lead
162	162	to difficult-to-avoid scripting attacks. If we used the same CSP for
163	163	`<script>` tags [as for `<style>` tags](#style), anyone with check-in
164	164	rights on your repository could add a JavaScript file to your repository
		@@ -214,11 +214,11 @@
214	214	[ed]: ./embeddeddoc.wiki
215	215	[edtf]: ./embeddeddoc.wiki#th1
216	216	[hfed]: ./embeddeddoc.wiki#html
217	217
218	218
219		-## <a name="serving"></a>Serving Files Within the Limits
	219	+## <a id="serving"></a>Serving Files Within the Limits
220	220
221	221	There are several ways to serve files within the above restrictions,
222	222	avoiding the need to [override the default CSP](#override). In
223	223	decreasing order of simplicity and preference:
224	224
		@@ -305,11 +305,11 @@
305	305	[uu]: /help?cmd=/uv
306	306	[uv]: ./unvers.wiki
307	307	[wiki]: ./wikitheory.wiki
308	308
309	309
310		-## <a name="override"></a>Overriding the Default CSP
	310	+## <a id="override"></a>Overriding the Default CSP
311	311
312	312	If you wish to relax the default CSP’s restrictions or to tighten them
313	313	further, there are multiple ways to accomplish that.
314	314
315	315	The following methods are listed in top-down order to give the simplest
		@@ -316,11 +316,11 @@
316	316	and most straightforward method first. Further methods dig down deeper
317	317	into the stack, which is helpful to understand even if you end up using
318	318	a higher-level method.
319	319
320	320
321		-### <a name="cspsetting"></a>The `default-csp` Setting
	321	+### <a id="cspsetting"></a>The `default-csp` Setting
322	322
323	323	If the [`default-csp` setting](/help?cmd=default-csp) is defined and is
324	324	not an empty string, its value is injected into the page using
325	325	[TH1](./th1.md) via one or more of the methods below, depending on the
326	326	skin you’re using and local configuration.
		@@ -355,11 +355,11 @@
355	355	your desired CSP via the command line. Setting it via the web UI
356	356	doesn’t have this problem.
357	357
358	358
359	359
360		-### <a name="th1"></a>TH1 Setup Hook
	360	+### <a id="th1"></a>TH1 Setup Hook
361	361
362	362	Fossil sets [the TH1 variable `$default_csp`][thvar] from the
363	363	`default-csp` setting and uses that to inject the value into generated
364	364	HTML pages in its stock configuration.
365	365
		@@ -373,11 +373,11 @@
373	373
374	374	[thvar]: ./customskin.md#vars
375	375
376	376
377	377
378		-### <a name="csrc"></a>Fossil C Source Code
	378	+### <a id="csrc"></a>Fossil C Source Code
379	379
380	380	When you do neither of the above things, Fossil uses
381	381	[a hard-coded default](/info?ln=527-530&name=65a555d0d4fb846b).
382	382
383	383	We tell you about this not to suggest that you hack the Fossil C source
		@@ -384,11 +384,11 @@
384	384	code to change the CSP but simply to document the next step before we
385	385	move down-stack.
386	386
387	387
388	388
389		-### <a name="header"></a>Skin Header
	389	+### <a id="header"></a>Skin Header
390	390
391	391	[In the normal case](./customskin.md#override), Fossil injects the CSP
392	392	retrieved by one of the above methods into the header of all HTML
393	393	documents it generates:
394	394
		@@ -445,11 +445,11 @@
445	445	independently of the skin.
446	446
447	447	[dcinj]: /info?ln=7&name=bef080a6929a3e6f
448	448
449	449
450		-### <a name="fep"></a>Front-End Proxy
	450	+### <a id="fep"></a>Front-End Proxy
451	451
452	452	If your Fossil repo is behind some sort of HTTP [front-end proxy][svr],
453	453	the [preferred method][pmcsp] for setting the CSP is via a custom HTTP
454	454	header, which most HTTP reverse proxy programs allow.
455	455
456	456

	--- www/defcsp.md
	+++ www/defcsp.md
	@@ -40,11 +40,11 @@
40	default-src *;
41	</pre>
42
43	The following sections detail the maining of the default CSP setting.
44
45	### <a name="base"></a> default-src 'self' data:
46
47	This policy means mixed-origin content isn’t allowed, so you can’t refer
48	to resources on other web domains. Browsers will ignore a link like the
49	one in the following Markdown under our default CSP:
50
	@@ -77,11 +77,11 @@
77
78	[b64]: https://en.wikipedia.org/wiki/Base64
79	[svr]: ./server/
80
81
82	### <a name="img"></a> img-src * data:
83
84	As of Fossil 2.15, we don’t restrict the source of inline images at all.
85	You can pull them in from remote systems as well as pull them from
86	within the Fossil repository itself, or use `data:` URIs.
87
	@@ -90,11 +90,11 @@
90	decoders, system dialog box spoofing, etc. — by changing this to
91	“`img-src 'self'`” possibly followed by “`data:`” if you will also use
92	`data:` URIs.
93
94
95	### <a name="style"></a> style-src 'self' 'unsafe-inline'
96
97	This policy allows CSS information to come from separate files hosted
98	under the Fossil repo server’s Internet domain. It also allows inline CSS
99	`<style>` tags within the document text.
100
	@@ -111,11 +111,11 @@
111	less than the harm possible with injected javascript. And so the
112	`'unsafe-inline'` compromise is accepted for now, though it might
113	go away in some future release of Fossil.
114
115
116	### <a name="script"></a> script-src 'self' 'nonce-%s'
117
118	This policy disables in-line JavaScript and only allows `<script>`
119	elements if the `<script>` includes a `nonce` attribute that matches the
120	one declared by the CSP. That nonce is a large random number, unique for
121	each HTTP page generated by Fossil, so an attacker cannot guess the
	@@ -154,11 +154,11 @@
154
155	[ext]: ./serverext.wiki
156	[su]: ./caps/admin-v-setup.md#apsu
157
158
159	#### <a name="xss"></a>Cross-Site Scripting via Ordinary User Capabilities
160
161	We’re so restrictive about how we treat JavaScript because it can lead
162	to difficult-to-avoid scripting attacks. If we used the same CSP for
163	`<script>` tags [as for `<style>` tags](#style), anyone with check-in
164	rights on your repository could add a JavaScript file to your repository
	@@ -214,11 +214,11 @@
214	[ed]: ./embeddeddoc.wiki
215	[edtf]: ./embeddeddoc.wiki#th1
216	[hfed]: ./embeddeddoc.wiki#html
217
218
219	## <a name="serving"></a>Serving Files Within the Limits
220
221	There are several ways to serve files within the above restrictions,
222	avoiding the need to [override the default CSP](#override). In
223	decreasing order of simplicity and preference:
224
	@@ -305,11 +305,11 @@
305	[uu]: /help?cmd=/uv
306	[uv]: ./unvers.wiki
307	[wiki]: ./wikitheory.wiki
308
309
310	## <a name="override"></a>Overriding the Default CSP
311
312	If you wish to relax the default CSP’s restrictions or to tighten them
313	further, there are multiple ways to accomplish that.
314
315	The following methods are listed in top-down order to give the simplest
	@@ -316,11 +316,11 @@
316	and most straightforward method first. Further methods dig down deeper
317	into the stack, which is helpful to understand even if you end up using
318	a higher-level method.
319
320
321	### <a name="cspsetting"></a>The `default-csp` Setting
322
323	If the [`default-csp` setting](/help?cmd=default-csp) is defined and is
324	not an empty string, its value is injected into the page using
325	[TH1](./th1.md) via one or more of the methods below, depending on the
326	skin you’re using and local configuration.
	@@ -355,11 +355,11 @@
355	your desired CSP via the command line. Setting it via the web UI
356	doesn’t have this problem.
357
358
359
360	### <a name="th1"></a>TH1 Setup Hook
361
362	Fossil sets [the TH1 variable `$default_csp`][thvar] from the
363	`default-csp` setting and uses that to inject the value into generated
364	HTML pages in its stock configuration.
365
	@@ -373,11 +373,11 @@
373
374	[thvar]: ./customskin.md#vars
375
376
377
378	### <a name="csrc"></a>Fossil C Source Code
379
380	When you do neither of the above things, Fossil uses
381	[a hard-coded default](/info?ln=527-530&name=65a555d0d4fb846b).
382
383	We tell you about this not to suggest that you hack the Fossil C source
	@@ -384,11 +384,11 @@
384	code to change the CSP but simply to document the next step before we
385	move down-stack.
386
387
388
389	### <a name="header"></a>Skin Header
390
391	[In the normal case](./customskin.md#override), Fossil injects the CSP
392	retrieved by one of the above methods into the header of all HTML
393	documents it generates:
394
	@@ -445,11 +445,11 @@
445	independently of the skin.
446
447	[dcinj]: /info?ln=7&name=bef080a6929a3e6f
448
449
450	### <a name="fep"></a>Front-End Proxy
451
452	If your Fossil repo is behind some sort of HTTP [front-end proxy][svr],
453	the [preferred method][pmcsp] for setting the CSP is via a custom HTTP
454	header, which most HTTP reverse proxy programs allow.
455
456

	--- www/defcsp.md
	+++ www/defcsp.md
	@@ -40,11 +40,11 @@
40	default-src *;
41	</pre>
42
43	The following sections detail the maining of the default CSP setting.
44
45	### <a id="base"></a> default-src 'self' data:
46
47	This policy means mixed-origin content isn’t allowed, so you can’t refer
48	to resources on other web domains. Browsers will ignore a link like the
49	one in the following Markdown under our default CSP:
50
	@@ -77,11 +77,11 @@
77
78	[b64]: https://en.wikipedia.org/wiki/Base64
79	[svr]: ./server/
80
81
82	### <a id="img"></a> img-src * data:
83
84	As of Fossil 2.15, we don’t restrict the source of inline images at all.
85	You can pull them in from remote systems as well as pull them from
86	within the Fossil repository itself, or use `data:` URIs.
87
	@@ -90,11 +90,11 @@
90	decoders, system dialog box spoofing, etc. — by changing this to
91	“`img-src 'self'`” possibly followed by “`data:`” if you will also use
92	`data:` URIs.
93
94
95	### <a id="style"></a> style-src 'self' 'unsafe-inline'
96
97	This policy allows CSS information to come from separate files hosted
98	under the Fossil repo server’s Internet domain. It also allows inline CSS
99	`<style>` tags within the document text.
100
	@@ -111,11 +111,11 @@
111	less than the harm possible with injected javascript. And so the
112	`'unsafe-inline'` compromise is accepted for now, though it might
113	go away in some future release of Fossil.
114
115
116	### <a id="script"></a> script-src 'self' 'nonce-%s'
117
118	This policy disables in-line JavaScript and only allows `<script>`
119	elements if the `<script>` includes a `nonce` attribute that matches the
120	one declared by the CSP. That nonce is a large random number, unique for
121	each HTTP page generated by Fossil, so an attacker cannot guess the
	@@ -154,11 +154,11 @@
154
155	[ext]: ./serverext.wiki
156	[su]: ./caps/admin-v-setup.md#apsu
157
158
159	#### <a id="xss"></a>Cross-Site Scripting via Ordinary User Capabilities
160
161	We’re so restrictive about how we treat JavaScript because it can lead
162	to difficult-to-avoid scripting attacks. If we used the same CSP for
163	`<script>` tags [as for `<style>` tags](#style), anyone with check-in
164	rights on your repository could add a JavaScript file to your repository
	@@ -214,11 +214,11 @@
214	[ed]: ./embeddeddoc.wiki
215	[edtf]: ./embeddeddoc.wiki#th1
216	[hfed]: ./embeddeddoc.wiki#html
217
218
219	## <a id="serving"></a>Serving Files Within the Limits
220
221	There are several ways to serve files within the above restrictions,
222	avoiding the need to [override the default CSP](#override). In
223	decreasing order of simplicity and preference:
224
	@@ -305,11 +305,11 @@
305	[uu]: /help?cmd=/uv
306	[uv]: ./unvers.wiki
307	[wiki]: ./wikitheory.wiki
308
309
310	## <a id="override"></a>Overriding the Default CSP
311
312	If you wish to relax the default CSP’s restrictions or to tighten them
313	further, there are multiple ways to accomplish that.
314
315	The following methods are listed in top-down order to give the simplest
	@@ -316,11 +316,11 @@
316	and most straightforward method first. Further methods dig down deeper
317	into the stack, which is helpful to understand even if you end up using
318	a higher-level method.
319
320
321	### <a id="cspsetting"></a>The `default-csp` Setting
322
323	If the [`default-csp` setting](/help?cmd=default-csp) is defined and is
324	not an empty string, its value is injected into the page using
325	[TH1](./th1.md) via one or more of the methods below, depending on the
326	skin you’re using and local configuration.
	@@ -355,11 +355,11 @@
355	your desired CSP via the command line. Setting it via the web UI
356	doesn’t have this problem.
357
358
359
360	### <a id="th1"></a>TH1 Setup Hook
361
362	Fossil sets [the TH1 variable `$default_csp`][thvar] from the
363	`default-csp` setting and uses that to inject the value into generated
364	HTML pages in its stock configuration.
365
	@@ -373,11 +373,11 @@
373
374	[thvar]: ./customskin.md#vars
375
376
377
378	### <a id="csrc"></a>Fossil C Source Code
379
380	When you do neither of the above things, Fossil uses
381	[a hard-coded default](/info?ln=527-530&name=65a555d0d4fb846b).
382
383	We tell you about this not to suggest that you hack the Fossil C source
	@@ -384,11 +384,11 @@
384	code to change the CSP but simply to document the next step before we
385	move down-stack.
386
387
388
389	### <a id="header"></a>Skin Header
390
391	[In the normal case](./customskin.md#override), Fossil injects the CSP
392	retrieved by one of the above methods into the header of all HTML
393	documents it generates:
394
	@@ -445,11 +445,11 @@
445	independently of the skin.
446
447	[dcinj]: /info?ln=7&name=bef080a6929a3e6f
448
449
450	### <a id="fep"></a>Front-End Proxy
451
452	If your Fossil repo is behind some sort of HTTP [front-end proxy][svr],
453	the [preferred method][pmcsp] for setting the CSP is via a custom HTTP
454	header, which most HTTP reverse proxy programs allow.
455
456

M www/delta_encoder_algorithm.wiki

+8 -8

		--- www/delta_encoder_algorithm.wiki
		+++ www/delta_encoder_algorithm.wiki
		@@ -17,11 +17,11 @@
17	17	</p>
18	18
19	19	<p>The algorithm is inspired
20	20	by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p>
21	21
22		-<a name="argresparam"></a><h2>1.0 Arguments, Results, and Parameters</h2>
	22	+<h2 id="argresparam">1.0 Arguments, Results, and Parameters</h2>
23	23
24	24	<p>The encoder takes two byte-sequences as input, the "original", and
25	25	the "target", and returns a single byte-sequence containing the
26	26	"delta" which transforms the original into the target upon its
27	27	application.</p>
		@@ -33,11 +33,11 @@
33	33	"sliding window" for the "rolling hash", in bytes. These two terms are
34	34	explained in the next section. The value of this parameter has to be a
35	35	power of two for the algorithm to work. For Fossil the value of this
36	36	parameter is set to "16".</p>
37	37
38		-<a name="operation"></a><h2>2.0 Operation</h2>
	38	+<h2 id="operation">2.0 Operation</h2>
39	39
40	40	<p>The algorithm is split into three phases which generate
41	41	the <a href="delta_format.wiki#header">header</a>,
42	42	<a href="delta_format.wiki#slist">segment list</a>,
43	43	and <a href="delta_format.wiki#trailer">trailer</a> of the delta, per
		@@ -50,11 +50,11 @@
50	50	<p>This leaves the segment-list. Its generation is done in two phases,
51	51	a pre-processing step operating on the "original" byte-sequence,
52	52	followed by the processing of the "target" byte-sequence using the
53	53	information gathered by the first step.</p>
54	54
55		-<a name="preprocessing"></a><h3>2.1 Preprocessing the original</h3>
	55	+<h3 id="preprocessing">2.1 Preprocessing the original</h3>
56	56
57	57	<p>A major part of the processing of the "target" is to find a range
58	58	in the "original" which contains the same content as found at the
59	59	current location in the "target".</p>
60	60
		@@ -83,11 +83,11 @@
83	83	<li>A hash table is filled, mapping from the hashes of the chunks to
84	84	the list of chunk locations having this hash.
85	85	</li>
86	86	</ol>
87	87
88		-<a name="processing"></a><h3>2.1 Processing the target</h3>
	88	+<h3 id="processing">2.1 Processing the target</h3>
89	89
90	90	<p>This, the main phase of the encoder, processes the target in a loop
91	91	from beginning to end. The state of the encoder is captured by two
92	92	locations, the "base" and the "slide". "base" points to the first byte
93	93	of the target for which no delta output has been generated yet, and
		@@ -194,29 +194,29 @@
194	194	<p>If the processing loop left bytes unencoded, i.e. "base" not
195	195	exactly at the end of the "target", as is possible for both end
196	196	conditions, then one last insert instruction is emitted to put these
197	197	bytes into the delta.<p>
198	198
199		-<a name="exceptions"></a><h2>3.0 Exceptions</h2>
	199	+<h2 id="exceptions">3.0 Exceptions</h2>
200	200
201	201	<p>If the "original" is at most NHASH bytes long no compression of
202	202	changes is possible, and the segment-list of the delta consists of a
203	203	single literal which contains the entire "target".</p>
204	204
205	205	<p>This is actually equivalent to the second end condition of the
206	206	processing loop described in the previous section, just checked before
207	207	actually entering the loop.</p>
208	208
209		-<a name="rollhash"></a><h2>4.0 The rolling hash</h2>
	209	+<h2 id="rollhash">4.0 The rolling hash</h2>
210	210
211	211	<p>The rolling hash described below and used to compute content
212	212	signatures was chosen not only for good hashing properties, but also
213	213	to enable the easy (incremental) recalculation of its value for a
214	214	sliding window, i.e. where the oldest byte is removed from the window
215	215	and a new byte is shifted in.<p>
216	216
217		-<a name="rhdef"></a><h3>4.1 Definition</h3>
	217	+<h3 id="rhdef">4.1 Definition</h3>
218	218
219	219	<p>Assuming an array Z of NHASH bytes (indexing starting at 0) the
220	220	hash V is computed via</p>
221	221
222	222	<p align=center><table><tr><td>
		@@ -226,11 +226,11 @@
226	226	</td></tr></table></p>
227	227
228	228	where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and
229	229	V is a 32-bit unsigned integer with B as MSB, A as LSB.
230	230
231		-<a name="rhincr"></a><h3>4.2 Incremental recalculation</h3>
	231	+<h3 id="rhincr">4.2 Incremental recalculation</h3>
232	232
233	233	<p>Assuming an array Z of NHASH bytes (indexing starting at 0) with
234	234	hash V (and components A and B), the dropped
235	235	byte <img src="encode4.gif" align="center">, and the new byte
236	236	<img src="encode5.gif" align="center"> , the new hash can
237	237

	--- www/delta_encoder_algorithm.wiki
	+++ www/delta_encoder_algorithm.wiki
	@@ -17,11 +17,11 @@
17	</p>
18
19	<p>The algorithm is inspired
20	by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p>
21
22	<a name="argresparam"></a><h2>1.0 Arguments, Results, and Parameters</h2>
23
24	<p>The encoder takes two byte-sequences as input, the "original", and
25	the "target", and returns a single byte-sequence containing the
26	"delta" which transforms the original into the target upon its
27	application.</p>
	@@ -33,11 +33,11 @@
33	"sliding window" for the "rolling hash", in bytes. These two terms are
34	explained in the next section. The value of this parameter has to be a
35	power of two for the algorithm to work. For Fossil the value of this
36	parameter is set to "16".</p>
37
38	<a name="operation"></a><h2>2.0 Operation</h2>
39
40	<p>The algorithm is split into three phases which generate
41	the <a href="delta_format.wiki#header">header</a>,
42	<a href="delta_format.wiki#slist">segment list</a>,
43	and <a href="delta_format.wiki#trailer">trailer</a> of the delta, per
	@@ -50,11 +50,11 @@
50	<p>This leaves the segment-list. Its generation is done in two phases,
51	a pre-processing step operating on the "original" byte-sequence,
52	followed by the processing of the "target" byte-sequence using the
53	information gathered by the first step.</p>
54
55	<a name="preprocessing"></a><h3>2.1 Preprocessing the original</h3>
56
57	<p>A major part of the processing of the "target" is to find a range
58	in the "original" which contains the same content as found at the
59	current location in the "target".</p>
60
	@@ -83,11 +83,11 @@
83	<li>A hash table is filled, mapping from the hashes of the chunks to
84	the list of chunk locations having this hash.
85	</li>
86	</ol>
87
88	<a name="processing"></a><h3>2.1 Processing the target</h3>
89
90	<p>This, the main phase of the encoder, processes the target in a loop
91	from beginning to end. The state of the encoder is captured by two
92	locations, the "base" and the "slide". "base" points to the first byte
93	of the target for which no delta output has been generated yet, and
	@@ -194,29 +194,29 @@
194	<p>If the processing loop left bytes unencoded, i.e. "base" not
195	exactly at the end of the "target", as is possible for both end
196	conditions, then one last insert instruction is emitted to put these
197	bytes into the delta.<p>
198
199	<a name="exceptions"></a><h2>3.0 Exceptions</h2>
200
201	<p>If the "original" is at most NHASH bytes long no compression of
202	changes is possible, and the segment-list of the delta consists of a
203	single literal which contains the entire "target".</p>
204
205	<p>This is actually equivalent to the second end condition of the
206	processing loop described in the previous section, just checked before
207	actually entering the loop.</p>
208
209	<a name="rollhash"></a><h2>4.0 The rolling hash</h2>
210
211	<p>The rolling hash described below and used to compute content
212	signatures was chosen not only for good hashing properties, but also
213	to enable the easy (incremental) recalculation of its value for a
214	sliding window, i.e. where the oldest byte is removed from the window
215	and a new byte is shifted in.<p>
216
217	<a name="rhdef"></a><h3>4.1 Definition</h3>
218
219	<p>Assuming an array Z of NHASH bytes (indexing starting at 0) the
220	hash V is computed via</p>
221
222	<p align=center><table><tr><td>
	@@ -226,11 +226,11 @@
226	</td></tr></table></p>
227
228	where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and
229	V is a 32-bit unsigned integer with B as MSB, A as LSB.
230
231	<a name="rhincr"></a><h3>4.2 Incremental recalculation</h3>
232
233	<p>Assuming an array Z of NHASH bytes (indexing starting at 0) with
234	hash V (and components A and B), the dropped
235	byte <img src="encode4.gif" align="center">, and the new byte
236	<img src="encode5.gif" align="center"> , the new hash can
237

	--- www/delta_encoder_algorithm.wiki
	+++ www/delta_encoder_algorithm.wiki
	@@ -17,11 +17,11 @@
17	</p>
18
19	<p>The algorithm is inspired
20	by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p>
21
22	<h2 id="argresparam">1.0 Arguments, Results, and Parameters</h2>
23
24	<p>The encoder takes two byte-sequences as input, the "original", and
25	the "target", and returns a single byte-sequence containing the
26	"delta" which transforms the original into the target upon its
27	application.</p>
	@@ -33,11 +33,11 @@
33	"sliding window" for the "rolling hash", in bytes. These two terms are
34	explained in the next section. The value of this parameter has to be a
35	power of two for the algorithm to work. For Fossil the value of this
36	parameter is set to "16".</p>
37
38	<h2 id="operation">2.0 Operation</h2>
39
40	<p>The algorithm is split into three phases which generate
41	the <a href="delta_format.wiki#header">header</a>,
42	<a href="delta_format.wiki#slist">segment list</a>,
43	and <a href="delta_format.wiki#trailer">trailer</a> of the delta, per
	@@ -50,11 +50,11 @@
50	<p>This leaves the segment-list. Its generation is done in two phases,
51	a pre-processing step operating on the "original" byte-sequence,
52	followed by the processing of the "target" byte-sequence using the
53	information gathered by the first step.</p>
54
55	<h3 id="preprocessing">2.1 Preprocessing the original</h3>
56
57	<p>A major part of the processing of the "target" is to find a range
58	in the "original" which contains the same content as found at the
59	current location in the "target".</p>
60
	@@ -83,11 +83,11 @@
83	<li>A hash table is filled, mapping from the hashes of the chunks to
84	the list of chunk locations having this hash.
85	</li>
86	</ol>
87
88	<h3 id="processing">2.1 Processing the target</h3>
89
90	<p>This, the main phase of the encoder, processes the target in a loop
91	from beginning to end. The state of the encoder is captured by two
92	locations, the "base" and the "slide". "base" points to the first byte
93	of the target for which no delta output has been generated yet, and
	@@ -194,29 +194,29 @@
194	<p>If the processing loop left bytes unencoded, i.e. "base" not
195	exactly at the end of the "target", as is possible for both end
196	conditions, then one last insert instruction is emitted to put these
197	bytes into the delta.<p>
198
199	<h2 id="exceptions">3.0 Exceptions</h2>
200
201	<p>If the "original" is at most NHASH bytes long no compression of
202	changes is possible, and the segment-list of the delta consists of a
203	single literal which contains the entire "target".</p>
204
205	<p>This is actually equivalent to the second end condition of the
206	processing loop described in the previous section, just checked before
207	actually entering the loop.</p>
208
209	<h2 id="rollhash">4.0 The rolling hash</h2>
210
211	<p>The rolling hash described below and used to compute content
212	signatures was chosen not only for good hashing properties, but also
213	to enable the easy (incremental) recalculation of its value for a
214	sliding window, i.e. where the oldest byte is removed from the window
215	and a new byte is shifted in.<p>
216
217	<h3 id="rhdef">4.1 Definition</h3>
218
219	<p>Assuming an array Z of NHASH bytes (indexing starting at 0) the
220	hash V is computed via</p>
221
222	<p align=center><table><tr><td>
	@@ -226,11 +226,11 @@
226	</td></tr></table></p>
227
228	where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and
229	V is a 32-bit unsigned integer with B as MSB, A as LSB.
230
231	<h3 id="rhincr">4.2 Incremental recalculation</h3>
232
233	<p>Assuming an array Z of NHASH bytes (indexing starting at 0) with
234	hash V (and components A and B), the dropped
235	byte <img src="encode4.gif" align="center">, and the new byte
236	<img src="encode5.gif" align="center"> , the new hash can
237

M www/delta_format.wiki

+11 -11

		--- www/delta_format.wiki
		+++ www/delta_format.wiki
		@@ -60,11 +60,11 @@
60	60	* <b>delta_parse(</b><i>D</i>)</b> → This is a table-valued function
61	61	that returns one row for the header, for the trailer, and for each segment
62	62	in delta D.
63	63
64	64
65		-<a name="structure"></a><h1>2.0 Structure</h1>
	65	+<h1 id="structure">2.0 Structure</h1>
66	66	<verbatim type="pikchr">
67	67	leftmargin = 0.1
68	68	box height 50% "Header"
69	69	box same "Segments"
70	70	box same "Trailer"
		@@ -75,11 +75,11 @@
75	75
76	76	<p>Both header and trailer provide information about the target
77	77	helping the decoder, and the segment-list describes how the target can
78	78	be constructed from the original.</p>
79	79
80		-<a name="header"></a><h2>2.1 Header</h2>
	80	+<h2 id="header">2.1 Header</h2>
81	81	<verbatim type="pikchr">
82	82	leftmargin = 0.1
83	83	box height 50% "Size"
84	84	box same "\"\\n\""
85	85	</verbatim>
		@@ -91,11 +91,11 @@
91	91	<p>This means that, given a delta, the decoder can compute the size of
92	92	the target (and allocate any necessary memory based on that) by simply
93	93	reading the first line of the delta and decoding the number found
94	94	there. In other words, before it has to decode everything else.</p>
95	95
96		-<a name="trailer"></a><h2>2.2 Trailer</h2>
	96	+<h2 id="trailer">2.2 Trailer</h2>
97	97	<verbatim type="pikchr">
98	98	leftmargin = 0.1
99	99	box height 50% "Checksum"
100	100	box same "\";\""
101	101	</verbatim>
		@@ -112,11 +112,11 @@
112	112
113	113	<p>By putting this information at the end of the delta a decoder has
114	114	it available immediately after the target has been reconstructed
115	115	fully.</p>
116	116
117		-<a name="slist"></a><h2>2.3 Segment-List</h2>
	117	+<h2 id="slist">2.3 Segment-List</h2>
118	118	<verbatim type="pikchr">
119	119	leftmargin = 0.1
120	120	PART1: [
121	121	B1: box height 50% width 15% ""
122	122	B2: box same ""
		@@ -148,11 +148,11 @@
148	148
149	149	<p>The target is constructed from beginning to end, with the data
150	150	generated by each instruction appended after the data of all previous
151	151	instructions, with no gaps.</p>
152	152
153		-<a name="insertlit"></a><h3>2.3.1 Insert Literal</h3>
	153	+<h3 id="insertlit">2.3.1 Insert Literal</h3>
154	154
155	155	<p>A literal is specified by two elements, the size of the literal in
156	156	bytes, and the bytes of the literal itself.</p>
157	157
158	158	<verbatim type="pikchr">
		@@ -163,11 +163,11 @@
163	163	</verbatim>
164	164
165	165	<p>The length is written first, followed by a colon character (ASCII
166	166	0x3a), followed by the bytes of the literal.</p>
167	167
168		-<a name="copyrange"></a><h3>2.3.2 Copy Range</h3>
	168	+<h3 id="copyrange">2.3.2 Copy Range</h3>
169	169
170	170	<p>A range to copy is specified by two numbers, the offset of the
171	171	first byte in the original to copy, and the size of the range, in
172	172	bytes. The size zero is special, its usage indicates that the range
173	173	extends to the end of the original.</p>
		@@ -182,11 +182,11 @@
182	182
183	183
184	184	<p>The length is written first, followed by an "at" character (ASCII
185	185	0x40), then the offset, followed by a comma (ASCII 0x2c).</p>
186	186
187		-<a name="intcoding"></a><h1>3.0 Encoding of integers</h1>
	187	+<h1 id="intcoding">3.0 Encoding of integers</h1>
188	188
189	189	<p>
190	190	The format currently handles only 32 bit integer numbers. They are
191	191	written base-64 encoded, MSB first, and without leading
192	192	"0"-characters, except if they are significant (i.e. 0 => "0").
		@@ -207,13 +207,13 @@
207	207	are encoded. The minimum number of encoding characters is used.
208	208	Note that for integers less than 10, the base-64 coding is a
209	209	ASCII decimal rendering of the number itself.
210	210	</p>
211	211
212		-<a name="examples"></a><h1>4.0 Examples</h1>
	212	+<h1 id="examples">4.0 Examples</h1>
213	213
214		-<a name="examplesint"></a><h2>4.1 Integer encoding</h2>
	214	+<h2 id="examplesint">4.1 Integer encoding</h2>
215	215
216	216	<table border=1>
217	217	<tr>
218	218	<th>Value</th>
219	219	<th>Encoding</th>
		@@ -230,11 +230,11 @@
230	230	<td>-1101438770</td>
231	231	<td>2zMM3E</td>
232	232	</tr>
233	233	</table>
234	234
235		-<a name="examplesdelta"></a><h2>4.2 Delta encoding</h2>
	235	+<h2 id="examplesdelta">4.2 Delta encoding</h2>
236	236
237	237	<p>An example of a delta using the specified encoding is:</p>
238	238
239	239	<table border=1><tr><td><pre>
240	240	1Xb
		@@ -306,11 +306,11 @@
306	306
307	307	</pre></td></tr></table>
308	308
309	309
310	310
311		-<a name="notes"></a><h1>Notes</h1>
	311	+<h1 id="notes">Notes</h1>
312	312
313	313	<ul>
314	314	<li>Pure text files generate a pure text delta.
315	315	</li>
316	316	<li>Binary files generate a delta that may contain some binary data.
317	317

	--- www/delta_format.wiki
	+++ www/delta_format.wiki
	@@ -60,11 +60,11 @@
60	* <b>delta_parse(</b><i>D</i>)</b> → This is a table-valued function
61	that returns one row for the header, for the trailer, and for each segment
62	in delta D.
63
64
65	<a name="structure"></a><h1>2.0 Structure</h1>
66	<verbatim type="pikchr">
67	leftmargin = 0.1
68	box height 50% "Header"
69	box same "Segments"
70	box same "Trailer"
	@@ -75,11 +75,11 @@
75
76	<p>Both header and trailer provide information about the target
77	helping the decoder, and the segment-list describes how the target can
78	be constructed from the original.</p>
79
80	<a name="header"></a><h2>2.1 Header</h2>
81	<verbatim type="pikchr">
82	leftmargin = 0.1
83	box height 50% "Size"
84	box same "\"\\n\""
85	</verbatim>
	@@ -91,11 +91,11 @@
91	<p>This means that, given a delta, the decoder can compute the size of
92	the target (and allocate any necessary memory based on that) by simply
93	reading the first line of the delta and decoding the number found
94	there. In other words, before it has to decode everything else.</p>
95
96	<a name="trailer"></a><h2>2.2 Trailer</h2>
97	<verbatim type="pikchr">
98	leftmargin = 0.1
99	box height 50% "Checksum"
100	box same "\";\""
101	</verbatim>
	@@ -112,11 +112,11 @@
112
113	<p>By putting this information at the end of the delta a decoder has
114	it available immediately after the target has been reconstructed
115	fully.</p>
116
117	<a name="slist"></a><h2>2.3 Segment-List</h2>
118	<verbatim type="pikchr">
119	leftmargin = 0.1
120	PART1: [
121	B1: box height 50% width 15% ""
122	B2: box same ""
	@@ -148,11 +148,11 @@
148
149	<p>The target is constructed from beginning to end, with the data
150	generated by each instruction appended after the data of all previous
151	instructions, with no gaps.</p>
152
153	<a name="insertlit"></a><h3>2.3.1 Insert Literal</h3>
154
155	<p>A literal is specified by two elements, the size of the literal in
156	bytes, and the bytes of the literal itself.</p>
157
158	<verbatim type="pikchr">
	@@ -163,11 +163,11 @@
163	</verbatim>
164
165	<p>The length is written first, followed by a colon character (ASCII
166	0x3a), followed by the bytes of the literal.</p>
167
168	<a name="copyrange"></a><h3>2.3.2 Copy Range</h3>
169
170	<p>A range to copy is specified by two numbers, the offset of the
171	first byte in the original to copy, and the size of the range, in
172	bytes. The size zero is special, its usage indicates that the range
173	extends to the end of the original.</p>
	@@ -182,11 +182,11 @@
182
183
184	<p>The length is written first, followed by an "at" character (ASCII
185	0x40), then the offset, followed by a comma (ASCII 0x2c).</p>
186
187	<a name="intcoding"></a><h1>3.0 Encoding of integers</h1>
188
189	<p>
190	The format currently handles only 32 bit integer numbers. They are
191	written base-64 encoded, MSB first, and without leading
192	"0"-characters, except if they are significant (i.e. 0 => "0").
	@@ -207,13 +207,13 @@
207	are encoded. The minimum number of encoding characters is used.
208	Note that for integers less than 10, the base-64 coding is a
209	ASCII decimal rendering of the number itself.
210	</p>
211
212	<a name="examples"></a><h1>4.0 Examples</h1>
213
214	<a name="examplesint"></a><h2>4.1 Integer encoding</h2>
215
216	<table border=1>
217	<tr>
218	<th>Value</th>
219	<th>Encoding</th>
	@@ -230,11 +230,11 @@
230	<td>-1101438770</td>
231	<td>2zMM3E</td>
232	</tr>
233	</table>
234
235	<a name="examplesdelta"></a><h2>4.2 Delta encoding</h2>
236
237	<p>An example of a delta using the specified encoding is:</p>
238
239	<table border=1><tr><td><pre>
240	1Xb
	@@ -306,11 +306,11 @@
306
307	</pre></td></tr></table>
308
309
310
311	<a name="notes"></a><h1>Notes</h1>
312
313	<ul>
314	<li>Pure text files generate a pure text delta.
315	</li>
316	<li>Binary files generate a delta that may contain some binary data.
317

	--- www/delta_format.wiki
	+++ www/delta_format.wiki
	@@ -60,11 +60,11 @@
60	* <b>delta_parse(</b><i>D</i>)</b> → This is a table-valued function
61	that returns one row for the header, for the trailer, and for each segment
62	in delta D.
63
64
65	<h1 id="structure">2.0 Structure</h1>
66	<verbatim type="pikchr">
67	leftmargin = 0.1
68	box height 50% "Header"
69	box same "Segments"
70	box same "Trailer"
	@@ -75,11 +75,11 @@
75
76	<p>Both header and trailer provide information about the target
77	helping the decoder, and the segment-list describes how the target can
78	be constructed from the original.</p>
79
80	<h2 id="header">2.1 Header</h2>
81	<verbatim type="pikchr">
82	leftmargin = 0.1
83	box height 50% "Size"
84	box same "\"\\n\""
85	</verbatim>
	@@ -91,11 +91,11 @@
91	<p>This means that, given a delta, the decoder can compute the size of
92	the target (and allocate any necessary memory based on that) by simply
93	reading the first line of the delta and decoding the number found
94	there. In other words, before it has to decode everything else.</p>
95
96	<h2 id="trailer">2.2 Trailer</h2>
97	<verbatim type="pikchr">
98	leftmargin = 0.1
99	box height 50% "Checksum"
100	box same "\";\""
101	</verbatim>
	@@ -112,11 +112,11 @@
112
113	<p>By putting this information at the end of the delta a decoder has
114	it available immediately after the target has been reconstructed
115	fully.</p>
116
117	<h2 id="slist">2.3 Segment-List</h2>
118	<verbatim type="pikchr">
119	leftmargin = 0.1
120	PART1: [
121	B1: box height 50% width 15% ""
122	B2: box same ""
	@@ -148,11 +148,11 @@
148
149	<p>The target is constructed from beginning to end, with the data
150	generated by each instruction appended after the data of all previous
151	instructions, with no gaps.</p>
152
153	<h3 id="insertlit">2.3.1 Insert Literal</h3>
154
155	<p>A literal is specified by two elements, the size of the literal in
156	bytes, and the bytes of the literal itself.</p>
157
158	<verbatim type="pikchr">
	@@ -163,11 +163,11 @@
163	</verbatim>
164
165	<p>The length is written first, followed by a colon character (ASCII
166	0x3a), followed by the bytes of the literal.</p>
167
168	<h3 id="copyrange">2.3.2 Copy Range</h3>
169
170	<p>A range to copy is specified by two numbers, the offset of the
171	first byte in the original to copy, and the size of the range, in
172	bytes. The size zero is special, its usage indicates that the range
173	extends to the end of the original.</p>
	@@ -182,11 +182,11 @@
182
183
184	<p>The length is written first, followed by an "at" character (ASCII
185	0x40), then the offset, followed by a comma (ASCII 0x2c).</p>
186
187	<h1 id="intcoding">3.0 Encoding of integers</h1>
188
189	<p>
190	The format currently handles only 32 bit integer numbers. They are
191	written base-64 encoded, MSB first, and without leading
192	"0"-characters, except if they are significant (i.e. 0 => "0").
	@@ -207,13 +207,13 @@
207	are encoded. The minimum number of encoding characters is used.
208	Note that for integers less than 10, the base-64 coding is a
209	ASCII decimal rendering of the number itself.
210	</p>
211
212	<h1 id="examples">4.0 Examples</h1>
213
214	<h2 id="examplesint">4.1 Integer encoding</h2>
215
216	<table border=1>
217	<tr>
218	<th>Value</th>
219	<th>Encoding</th>
	@@ -230,11 +230,11 @@
230	<td>-1101438770</td>
231	<td>2zMM3E</td>
232	</tr>
233	</table>
234
235	<h2 id="examplesdelta">4.2 Delta encoding</h2>
236
237	<p>An example of a delta using the specified encoding is:</p>
238
239	<table border=1><tr><td><pre>
240	1Xb
	@@ -306,11 +306,11 @@
306
307	</pre></td></tr></table>
308
309
310
311	<h1 id="notes">Notes</h1>
312
313	<ul>
314	<li>Pure text files generate a pure text delta.
315	</li>
316	<li>Binary files generate a delta that may contain some binary data.
317

M www/embeddeddoc.wiki

+3 -3

		--- www/embeddeddoc.wiki
		+++ www/embeddeddoc.wiki
		@@ -48,11 +48,11 @@
48	48	that contains the embedded document. This might be a hash prefix for
49	49	the check-in, or it might be the name of a branch or tag, or it might
50	50	be a timestamp. See the prior link
51	51	for more possibilities and examples.
52	52
53		-<a id="ckout"></a>The <i><version></i> can
	53	+The <i id="ckout"><version></i> can
54	54	also be the special identifier "<b>ckout</b>".
55	55	The "<b>ckout</b>" keywords means to
56	56	pull the documentation file from the local source tree on disk, not
57	57	from the any check-in. The "<b>ckout</b>" keyword
58	58	only works when you start your server using the
		@@ -98,13 +98,13 @@
98	98	Wiki, markdown, and plain text documentation files
99	99	are rendered with the standard fossil header and footer added.
100	100	Most other mimetypes are delivered directly to the requesting
101	101	web browser without interpretation, additions, or changes.
102	102
103		-<h2>1.1 HTML Rendering With Fossil Headers And Footers</h2>
	103	+<h2 id="html">1.1 HTML Rendering With Fossil Headers And Footers</h2>
104	104
105		-<a name="html"></a>Files with the mimetype "text/html" (the .html or .htm suffix) are
	105	+Files with the mimetype "text/html" (the .html or .htm suffix) are
106	106	usually rendered directly to the browser without interpretation.
107	107	However, if the file begins with a <div> element like this:
108	108
109	109	<b><div class='fossil-doc' data-title='<i>Title Text</i>'></b>
110	110
111	111

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -48,11 +48,11 @@
48	that contains the embedded document. This might be a hash prefix for
49	the check-in, or it might be the name of a branch or tag, or it might
50	be a timestamp. See the prior link
51	for more possibilities and examples.
52
53	<a id="ckout"></a>The <i><version></i> can
54	also be the special identifier "<b>ckout</b>".
55	The "<b>ckout</b>" keywords means to
56	pull the documentation file from the local source tree on disk, not
57	from the any check-in. The "<b>ckout</b>" keyword
58	only works when you start your server using the
	@@ -98,13 +98,13 @@
98	Wiki, markdown, and plain text documentation files
99	are rendered with the standard fossil header and footer added.
100	Most other mimetypes are delivered directly to the requesting
101	web browser without interpretation, additions, or changes.
102
103	<h2>1.1 HTML Rendering With Fossil Headers And Footers</h2>
104
105	<a name="html"></a>Files with the mimetype "text/html" (the .html or .htm suffix) are
106	usually rendered directly to the browser without interpretation.
107	However, if the file begins with a <div> element like this:
108
109	<b><div class='fossil-doc' data-title='<i>Title Text</i>'></b>
110
111

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -48,11 +48,11 @@
48	that contains the embedded document. This might be a hash prefix for
49	the check-in, or it might be the name of a branch or tag, or it might
50	be a timestamp. See the prior link
51	for more possibilities and examples.
52
53	The <i id="ckout"><version></i> can
54	also be the special identifier "<b>ckout</b>".
55	The "<b>ckout</b>" keywords means to
56	pull the documentation file from the local source tree on disk, not
57	from the any check-in. The "<b>ckout</b>" keyword
58	only works when you start your server using the
	@@ -98,13 +98,13 @@
98	Wiki, markdown, and plain text documentation files
99	are rendered with the standard fossil header and footer added.
100	Most other mimetypes are delivered directly to the requesting
101	web browser without interpretation, additions, or changes.
102
103	<h2 id="html">1.1 HTML Rendering With Fossil Headers And Footers</h2>
104
105	Files with the mimetype "text/html" (the .html or .htm suffix) are
106	usually rendered directly to the browser without interpretation.
107	However, if the file begins with a <div> element like this:
108
109	<b><div class='fossil-doc' data-title='<i>Title Text</i>'></b>
110
111

M www/env-opts.md

+1 -1

		--- www/env-opts.md
		+++ www/env-opts.md
		@@ -417,11 +417,11 @@
417	417	can be selected with either the `--vfs VFSNAME` option or the
418	418	`FOSSIL_VFS` environment variable. The `--vfs` option takes
419	419	precedence.
420	420
421	421
422		-### <a name="temp"></a>Temporary File Location
	422	+### <a id="temp"></a>Temporary File Location
423	423
424	424	Fossil places some temporary files in the checkout directory. Most notably,
425	425	supporting files related to merge conflicts are placed in the same
426	426	folder as the merge result.
427	427
428	428

	--- www/env-opts.md
	+++ www/env-opts.md
	@@ -417,11 +417,11 @@
417	can be selected with either the `--vfs VFSNAME` option or the
418	`FOSSIL_VFS` environment variable. The `--vfs` option takes
419	precedence.
420
421
422	### <a name="temp"></a>Temporary File Location
423
424	Fossil places some temporary files in the checkout directory. Most notably,
425	supporting files related to merge conflicts are placed in the same
426	folder as the merge result.
427
428

	--- www/env-opts.md
	+++ www/env-opts.md
	@@ -417,11 +417,11 @@
417	can be selected with either the `--vfs VFSNAME` option or the
418	`FOSSIL_VFS` environment variable. The `--vfs` option takes
419	precedence.
420
421
422	### <a id="temp"></a>Temporary File Location
423
424	Fossil places some temporary files in the checkout directory. Most notably,
425	supporting files related to merge conflicts are placed in the same
426	folder as the merge result.
427
428

M www/faq.tcl

+1 -2

		--- www/faq.tcl
		+++ www/faq.tcl
		@@ -167,12 +167,11 @@
167	167	}
168	168	puts {</ol>}
169	169	puts {<hr>}
170	170
171	171	for {set i 1} {$i<$cnt} {incr i} {
172		- puts "<a name=\"q$i\"></a>"
173		- puts "<p><b>($i) [lindex $faq($i) 0]</b></p>\n"
	172	+ puts "<p id=\"q$i\"><b>($i) [lindex $faq($i) 0]</b></p>\n"
174	173	set body [lindex $faq($i) 1]
175	174	regsub -all "\n *" [string trim $body] "\n" body
176	175	puts "<blockquote>$body</blockquote></li>\n"
177	176	}
178	177	puts {</ol>}
179	178

	--- www/faq.tcl
	+++ www/faq.tcl
	@@ -167,12 +167,11 @@
167	}
168	puts {</ol>}
169	puts {<hr>}
170
171	for {set i 1} {$i<$cnt} {incr i} {
172	puts "<a name=\"q$i\"></a>"
173	puts "<p><b>($i) [lindex $faq($i) 0]</b></p>\n"
174	set body [lindex $faq($i) 1]
175	regsub -all "\n *" [string trim $body] "\n" body
176	puts "<blockquote>$body</blockquote></li>\n"
177	}
178	puts {</ol>}
179

	--- www/faq.tcl
	+++ www/faq.tcl
	@@ -167,12 +167,11 @@
167	}
168	puts {</ol>}
169	puts {<hr>}
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

M www/faq.wiki

+10 -23

		--- www/faq.wiki
		+++ www/faq.wiki
		@@ -1,11 +1,9 @@
1	1	<title>Fossil FAQ</title>
2	2	<h1 align="center">Frequently Asked Questions</h1>
3	3
4		-<p>Note:
5		-This page is old and has not been kept up-to-date. See the
6		-[/finfo?name=www/faq.wiki\|change history of this page].</p>
	4	+<p>Note: See also <a href="qandc.wiki">Questions and Criticisms</a>.
7	5
8	6	<ol>
9	7	<li><a href="#q1">What GUIs are available for fossil?</a></li>
10	8	<li><a href="#q2">What is the difference between a "branch" and a "fork"?</a></li>
11	9	<li><a href="#q3">How do I create a new branch?</a></li>
		@@ -15,12 +13,11 @@
15	13	<li><a href="#q6">How can I delete inappropriate content from my fossil repository?</a></li>
16	14	<li><a href="#q7">How do I make a clone of the fossil self-hosting repository?</a></li>
17	15	<li><a href="#q8">How do I import or export content from and to other version control systems?</a></li>
18	16	</ol>
19	17	<hr>
20		-<a name="q1"></a>
21		-<p><b>(1) What GUIs are available for fossil?</b></p>
	18	+<p id="q1"><b>(1) What GUIs are available for fossil?</b></p>
22	19
23	20	<blockquote>The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
24	21	Just run:
25	22
26	23	<blockquote>
		@@ -27,24 +24,19 @@
27	24	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
28	25	</blockquote>
29	26
30	27	And your default web browser should pop up and automatically point to
31	28	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
32		-if you are within an open check-out.)
	29	+if you are within an open check-out.)</blockquote></li>
33	30
34		-See also: [http://fuelscm.org/]
35		-</blockquote></li>
36		-
37		-<a name="q2"></a>
38		-<p><b>(2) What is the difference between a "branch" and a "fork"?</b></p>
	31	+<p id="q2"><b>(2) What is the difference between a "branch" and a "fork"?</b></p>
39	32
40	33	<blockquote>This is a big question - too big to answer in a FAQ. Please
41	34	read the <a href="branching.wiki">Branching, Forking, Merging,
42	35	and Tagging</a> document.</blockquote></li>
43	36
44		-<a name="q3"></a>
45		-<p><b>(3) How do I create a new branch?</b></p>
	37	+<p id="q3"><b>(3) How do I create a new branch?</b></p>
46	38
47	39	<blockquote>There are lots of ways:
48	40
49	41	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
50	42	command, you can add the option "--branch <i>BRANCH-NAME</i>" to
		@@ -69,12 +61,11 @@
69	61	link (near the "Commands:" label) and click on that. On the
70	62	"Edit Check-in" page, check the box beside "Branching:" and fill in
71	63	the name of your new branch to the right and press the "Apply Changes"
72	64	button.</blockquote></li>
73	65
74		-<a name="q4"></a>
75		-<p><b>(4) How do I tag a check-in?</b></p>
	66	+<p id="q4"><b>(4) How do I tag a check-in?</b></p>
76	67
77	68	<blockquote>There are several ways:
78	69
79	70	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
80	71	command, you can add a tag to that check-in using the
		@@ -98,12 +89,11 @@
98	89	information page for that check-in. Then find the "<b>edit</b>"
99	90	link (near the "Commands:" label) and click on that. There are
100	91	controls on the edit page that allow new tags to be added and existing
101	92	tags to be removed.</blockquote></li>
102	93
103		-<a name="q5"></a>
104		-<p><b>(5) How do I create a private branch that won't get pushed back to the
	94	+<p id="q5"><b>(5) How do I create a private branch that won't get pushed back to the
105	95	main repository.</b></p>
106	96
107	97	<blockquote>Use the <b>--private</b> command-line option on the
108	98	<b>commit</b> command. The result will be a check-in which exists on
109	99	your local repository only and is never pushed to other repositories.
		@@ -123,17 +113,15 @@
123	113	Of course, you can also keep your branch private forever simply
124	114	by not merging the changes in the private branch back into the trunk.
125	115
126	116	[./private.wiki \| Additional information]</blockquote></li>
127	117
128		-<a name="q6"></a>
129		-<p><b>(6) How can I delete inappropriate content from my fossil repository?</b></p>
	118	+<p id="q6"><b>(6) How can I delete inappropriate content from my fossil repository?</b></p>
130	119
131	120	<blockquote>See the article on [./shunning.wiki \| "shunning"] for details.</blockquote></li>
132	121
133		-<a name="q7"></a>
134		-<p><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p>
	122	+<p id="q7"><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p>
135	123
136	124	<blockquote>Any of the following commands should work:
137	125	<blockquote><pre>
138	126	fossil [/help/clone\|clone] http://fossil-scm.org/ fossil.fossil
139	127	fossil [/help/clone\|clone] http://www2.fossil-scm.org/ fossil.fossil
		@@ -148,11 +136,10 @@
148	136	with the latest code in the public repository by typing:
149	137	<blockquote><pre>
150	138	fossil [/help/update\|update]
151	139	</pre></blockquote></blockquote></li>
152	140
153		-<a name="q8"></a>
154		-<p><b>(8) How do I import or export content from and to other version control systems?</b></p>
	141	+<p id="q8"><b>(8) How do I import or export content from and to other version control systems?</b></p>
155	142
156	143	<blockquote>Please see [./inout.wiki \| Import And Export]</blockquote></li>
157	144
158	145	</ol>
159	146

	--- www/faq.wiki
	+++ www/faq.wiki
	@@ -1,11 +1,9 @@
1	<title>Fossil FAQ</title>
2	<h1 align="center">Frequently Asked Questions</h1>
3
4	<p>Note:
5	This page is old and has not been kept up-to-date. See the
6	[/finfo?name=www/faq.wiki\|change history of this page].</p>
7
8	<ol>
9	<li><a href="#q1">What GUIs are available for fossil?</a></li>
10	<li><a href="#q2">What is the difference between a "branch" and a "fork"?</a></li>
11	<li><a href="#q3">How do I create a new branch?</a></li>
	@@ -15,12 +13,11 @@
15	<li><a href="#q6">How can I delete inappropriate content from my fossil repository?</a></li>
16	<li><a href="#q7">How do I make a clone of the fossil self-hosting repository?</a></li>
17	<li><a href="#q8">How do I import or export content from and to other version control systems?</a></li>
18	</ol>
19	<hr>
20	<a name="q1"></a>
21	<p><b>(1) What GUIs are available for fossil?</b></p>
22
23	<blockquote>The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
24	Just run:
25
26	<blockquote>
	@@ -27,24 +24,19 @@
27	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
28	</blockquote>
29
30	And your default web browser should pop up and automatically point to
31	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
32	if you are within an open check-out.)
33
34	See also: [http://fuelscm.org/]
35	</blockquote></li>
36
37	<a name="q2"></a>
38	<p><b>(2) What is the difference between a "branch" and a "fork"?</b></p>
39
40	<blockquote>This is a big question - too big to answer in a FAQ. Please
41	read the <a href="branching.wiki">Branching, Forking, Merging,
42	and Tagging</a> document.</blockquote></li>
43
44	<a name="q3"></a>
45	<p><b>(3) How do I create a new branch?</b></p>
46
47	<blockquote>There are lots of ways:
48
49	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
50	command, you can add the option "--branch <i>BRANCH-NAME</i>" to
	@@ -69,12 +61,11 @@
69	link (near the "Commands:" label) and click on that. On the
70	"Edit Check-in" page, check the box beside "Branching:" and fill in
71	the name of your new branch to the right and press the "Apply Changes"
72	button.</blockquote></li>
73
74	<a name="q4"></a>
75	<p><b>(4) How do I tag a check-in?</b></p>
76
77	<blockquote>There are several ways:
78
79	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
80	command, you can add a tag to that check-in using the
	@@ -98,12 +89,11 @@
98	information page for that check-in. Then find the "<b>edit</b>"
99	link (near the "Commands:" label) and click on that. There are
100	controls on the edit page that allow new tags to be added and existing
101	tags to be removed.</blockquote></li>
102
103	<a name="q5"></a>
104	<p><b>(5) How do I create a private branch that won't get pushed back to the
105	main repository.</b></p>
106
107	<blockquote>Use the <b>--private</b> command-line option on the
108	<b>commit</b> command. The result will be a check-in which exists on
109	your local repository only and is never pushed to other repositories.
	@@ -123,17 +113,15 @@
123	Of course, you can also keep your branch private forever simply
124	by not merging the changes in the private branch back into the trunk.
125
126	[./private.wiki \| Additional information]</blockquote></li>
127
128	<a name="q6"></a>
129	<p><b>(6) How can I delete inappropriate content from my fossil repository?</b></p>
130
131	<blockquote>See the article on [./shunning.wiki \| "shunning"] for details.</blockquote></li>
132
133	<a name="q7"></a>
134	<p><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p>
135
136	<blockquote>Any of the following commands should work:
137	<blockquote><pre>
138	fossil [/help/clone\|clone] http://fossil-scm.org/ fossil.fossil
139	fossil [/help/clone\|clone] http://www2.fossil-scm.org/ fossil.fossil
	@@ -148,11 +136,10 @@
148	with the latest code in the public repository by typing:
149	<blockquote><pre>
150	fossil [/help/update\|update]
151	</pre></blockquote></blockquote></li>
152
153	<a name="q8"></a>
154	<p><b>(8) How do I import or export content from and to other version control systems?</b></p>
155
156	<blockquote>Please see [./inout.wiki \| Import And Export]</blockquote></li>
157
158	</ol>
159

	--- www/faq.wiki
	+++ www/faq.wiki
	@@ -1,11 +1,9 @@
1	<title>Fossil FAQ</title>
2	<h1 align="center">Frequently Asked Questions</h1>
3
4	<p>Note: See also <a href="qandc.wiki">Questions and Criticisms</a>.


5
6	<ol>
7	<li><a href="#q1">What GUIs are available for fossil?</a></li>
8	<li><a href="#q2">What is the difference between a "branch" and a "fork"?</a></li>
9	<li><a href="#q3">How do I create a new branch?</a></li>
	@@ -15,12 +13,11 @@
13	<li><a href="#q6">How can I delete inappropriate content from my fossil repository?</a></li>
14	<li><a href="#q7">How do I make a clone of the fossil self-hosting repository?</a></li>
15	<li><a href="#q8">How do I import or export content from and to other version control systems?</a></li>
16	</ol>
17	<hr>
18	<p id="q1"><b>(1) What GUIs are available for fossil?</b></p>

19
20	<blockquote>The fossil executable comes with a [./webui.wiki \| web-based GUI] built in.
21	Just run:
22
23	<blockquote>
	@@ -27,24 +24,19 @@
24	<b>fossil [/help/ui\|ui]</b> <i>REPOSITORY-FILENAME</i>
25	</blockquote>
26
27	And your default web browser should pop up and automatically point to
28	the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
29	if you are within an open check-out.)</blockquote></li>
30
31	<p id="q2"><b>(2) What is the difference between a "branch" and a "fork"?</b></p>




32
33	<blockquote>This is a big question - too big to answer in a FAQ. Please
34	read the <a href="branching.wiki">Branching, Forking, Merging,
35	and Tagging</a> document.</blockquote></li>
36
37	<p id="q3"><b>(3) How do I create a new branch?</b></p>

38
39	<blockquote>There are lots of ways:
40
41	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
42	command, you can add the option "--branch <i>BRANCH-NAME</i>" to
	@@ -69,12 +61,11 @@
61	link (near the "Commands:" label) and click on that. On the
62	"Edit Check-in" page, check the box beside "Branching:" and fill in
63	the name of your new branch to the right and press the "Apply Changes"
64	button.</blockquote></li>
65
66	<p id="q4"><b>(4) How do I tag a check-in?</b></p>

67
68	<blockquote>There are several ways:
69
70	When you are checking in a new change using the <b>[/help/commit\|commit]</b>
71	command, you can add a tag to that check-in using the
	@@ -98,12 +89,11 @@
89	information page for that check-in. Then find the "<b>edit</b>"
90	link (near the "Commands:" label) and click on that. There are
91	controls on the edit page that allow new tags to be added and existing
92	tags to be removed.</blockquote></li>
93
94	<p id="q5"><b>(5) How do I create a private branch that won't get pushed back to the

95	main repository.</b></p>
96
97	<blockquote>Use the <b>--private</b> command-line option on the
98	<b>commit</b> command. The result will be a check-in which exists on
99	your local repository only and is never pushed to other repositories.
	@@ -123,17 +113,15 @@
113	Of course, you can also keep your branch private forever simply
114	by not merging the changes in the private branch back into the trunk.
115
116	[./private.wiki \| Additional information]</blockquote></li>
117
118	<p id="q6"><b>(6) How can I delete inappropriate content from my fossil repository?</b></p>

119
120	<blockquote>See the article on [./shunning.wiki \| "shunning"] for details.</blockquote></li>
121
122	<p id="q7"><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p>

123
124	<blockquote>Any of the following commands should work:
125	<blockquote><pre>
126	fossil [/help/clone\|clone] http://fossil-scm.org/ fossil.fossil
127	fossil [/help/clone\|clone] http://www2.fossil-scm.org/ fossil.fossil
	@@ -148,11 +136,10 @@
136	with the latest code in the public repository by typing:
137	<blockquote><pre>
138	fossil [/help/update\|update]
139	</pre></blockquote></blockquote></li>
140
141	<p id="q8"><b>(8) How do I import or export content from and to other version control systems?</b></p>

142
143	<blockquote>Please see [./inout.wiki \| Import And Export]</blockquote></li>
144
145	</ol>
146

M www/fileformat.wiki

+13 -26

		--- www/fileformat.wiki
		+++ www/fileformat.wiki
		@@ -32,12 +32,11 @@
32	32	with the global state.
33	33	The local state is not composed of artifacts and is not intended to be enduring.
34	34	This document is concerned with global state only. Local state is only
35	35	mentioned here in order to distinguish it from global state.
36	36
37		-<a id="names"></a>
38		-<h2>1.0 Artifact Names</h2>
	37	+<h2 id="names">1.0 Artifact Names</h2>
39	38
40	39	Each artifact in the repository is named by a hash of its content.
41	40	No prefixes, suffixes, or other information is added to an artifact before
42	41	the hash is computed. The artifact name is just the (lower-case
43	42	hexadecimal) hash of the raw artifact.
		@@ -54,12 +53,11 @@
54	53
55	54	Prior to Fossil version 2.0, all names were formed from the SHA1 hash of
56	55	the artifact. The key innovation in Fossil 2.0 was adding support for
57	56	alternative hash algorithms.
58	57
59		-<a id="structural"></a>
60		-<h2>2.0 Structural Artifacts</h2>
	58	+<h2 id="structural">2.0 Structural Artifacts</h2>
61	59
62	60	A structural artifact is an artifact with a particular format
63	61	that is used to define the relationships between other artifacts in the
64	62	repository.
65	63	Fossil recognizes the following kinds of structural
		@@ -100,12 +98,11 @@
100	98	not how the artifacts are stored on disk. It is the artifact format that
101	99	is intended to be enduring. The specifics of how artifacts are stored on
102	100	disk, though stable, is not intended to live as long as the
103	101	artifact format.
104	102
105		-<a id="manifest"></a>
106		-<h3>2.1 The Manifest</h3>
	103	+<h3 id="manifest">2.1 The Manifest</h3>
107	104
108	105	A manifest defines a check-in.
109	106	A manifest contains a list of artifacts for
110	107	each file in the project and the corresponding filenames, as
111	108	well as information such as parent check-ins, the username of the
		@@ -256,12 +253,11 @@
256	253	consistent.
257	254
258	255	A sample manifest from Fossil itself can be seen
259	256	[/artifact/28987096ac \| here].
260	257
261		-<a id="cluster"></a>
262		-<h3>2.2 Clusters</h3>
	258	+<h3 id="cluster">2.2 Clusters</h3>
263	259
264	260	A cluster is an artifact that declares the existence of other artifacts.
265	261	Clusters are used during repository synchronization to help
266	262	reduce network traffic. As such, clusters are an optimization and
267	263	may be removed from a repository without loss or damage to the
		@@ -282,12 +278,11 @@
282	278	prior cards in the cluster. The <b>Z</b> card is required.
283	279
284	280	An example cluster from Fossil can be seen
285	281	[/artifact/d03dbdd73a2a8 \| here].
286	282
287		-<a id="ctrl"></a>
288		-<h3>2.3 Control Artifacts</h3>
	283	+<h3 id="ctrl">2.3 Control Artifacts</h3>
289	284
290	285	Control artifacts are used to assign properties to other artifacts
291	286	within the repository.
292	287	Allowed cards in a control artifact are as follows:
293	288
		@@ -336,12 +331,11 @@
336	331	artifact. The <b>Z</b> card is the usual required artifact checksum.
337	332
338	333	An example control artifact can be seen [/info/9d302ccda8 \| here].
339	334
340	335
341		-<a id="wikichng"></a>
342		-<h3>2.4 Wiki Pages</h3>
	336	+<h3 id="wikichng">2.4 Wiki Pages</h3>
343	337
344	338	A wiki artifact defines a single version of a
345	339	single wiki page.
346	340	Wiki artifacts accept
347	341	the following card types:
		@@ -380,12 +374,11 @@
380	374	artifact that includes a <b>C</b> card.
381	375
382	376	An example wiki artifact can be seen
383	377	[/artifact?name=7b2f5fd0e0&txt=1 \| here].
384	378
385		-<a id="tktchng"></a>
386		-<h3>2.5 Ticket Changes</h3>
	379	+<h3 id="tktchng">2.5 Ticket Changes</h3>
387	380
388	381	A ticket-change artifact represents a change to a trouble ticket.
389	382	The following cards are allowed on a ticket change artifact:
390	383
391	384	<blockquote>
		@@ -426,12 +419,11 @@
426	419	escapes defined for the <b>C</b> card of a manifest.
427	420
428	421	An example ticket-change artifact can be seen
429	422	[/artifact/91f1ec6af053 \| here].
430	423
431		-<a id="attachment"></a>
432		-<h3>2.6 Attachments</h3>
	424	+<h3 id="attachment">2.6 Attachments</h3>
433	425
434	426	An attachment artifact associates some other artifact that is the
435	427	attachment (the source artifact) with a ticket or wiki page or
436	428	technical note to which
437	429	the attachment is connected (the target artifact).
		@@ -468,12 +460,11 @@
468	460
469	461	The <b>Z</b> card is the usual checksum over the rest of the attachment artifact.
470	462	The <b>Z</b> card is required.
471	463
472	464
473		-<a id="event"></a>
474		-<h3>2.7 Technical Notes</h3>
	465	+<h3 id="event">2.7 Technical Notes</h3>
475	466
476	467	A technical note or "technote" artifact (formerly known as an "event" artifact)
477	468	associates a timeline comment and a page of text
478	469	(similar to a wiki page) with a point in time. Technotes can be used
479	470	to record project milestones, release notes, blog entries, process
		@@ -536,12 +527,11 @@
536	527	technote. The format of the <b>W</b> card is exactly the same as for a
537	528	[#wikichng \| wiki artifact].
538	529
539	530	The <b>Z</b> card is the required checksum over the rest of the artifact.
540	531
541		-<a id="forum"></a>
542		-<h3>2.8 Forum Posts</h3>
	532	+<h3 id="forum">2.8 Forum Posts</h3>
543	533
544	534	Forum posts are intended as a mechanism for users and developers to
545	535	discuss a project. Forum posts are like messages on a mailing list.
546	536
547	537	The following cards are allowed on an forum post artifact:
		@@ -611,12 +601,11 @@
611	601	[#wikichng \| wiki artifact].
612	602
613	603	The <b>Z</b> card is the required checksum over the rest of the artifact.
614	604
615	605
616		-<a id="summary"></a>
617		-<h2>3.0 Card Summary</h2>
	606	+<h2 id="summary">3.0 Card Summary</h2>
618	607
619	608	The following table summarizes the various kinds of cards that appear
620	609	on Fossil artifacts. A blank entry means that combination of card and
621	610	artifact is not legal. A number or range of numbers indicates the number
622	611	of times a card may (or must) appear in the corresponding artifact type.
		@@ -887,18 +876,16 @@
887	876	I-card, not both.
888	877
889	878	5) [#forum \| Forum Post] P-cards may have only a single parent
890	879	hash. i.e. they may not have merge parents.
891	880
892		-<a id="addenda"></a>
893		-<h2>4.0 Addenda</h2>
	881	+<h2 id="addenda">4.0 Addenda</h2>
894	882
895	883	This section contains additional information which may be useful when
896	884	implementing algorithms described above.
897	885
898		-<a id="outofordercards"></a>
899		-<h3>4.1 Relaxed Card Ordering Due To An Historical Bug</h3>
	886	+<h3 id="outofordercards">4.1 Relaxed Card Ordering Due To An Historical Bug</h3>
900	887
901	888	All cards of a structural artifact should be in lexicographical order.
902	889	The Fossil implementation verifies this and rejects any structural
903	890	artifact which has out-of-order cards. Futhermore, when Fossil is
904	891	generating new structural artifacts, it runs the generated artifact
905	892

	--- www/fileformat.wiki
	+++ www/fileformat.wiki
	@@ -32,12 +32,11 @@
32	with the global state.
33	The local state is not composed of artifacts and is not intended to be enduring.
34	This document is concerned with global state only. Local state is only
35	mentioned here in order to distinguish it from global state.
36
37	<a id="names"></a>
38	<h2>1.0 Artifact Names</h2>
39
40	Each artifact in the repository is named by a hash of its content.
41	No prefixes, suffixes, or other information is added to an artifact before
42	the hash is computed. The artifact name is just the (lower-case
43	hexadecimal) hash of the raw artifact.
	@@ -54,12 +53,11 @@
54
55	Prior to Fossil version 2.0, all names were formed from the SHA1 hash of
56	the artifact. The key innovation in Fossil 2.0 was adding support for
57	alternative hash algorithms.
58
59	<a id="structural"></a>
60	<h2>2.0 Structural Artifacts</h2>
61
62	A structural artifact is an artifact with a particular format
63	that is used to define the relationships between other artifacts in the
64	repository.
65	Fossil recognizes the following kinds of structural
	@@ -100,12 +98,11 @@
100	not how the artifacts are stored on disk. It is the artifact format that
101	is intended to be enduring. The specifics of how artifacts are stored on
102	disk, though stable, is not intended to live as long as the
103	artifact format.
104
105	<a id="manifest"></a>
106	<h3>2.1 The Manifest</h3>
107
108	A manifest defines a check-in.
109	A manifest contains a list of artifacts for
110	each file in the project and the corresponding filenames, as
111	well as information such as parent check-ins, the username of the
	@@ -256,12 +253,11 @@
256	consistent.
257
258	A sample manifest from Fossil itself can be seen
259	[/artifact/28987096ac \| here].
260
261	<a id="cluster"></a>
262	<h3>2.2 Clusters</h3>
263
264	A cluster is an artifact that declares the existence of other artifacts.
265	Clusters are used during repository synchronization to help
266	reduce network traffic. As such, clusters are an optimization and
267	may be removed from a repository without loss or damage to the
	@@ -282,12 +278,11 @@
282	prior cards in the cluster. The <b>Z</b> card is required.
283
284	An example cluster from Fossil can be seen
285	[/artifact/d03dbdd73a2a8 \| here].
286
287	<a id="ctrl"></a>
288	<h3>2.3 Control Artifacts</h3>
289
290	Control artifacts are used to assign properties to other artifacts
291	within the repository.
292	Allowed cards in a control artifact are as follows:
293
	@@ -336,12 +331,11 @@
336	artifact. The <b>Z</b> card is the usual required artifact checksum.
337
338	An example control artifact can be seen [/info/9d302ccda8 \| here].
339
340
341	<a id="wikichng"></a>
342	<h3>2.4 Wiki Pages</h3>
343
344	A wiki artifact defines a single version of a
345	single wiki page.
346	Wiki artifacts accept
347	the following card types:
	@@ -380,12 +374,11 @@
380	artifact that includes a <b>C</b> card.
381
382	An example wiki artifact can be seen
383	[/artifact?name=7b2f5fd0e0&txt=1 \| here].
384
385	<a id="tktchng"></a>
386	<h3>2.5 Ticket Changes</h3>
387
388	A ticket-change artifact represents a change to a trouble ticket.
389	The following cards are allowed on a ticket change artifact:
390
391	<blockquote>
	@@ -426,12 +419,11 @@
426	escapes defined for the <b>C</b> card of a manifest.
427
428	An example ticket-change artifact can be seen
429	[/artifact/91f1ec6af053 \| here].
430
431	<a id="attachment"></a>
432	<h3>2.6 Attachments</h3>
433
434	An attachment artifact associates some other artifact that is the
435	attachment (the source artifact) with a ticket or wiki page or
436	technical note to which
437	the attachment is connected (the target artifact).
	@@ -468,12 +460,11 @@
468
469	The <b>Z</b> card is the usual checksum over the rest of the attachment artifact.
470	The <b>Z</b> card is required.
471
472
473	<a id="event"></a>
474	<h3>2.7 Technical Notes</h3>
475
476	A technical note or "technote" artifact (formerly known as an "event" artifact)
477	associates a timeline comment and a page of text
478	(similar to a wiki page) with a point in time. Technotes can be used
479	to record project milestones, release notes, blog entries, process
	@@ -536,12 +527,11 @@
536	technote. The format of the <b>W</b> card is exactly the same as for a
537	[#wikichng \| wiki artifact].
538
539	The <b>Z</b> card is the required checksum over the rest of the artifact.
540
541	<a id="forum"></a>
542	<h3>2.8 Forum Posts</h3>
543
544	Forum posts are intended as a mechanism for users and developers to
545	discuss a project. Forum posts are like messages on a mailing list.
546
547	The following cards are allowed on an forum post artifact:
	@@ -611,12 +601,11 @@
611	[#wikichng \| wiki artifact].
612
613	The <b>Z</b> card is the required checksum over the rest of the artifact.
614
615
616	<a id="summary"></a>
617	<h2>3.0 Card Summary</h2>
618
619	The following table summarizes the various kinds of cards that appear
620	on Fossil artifacts. A blank entry means that combination of card and
621	artifact is not legal. A number or range of numbers indicates the number
622	of times a card may (or must) appear in the corresponding artifact type.
	@@ -887,18 +876,16 @@
887	I-card, not both.
888
889	5) [#forum \| Forum Post] P-cards may have only a single parent
890	hash. i.e. they may not have merge parents.
891
892	<a id="addenda"></a>
893	<h2>4.0 Addenda</h2>
894
895	This section contains additional information which may be useful when
896	implementing algorithms described above.
897
898	<a id="outofordercards"></a>
899	<h3>4.1 Relaxed Card Ordering Due To An Historical Bug</h3>
900
901	All cards of a structural artifact should be in lexicographical order.
902	The Fossil implementation verifies this and rejects any structural
903	artifact which has out-of-order cards. Futhermore, when Fossil is
904	generating new structural artifacts, it runs the generated artifact
905

	--- www/fileformat.wiki
	+++ www/fileformat.wiki
	@@ -32,12 +32,11 @@
32	with the global state.
33	The local state is not composed of artifacts and is not intended to be enduring.
34	This document is concerned with global state only. Local state is only
35	mentioned here in order to distinguish it from global state.
36
37	<h2 id="names">1.0 Artifact Names</h2>

38
39	Each artifact in the repository is named by a hash of its content.
40	No prefixes, suffixes, or other information is added to an artifact before
41	the hash is computed. The artifact name is just the (lower-case
42	hexadecimal) hash of the raw artifact.
	@@ -54,12 +53,11 @@
53
54	Prior to Fossil version 2.0, all names were formed from the SHA1 hash of
55	the artifact. The key innovation in Fossil 2.0 was adding support for
56	alternative hash algorithms.
57
58	<h2 id="structural">2.0 Structural Artifacts</h2>

59
60	A structural artifact is an artifact with a particular format
61	that is used to define the relationships between other artifacts in the
62	repository.
63	Fossil recognizes the following kinds of structural
	@@ -100,12 +98,11 @@
98	not how the artifacts are stored on disk. It is the artifact format that
99	is intended to be enduring. The specifics of how artifacts are stored on
100	disk, though stable, is not intended to live as long as the
101	artifact format.
102
103	<h3 id="manifest">2.1 The Manifest</h3>

104
105	A manifest defines a check-in.
106	A manifest contains a list of artifacts for
107	each file in the project and the corresponding filenames, as
108	well as information such as parent check-ins, the username of the
	@@ -256,12 +253,11 @@
253	consistent.
254
255	A sample manifest from Fossil itself can be seen
256	[/artifact/28987096ac \| here].
257
258	<h3 id="cluster">2.2 Clusters</h3>

259
260	A cluster is an artifact that declares the existence of other artifacts.
261	Clusters are used during repository synchronization to help
262	reduce network traffic. As such, clusters are an optimization and
263	may be removed from a repository without loss or damage to the
	@@ -282,12 +278,11 @@
278	prior cards in the cluster. The <b>Z</b> card is required.
279
280	An example cluster from Fossil can be seen
281	[/artifact/d03dbdd73a2a8 \| here].
282
283	<h3 id="ctrl">2.3 Control Artifacts</h3>

284
285	Control artifacts are used to assign properties to other artifacts
286	within the repository.
287	Allowed cards in a control artifact are as follows:
288
	@@ -336,12 +331,11 @@
331	artifact. The <b>Z</b> card is the usual required artifact checksum.
332
333	An example control artifact can be seen [/info/9d302ccda8 \| here].
334
335
336	<h3 id="wikichng">2.4 Wiki Pages</h3>

337
338	A wiki artifact defines a single version of a
339	single wiki page.
340	Wiki artifacts accept
341	the following card types:
	@@ -380,12 +374,11 @@
374	artifact that includes a <b>C</b> card.
375
376	An example wiki artifact can be seen
377	[/artifact?name=7b2f5fd0e0&txt=1 \| here].
378
379	<h3 id="tktchng">2.5 Ticket Changes</h3>

380
381	A ticket-change artifact represents a change to a trouble ticket.
382	The following cards are allowed on a ticket change artifact:
383
384	<blockquote>
	@@ -426,12 +419,11 @@
419	escapes defined for the <b>C</b> card of a manifest.
420
421	An example ticket-change artifact can be seen
422	[/artifact/91f1ec6af053 \| here].
423
424	<h3 id="attachment">2.6 Attachments</h3>

425
426	An attachment artifact associates some other artifact that is the
427	attachment (the source artifact) with a ticket or wiki page or
428	technical note to which
429	the attachment is connected (the target artifact).
	@@ -468,12 +460,11 @@
460
461	The <b>Z</b> card is the usual checksum over the rest of the attachment artifact.
462	The <b>Z</b> card is required.
463
464
465	<h3 id="event">2.7 Technical Notes</h3>

466
467	A technical note or "technote" artifact (formerly known as an "event" artifact)
468	associates a timeline comment and a page of text
469	(similar to a wiki page) with a point in time. Technotes can be used
470	to record project milestones, release notes, blog entries, process
	@@ -536,12 +527,11 @@
527	technote. The format of the <b>W</b> card is exactly the same as for a
528	[#wikichng \| wiki artifact].
529
530	The <b>Z</b> card is the required checksum over the rest of the artifact.
531
532	<h3 id="forum">2.8 Forum Posts</h3>

533
534	Forum posts are intended as a mechanism for users and developers to
535	discuss a project. Forum posts are like messages on a mailing list.
536
537	The following cards are allowed on an forum post artifact:
	@@ -611,12 +601,11 @@
601	[#wikichng \| wiki artifact].
602
603	The <b>Z</b> card is the required checksum over the rest of the artifact.
604
605
606	<h2 id="summary">3.0 Card Summary</h2>

607
608	The following table summarizes the various kinds of cards that appear
609	on Fossil artifacts. A blank entry means that combination of card and
610	artifact is not legal. A number or range of numbers indicates the number
611	of times a card may (or must) appear in the corresponding artifact type.
	@@ -887,18 +876,16 @@
876	I-card, not both.
877
878	5) [#forum \| Forum Post] P-cards may have only a single parent
879	hash. i.e. they may not have merge parents.
880
881	<h2 id="addenda">4.0 Addenda</h2>

882
883	This section contains additional information which may be useful when
884	implementing algorithms described above.
885
886	<h3 id="outofordercards">4.1 Relaxed Card Ordering Due To An Historical Bug</h3>

887
888	All cards of a structural artifact should be in lexicographical order.
889	The Fossil implementation verifies this and rejects any structural
890	artifact which has out-of-order cards. Futhermore, when Fossil is
891	generating new structural artifacts, it runs the generated artifact
892

M www/gitusers.md

+4 -4

		--- www/gitusers.md
		+++ www/gitusers.md
		@@ -716,11 +716,11 @@
716	716	We cover [this and the workaround for it](#csplit) above.
717	717
718	718	[3]: ./rebaseharm.md
719	719
720	720
721		-## <a name="cdiff"></a> Colorized Diffs
	721	+## <a id="cdiff"></a> Colorized Diffs
722	722
723	723	The graphical diffs in the Fossil web UI and `fossil diff --tk` use
724	724	color to distinguish insertions, deletions, and replacements, but unlike
725	725	with `git diff` when the output is to an ANSI X3.64 capable terminal,
726	726	`fossil diff` does not.
		@@ -753,11 +753,11 @@
753	753
754	754	While there is no direct equivalent to Git’s “`show`” command, similar
755	755	functionality may be present in Fossil under other commands:
756	756
757	757
758		-#### <a name="patch"></a> Show A Patch For A Commit
	758	+#### <a id="patch"></a> Show A Patch For A Commit
759	759
760	760	git show -p COMMIT_ID
761	761
762	762	…gives much the same output as
763	763
		@@ -778,11 +778,11 @@
778	778
779	779	[devorg]: ./fossil-v-git.wiki#devorg
780	780	[LKML]: https://lkml.org/
781	781
782	782
783		-#### <a name="cmsg"></a> Show A Specific Commit Message
	783	+#### <a id="cmsg"></a> Show A Specific Commit Message
784	784
785	785	git show -s COMMIT_ID
786	786
787	787
788	788	…is
		@@ -797,11 +797,11 @@
797	797	`git show`; it just overlaps its functionality in some areas. Much of
798	798	what’s missing is present in the corresponding [`/info` web
799	799	view][infow], though.
800	800
801	801
802		-#### <a name="dstat"></a> Diff Statistics
	802	+#### <a id="dstat"></a> Diff Statistics
803	803
804	804	Fossil’s closest internal equivalent to commands like
805	805	`git show --stat` is:
806	806
807	807	fossil diff -i --from 2020-04-01 --numstat
808	808

	--- www/gitusers.md
	+++ www/gitusers.md
	@@ -716,11 +716,11 @@
716	We cover [this and the workaround for it](#csplit) above.
717
718	[3]: ./rebaseharm.md
719
720
721	## <a name="cdiff"></a> Colorized Diffs
722
723	The graphical diffs in the Fossil web UI and `fossil diff --tk` use
724	color to distinguish insertions, deletions, and replacements, but unlike
725	with `git diff` when the output is to an ANSI X3.64 capable terminal,
726	`fossil diff` does not.
	@@ -753,11 +753,11 @@
753
754	While there is no direct equivalent to Git’s “`show`” command, similar
755	functionality may be present in Fossil under other commands:
756
757
758	#### <a name="patch"></a> Show A Patch For A Commit
759
760	git show -p COMMIT_ID
761
762	…gives much the same output as
763
	@@ -778,11 +778,11 @@
778
779	[devorg]: ./fossil-v-git.wiki#devorg
780	[LKML]: https://lkml.org/
781
782
783	#### <a name="cmsg"></a> Show A Specific Commit Message
784
785	git show -s COMMIT_ID
786
787
788	…is
	@@ -797,11 +797,11 @@
797	`git show`; it just overlaps its functionality in some areas. Much of
798	what’s missing is present in the corresponding [`/info` web
799	view][infow], though.
800
801
802	#### <a name="dstat"></a> Diff Statistics
803
804	Fossil’s closest internal equivalent to commands like
805	`git show --stat` is:
806
807	fossil diff -i --from 2020-04-01 --numstat
808

	--- www/gitusers.md
	+++ www/gitusers.md
	@@ -716,11 +716,11 @@
716	We cover [this and the workaround for it](#csplit) above.
717
718	[3]: ./rebaseharm.md
719
720
721	## <a id="cdiff"></a> Colorized Diffs
722
723	The graphical diffs in the Fossil web UI and `fossil diff --tk` use
724	color to distinguish insertions, deletions, and replacements, but unlike
725	with `git diff` when the output is to an ANSI X3.64 capable terminal,
726	`fossil diff` does not.
	@@ -753,11 +753,11 @@
753
754	While there is no direct equivalent to Git’s “`show`” command, similar
755	functionality may be present in Fossil under other commands:
756
757
758	#### <a id="patch"></a> Show A Patch For A Commit
759
760	git show -p COMMIT_ID
761
762	…gives much the same output as
763
	@@ -778,11 +778,11 @@
778
779	[devorg]: ./fossil-v-git.wiki#devorg
780	[LKML]: https://lkml.org/
781
782
783	#### <a id="cmsg"></a> Show A Specific Commit Message
784
785	git show -s COMMIT_ID
786
787
788	…is
	@@ -797,11 +797,11 @@
797	`git show`; it just overlaps its functionality in some areas. Much of
798	what’s missing is present in the corresponding [`/info` web
799	view][infow], though.
800
801
802	#### <a id="dstat"></a> Diff Statistics
803
804	Fossil’s closest internal equivalent to commands like
805	`git show --stat` is:
806
807	fossil diff -i --from 2020-04-01 --numstat
808

M www/globs.md

+2 -2

		--- www/globs.md
		+++ www/globs.md
		@@ -282,11 +282,11 @@
282	282	That advice does not help you when you are giving one-off glob patterns
283	283	in `fossil` commands. The remainder of this section gives remedies and
284	284	workarounds for these problems.
285	285
286	286
287		-### <a name="posix"></a>POSIX Systems
	287	+### <a id="posix"></a>POSIX Systems
288	288
289	289	If you are using Fossil on a system with a POSIX-compatible shell
290	290	— Linux, macOS, the BSDs, Unix, Cygwin, WSL etc. — the shell
291	291	may expand the glob patterns before passing the result to the `fossil`
292	292	executable.
		@@ -369,11 +369,11 @@
369	369	accidentally check something like a password, an API key, or the
370	370	private half of a public cryptographic key into Fossil repository that
371	371	can be read by people who should not have such secrets.
372	372
373	373
374		-### <a name="windows"></a>Windows
	374	+### <a id="windows"></a>Windows
375	375
376	376	Before we get into Windows-specific details here, beware that this
377	377	section does not apply to the several Microsoft Windows extensions that
378	378	provide POSIX semantics to Windows, for which you want to use the advice
379	379	in [the POSIX section above](#posix) instead:
380	380

	--- www/globs.md
	+++ www/globs.md
	@@ -282,11 +282,11 @@
282	That advice does not help you when you are giving one-off glob patterns
283	in `fossil` commands. The remainder of this section gives remedies and
284	workarounds for these problems.
285
286
287	### <a name="posix"></a>POSIX Systems
288
289	If you are using Fossil on a system with a POSIX-compatible shell
290	— Linux, macOS, the BSDs, Unix, Cygwin, WSL etc. — the shell
291	may expand the glob patterns before passing the result to the `fossil`
292	executable.
	@@ -369,11 +369,11 @@
369	accidentally check something like a password, an API key, or the
370	private half of a public cryptographic key into Fossil repository that
371	can be read by people who should not have such secrets.
372
373
374	### <a name="windows"></a>Windows
375
376	Before we get into Windows-specific details here, beware that this
377	section does not apply to the several Microsoft Windows extensions that
378	provide POSIX semantics to Windows, for which you want to use the advice
379	in [the POSIX section above](#posix) instead:
380

	--- www/globs.md
	+++ www/globs.md
	@@ -282,11 +282,11 @@
282	That advice does not help you when you are giving one-off glob patterns
283	in `fossil` commands. The remainder of this section gives remedies and
284	workarounds for these problems.
285
286
287	### <a id="posix"></a>POSIX Systems
288
289	If you are using Fossil on a system with a POSIX-compatible shell
290	— Linux, macOS, the BSDs, Unix, Cygwin, WSL etc. — the shell
291	may expand the glob patterns before passing the result to the `fossil`
292	executable.
	@@ -369,11 +369,11 @@
369	accidentally check something like a password, an API key, or the
370	private half of a public cryptographic key into Fossil repository that
371	can be read by people who should not have such secrets.
372
373
374	### <a id="windows"></a>Windows
375
376	Before we get into Windows-specific details here, beware that this
377	section does not apply to the several Microsoft Windows extensions that
378	provide POSIX semantics to Windows, for which you want to use the advice
379	in [the POSIX section above](#posix) instead:
380

M www/inout.wiki

+1 -1

		--- www/inout.wiki
		+++ www/inout.wiki
		@@ -24,11 +24,11 @@
24	24	is currently the only VCS interchange format that Fossil understands. But
25	25	future versions of Fossil might be enhanced to understand other VCS
26	26	interchange formats, and so for compatibility, use of the
27	27	--git option is recommended.
28	28
29		-<a name="fx_git"></a>
	29	+<a id="fx_git"></a>
30	30	Note that in new imports, Fossil defaults to using the email component of the
31	31	Git <em>committer</em> (or <em>author</em> if <code>--use-author</code> is
32	32	passed) to attribute check-ins in the imported repository. Alternatively, the
33	33	[/help?cmd=import \| <code>--attribute</code>] option can be passed to have all
34	34	commits by a given committer attributed to a desired username. This will create
35	35

	--- www/inout.wiki
	+++ www/inout.wiki
	@@ -24,11 +24,11 @@
24	is currently the only VCS interchange format that Fossil understands. But
25	future versions of Fossil might be enhanced to understand other VCS
26	interchange formats, and so for compatibility, use of the
27	--git option is recommended.
28
29	<a name="fx_git"></a>
30	Note that in new imports, Fossil defaults to using the email component of the
31	Git <em>committer</em> (or <em>author</em> if <code>--use-author</code> is
32	passed) to attribute check-ins in the imported repository. Alternatively, the
33	[/help?cmd=import \| <code>--attribute</code>] option can be passed to have all
34	commits by a given committer attributed to a desired username. This will create
35

	--- www/inout.wiki
	+++ www/inout.wiki
	@@ -24,11 +24,11 @@
24	is currently the only VCS interchange format that Fossil understands. But
25	future versions of Fossil might be enhanced to understand other VCS
26	interchange formats, and so for compatibility, use of the
27	--git option is recommended.
28
29	<a id="fx_git"></a>
30	Note that in new imports, Fossil defaults to using the email component of the
31	Git <em>committer</em> (or <em>author</em> if <code>--use-author</code> is
32	passed) to attribute check-ins in the imported repository. Alternatively, the
33	[/help?cmd=import \| <code>--attribute</code>] option can be passed to have all
34	commits by a given committer attributed to a desired username. This will create
35

M www/interwiki.md

+1 -1

		--- www/interwiki.md
		+++ www/interwiki.md
		@@ -57,11 +57,11 @@
57	57	The Intermap defines a base URL for each Tag. Path links are appended
58	58	directly to the URL contained in the Intermap. The Intermap can define
59	59	additional text to put in between the base URL and the PageName for
60	60	Hash and Wiki links, respectively.
61	61
62		-<a name="intermap"></a>
	62	+<a id="intermap"></a>
63	63	## Intermap
64	64
65	65	The intermap defines a mapping from interwiki Tags to full URLs. The
66	66	Intermap can be viewed and managed using the [fossil interwiki][iwiki]
67	67	command or the [/intermap][imap] webpages.
68	68

	--- www/interwiki.md
	+++ www/interwiki.md
	@@ -57,11 +57,11 @@
57	The Intermap defines a base URL for each Tag. Path links are appended
58	directly to the URL contained in the Intermap. The Intermap can define
59	additional text to put in between the base URL and the PageName for
60	Hash and Wiki links, respectively.
61
62	<a name="intermap"></a>
63	## Intermap
64
65	The intermap defines a mapping from interwiki Tags to full URLs. The
66	Intermap can be viewed and managed using the [fossil interwiki][iwiki]
67	command or the [/intermap][imap] webpages.
68

	--- www/interwiki.md
	+++ www/interwiki.md
	@@ -57,11 +57,11 @@
57	The Intermap defines a base URL for each Tag. Path links are appended
58	directly to the URL contained in the Intermap. The Intermap can define
59	additional text to put in between the base URL and the PageName for
60	Hash and Wiki links, respectively.
61
62	<a id="intermap"></a>
63	## Intermap
64
65	The intermap defines a mapping from interwiki Tags to full URLs. The
66	Intermap can be viewed and managed using the [fossil interwiki][iwiki]
67	command or the [/intermap][imap] webpages.
68

M www/makefile.wiki

+2 -4

		--- www/makefile.wiki
		+++ www/makefile.wiki
		@@ -12,12 +12,11 @@
12	12	So must people do not need to be concerned with the
13	13	build complexities of Fossil. But hard-core developers who desire
14	14	a deep understanding of how Fossil is put together can benefit
15	15	from reviewing this article.
16	16
17		-<a name="srctour"></a>
18		-<h1>2.0 Source Code Tour</h1>
	17	+<h1 id="srctour">2.0 Source Code Tour</h1>
19	18
20	19	The source code for Fossil is found in the
21	20	[/dir?ci=trunk&name=src \| src/] subdirectory of the
22	21	source tree. The src/ subdirectory contains all code, including
23	22	the code for the separate preprocessor programs.
		@@ -171,12 +170,11 @@
171	170	At the time of this writing, the "diff.tcl" script (a Tcl/Tk script used
172	171	to generate implement --tk option on the diff command) is the only resource
173	172	file processed using mkbuiltin.exe. However, new resources will likely be
174	173	added using this facility in future versions of Fossil.
175	174
176		-<a name="preprocessing"></a>
177		-<h1>4.0 Preprocessing</h1>
	175	+<h1 id="preprocessing">4.0 Preprocessing</h1>
178	176
179	177	There are three preprocessors for the Fossil sources. The mkindex
180	178	and translate preprocessors can be run in any order. The makeheaders
181	179	preprocessor must be run after translate.
182	180
183	181

	--- www/makefile.wiki
	+++ www/makefile.wiki
	@@ -12,12 +12,11 @@
12	So must people do not need to be concerned with the
13	build complexities of Fossil. But hard-core developers who desire
14	a deep understanding of how Fossil is put together can benefit
15	from reviewing this article.
16
17	<a name="srctour"></a>
18	<h1>2.0 Source Code Tour</h1>
19
20	The source code for Fossil is found in the
21	[/dir?ci=trunk&name=src \| src/] subdirectory of the
22	source tree. The src/ subdirectory contains all code, including
23	the code for the separate preprocessor programs.
	@@ -171,12 +170,11 @@
171	At the time of this writing, the "diff.tcl" script (a Tcl/Tk script used
172	to generate implement --tk option on the diff command) is the only resource
173	file processed using mkbuiltin.exe. However, new resources will likely be
174	added using this facility in future versions of Fossil.
175
176	<a name="preprocessing"></a>
177	<h1>4.0 Preprocessing</h1>
178
179	There are three preprocessors for the Fossil sources. The mkindex
180	and translate preprocessors can be run in any order. The makeheaders
181	preprocessor must be run after translate.
182
183

	--- www/makefile.wiki
	+++ www/makefile.wiki
	@@ -12,12 +12,11 @@
12	So must people do not need to be concerned with the
13	build complexities of Fossil. But hard-core developers who desire
14	a deep understanding of how Fossil is put together can benefit
15	from reviewing this article.
16
17	<h1 id="srctour">2.0 Source Code Tour</h1>

18
19	The source code for Fossil is found in the
20	[/dir?ci=trunk&name=src \| src/] subdirectory of the
21	source tree. The src/ subdirectory contains all code, including
22	the code for the separate preprocessor programs.
	@@ -171,12 +170,11 @@
170	At the time of this writing, the "diff.tcl" script (a Tcl/Tk script used
171	to generate implement --tk option on the diff command) is the only resource
172	file processed using mkbuiltin.exe. However, new resources will likely be
173	added using this facility in future versions of Fossil.
174
175	<h1 id="preprocessing">4.0 Preprocessing</h1>

176
177	There are three preprocessors for the Fossil sources. The mkindex
178	and translate preprocessors can be run in any order. The makeheaders
179	preprocessor must be run after translate.
180
181

M www/mirrortogithub.md

+2 -2

		--- www/mirrortogithub.md
		+++ www/mirrortogithub.md
		@@ -143,12 +143,12 @@
143	143	[attr]: /help?cmd=import
144	144	[fxgit]: ./inout.wiki#fx_git
145	145	[ui]: /help?cmd=ui
146	146	[usercmd]: /help?cmd=user
147	147
148		-<a name='ex1'></a>
149		-## Example GitHub Mirrors
	148	+
	149	+## <a id='ex1'></a>Example GitHub Mirrors
150	150
151	151	As of this writing (2019-03-16) Fossil’s own repository is mirrored
152	152	on GitHub at:
153	153
154	154	>
155	155

	--- www/mirrortogithub.md
	+++ www/mirrortogithub.md
	@@ -143,12 +143,12 @@
143	[attr]: /help?cmd=import
144	[fxgit]: ./inout.wiki#fx_git
145	[ui]: /help?cmd=ui
146	[usercmd]: /help?cmd=user
147
148	<a name='ex1'></a>
149	## Example GitHub Mirrors
150
151	As of this writing (2019-03-16) Fossil’s own repository is mirrored
152	on GitHub at:
153
154	>
155

	--- www/mirrortogithub.md
	+++ www/mirrortogithub.md
	@@ -143,12 +143,12 @@
143	[attr]: /help?cmd=import
144	[fxgit]: ./inout.wiki#fx_git
145	[ui]: /help?cmd=ui
146	[usercmd]: /help?cmd=user
147
148
149	## <a id='ex1'></a>Example GitHub Mirrors
150
151	As of this writing (2019-03-16) Fossil’s own repository is mirrored
152	on GitHub at:
153
154	>
155

M www/mkindex.tcl

+1 -2

		--- www/mkindex.tcl
		+++ www/mkindex.tcl
		@@ -168,12 +168,11 @@
168	168	<li> <a href='hacker-howto.wiki'>Fossil Developer's Guide</a>
169	169	<li> <a href='$ROOT/wiki?name=To+Do+List'>To Do List (Wiki)</a>
170	170	<li> <a href='http://fossil-scm.org/schimpf-book/home'>Jim Schimpf's
171	171	book</a>
172	172	</ul>
173		-<a name="pindex"></a>
174		-<h2>Other Documents:</h2>
	173	+<h2 id="pindex">Other Documents:</h2>
175	174	<ul>}
176	175	foreach entry $permindex {
177	176	foreach {title file bold} $entry break
178	177	# if {$bold} {set title <b>$title</b>}
179	178	if {[string match /* $file]} {set file ../../..$file}
180	179

	--- www/mkindex.tcl
	+++ www/mkindex.tcl
	@@ -168,12 +168,11 @@
168	<li> <a href='hacker-howto.wiki'>Fossil Developer's Guide</a>
169	<li> <a href='$ROOT/wiki?name=To+Do+List'>To Do List (Wiki)</a>
170	<li> <a href='http://fossil-scm.org/schimpf-book/home'>Jim Schimpf's
171	book</a>
172	</ul>
173	<a name="pindex"></a>
174	<h2>Other Documents:</h2>
175	<ul>}
176	foreach entry $permindex {
177	foreach {title file bold} $entry break
178	# if {$bold} {set title <b>$title</b>}
179	if {[string match /* $file]} {set file ../../..$file}
180

	--- www/mkindex.tcl
	+++ www/mkindex.tcl
	@@ -168,12 +168,11 @@
168	<li> <a href='hacker-howto.wiki'>Fossil Developer's Guide</a>
169	<li> <a href='$ROOT/wiki?name=To+Do+List'>To Do List (Wiki)</a>
170	<li> <a href='http://fossil-scm.org/schimpf-book/home'>Jim Schimpf's
171	book</a>
172	</ul>
173	<h2 id="pindex">Other Documents:</h2>

174	<ul>}
175	foreach entry $permindex {
176	foreach {title file bold} $entry break
177	# if {$bold} {set title <b>$title</b>}
178	if {[string match /* $file]} {set file ../../..$file}
179

M www/permutedindex.html

+1 -2

		--- www/permutedindex.html
		+++ www/permutedindex.html
		@@ -17,12 +17,11 @@
17	17	<li> <a href='hacker-howto.wiki'>Fossil Developer's Guide</a>
18	18	<li> <a href='$ROOT/wiki?name=To+Do+List'>To Do List (Wiki)</a>
19	19	<li> <a href='http://fossil-scm.org/schimpf-book/home'>Jim Schimpf's
20	20	book</a>
21	21	</ul>
22		-<a name="pindex"></a>
23		-<h2>Other Documents:</h2>
	22	+<h2 id="pindex">Other Documents:</h2>
24	23	<ul>
25	24	<li><a href="tech_overview.wiki">A Technical Overview Of The Design And Implementation Of Fossil</a></li>
26	25	<li><a href="serverext.wiki">Adding Extensions To A Fossil Server Using CGI Scripts</a></li>
27	26	<li><a href="adding_code.wiki">Adding New Features To Fossil</a></li>
28	27	<li><a href="caps/">Administering User Capabilities</a></li>
29	28

	--- www/permutedindex.html
	+++ www/permutedindex.html
	@@ -17,12 +17,11 @@
17	<li> <a href='hacker-howto.wiki'>Fossil Developer's Guide</a>
18	<li> <a href='$ROOT/wiki?name=To+Do+List'>To Do List (Wiki)</a>
19	<li> <a href='http://fossil-scm.org/schimpf-book/home'>Jim Schimpf's
20	book</a>
21	</ul>
22	<a name="pindex"></a>
23	<h2>Other Documents:</h2>
24	<ul>
25	<li><a href="tech_overview.wiki">A Technical Overview Of The Design And Implementation Of Fossil</a></li>
26	<li><a href="serverext.wiki">Adding Extensions To A Fossil Server Using CGI Scripts</a></li>
27	<li><a href="adding_code.wiki">Adding New Features To Fossil</a></li>
28	<li><a href="caps/">Administering User Capabilities</a></li>
29

	--- www/permutedindex.html
	+++ www/permutedindex.html
	@@ -17,12 +17,11 @@
17	<li> <a href='hacker-howto.wiki'>Fossil Developer's Guide</a>
18	<li> <a href='$ROOT/wiki?name=To+Do+List'>To Do List (Wiki)</a>
19	<li> <a href='http://fossil-scm.org/schimpf-book/home'>Jim Schimpf's
20	book</a>
21	</ul>
22	<h2 id="pindex">Other Documents:</h2>

23	<ul>
24	<li><a href="tech_overview.wiki">A Technical Overview Of The Design And Implementation Of Fossil</a></li>
25	<li><a href="serverext.wiki">Adding Extensions To A Fossil Server Using CGI Scripts</a></li>
26	<li><a href="adding_code.wiki">Adding New Features To Fossil</a></li>
27	<li><a href="caps/">Administering User Capabilities</a></li>
28

M www/rebaseharm.md

+14 -14

		--- www/rebaseharm.md
		+++ www/rebaseharm.md
		@@ -14,19 +14,19 @@
14	14	[golden rule of rebasing][golden]: never rebase on a public
15	15	branch. Horror stories of misused rebase abound, and the rebase
16	16	documentation devotes considerable space toward explaining how to
17	17	recover from rebase errors and/or misuse.
18	18
19		-## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities
	19	+## <a id="cap-loss"></a>2.0 Rebase provides no new capabilities
20	20
21	21	Sometimes sharp and dangerous tools are justified,
22	22	because they accomplish things that cannot be
23	23	done otherwise, or at least cannot be done easily.
24	24	Rebase does not fall into that category,
25	25	because it provides no new capabilities.
26	26
27		-### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted
	27	+### <a id="orphaning"></a>2.1 A rebase is just a merge with historical references omitted
28	28
29	29	A rebase is really nothing more than a merge (or a series of merges)
30	30	that deliberately forgets one of the parents of each merge step.
31	31	To help illustrate this fact,
32	32	consider the first rebase example from the
		@@ -88,11 +88,11 @@
88	88	not overwhelm the weak history display mechanisms available in Git.
89	89	Wouldn't it be better, less error-prone, and easier on users
90	90	to enhance the history display mechanisms in Git so that rebasing
91	91	for a clean, linear history became unnecessary?
92	92
93		-### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs
	93	+### <a id="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs
94	94
95	95	Another argument, often cited, is that rebasing a feature branch
96	96	allows one to see just the changes in the feature branch without
97	97	the concurrent changes in the main line of development.
98	98	Consider a hypothetical case:
		@@ -212,11 +212,11 @@
212	212
213	213	So, to help with the problem of viewing changes associated with a feature
214	214	branch, perhaps what is needed is not rebase but rather better tools to
215	215	help users identify an appropriate baseline for their diffs.
216	216
217		-## <a name="siloing"></a>3.0 Rebase encourages siloed development
	217	+## <a id="siloing"></a>3.0 Rebase encourages siloed development
218	218
219	219	The [golden rule of rebasing][golden] is that you should never do it
220	220	on public branches, so if you are using rebase as intended, that means
221	221	you are keeping private branches. Or, to put it another way, you are
222	222	doing siloed development. You are not sharing your intermediate work
		@@ -251,11 +251,11 @@
251	251	while they're still isolated on a feature branch, or should that vetting
252	252	wait until you finally push a collapsed version of a private working
253	253	branch to the parent repo? Will the many eyeballs even see those errors
254	254	when they’re intermingled with code implementing some compelling new feature?
255	255
256		-## <a name="timestamps"></a>4.0 Rebase causes timestamp confusion
	256	+## <a id="timestamps"></a>4.0 Rebase causes timestamp confusion
257	257
258	258	Consider the earlier example of rebasing a feature branch:
259	259
260	260	~~~ pikchr toggle
261	261	# Copy of second diagram in section 2.2 above
		@@ -293,11 +293,11 @@
293	293	unique timestamps for C3' and C5' but then you lose the information
294	294	about when those check-ins were originally created, which can make
295	295	historical analysis of changes more difficult. It might also
296	296	complicate the legal defense of prior art claims.
297	297
298		-## <a name="lying"></a>5.0 Rebase misrepresents the project history
	298	+## <a id="lying"></a>5.0 Rebase misrepresents the project history
299	299
300	300	By discarding parentage information, rebase attempts to deceive the
301	301	reader about how the code actually came together.
302	302
303	303	Git’s rebase feature is more than just an
		@@ -329,11 +329,11 @@
329	329	why Git lacks support for making editorial changes to check-ins without
330	330	modifying history? Wouldn't it be better to fix the version control
331	331	tool rather than requiring users to fabricate a fictitious project
332	332	history?
333	333
334		-## <a name="collapsing"></a>6.0 Collapsing check-ins throws away valuable information
	334	+## <a id="collapsing"></a>6.0 Collapsing check-ins throws away valuable information
335	335
336	336	One of the oft-cited advantages of rebasing in Git is that it lets you
337	337	collapse multiple check-ins down to a single check-in to make the
338	338	development history “clean.” The intent is that development appear as
339	339	though every feature were created in a single step: no multi-step
		@@ -344,11 +344,11 @@
344	344
345	345	The common counterargument is that collapsed check-ins represent a
346	346	better world, the ideal we're striving for. What that argument overlooks
347	347	is that we must throw away valuable information to get there.
348	348
349		-### <a name="empathy"></a>6.1 Individual check-ins support mutual understanding
	349	+### <a id="empathy"></a>6.1 Individual check-ins support mutual understanding
350	350
351	351	Ideally, future developers of our software can understand every feature
352	352	in it using only context available in the version of the code they start
353	353	work with. Prior to widespread version control, developers had no choice
354	354	but to work that way. Pre-existing codebases could only be understood
		@@ -389,11 +389,11 @@
389	389	that collapses a whole branch's worth of changes down to a single
390	390	finished feature.
391	391
392	392	[sdm]: ./fossil-v-git.wiki#durable
393	393
394		-### <a name="bisecting"></a>6.2 Bisecting works better on small check-ins
	394	+### <a id="bisecting"></a>6.2 Bisecting works better on small check-ins
395	395
396	396	Git lets a developer write a feature in ten check-ins but collapse it
397	397	down to an eleventh check-in and then deliberately push only that final
398	398	collapsed check-in to the parent repo. Someone else may then do a bisect
399	399	that blames the merged check-in as the source of the problem they’re
		@@ -404,11 +404,11 @@
404	404	An equivalent push in Fossil will send all 11 check-ins to the parent
405	405	repository so that a later investigator doing the same sort of bisect
406	406	sees the complete check-in history. That bisect will point the
407	407	investigator at the single original check-in that caused the problem.
408	408
409		-### <a name="comments"></a>6.3 Multiple check-ins require multiple check-in comments
	409	+### <a id="comments"></a>6.3 Multiple check-ins require multiple check-in comments
410	410
411	411	The more comments you have from a given developer on a given body of
412	412	code, the more concise documentation you have of that developer's
413	413	thought process. To resume the bisecting example, a developer trying to
414	414	work out what the original developer was thinking with a given change
		@@ -416,11 +416,11 @@
416	416	one check-in out of ten blamed by the "bisect" command was trying to
417	417	accomplish than if they must work that out from the eleventh check-in's
418	418	comment, which only explains the "clean" version of the collapsed
419	419	feature.
420	420
421		-### <a name="cherrypicking"></a>6.4 Cherry-picks work better with small check-ins
	421	+### <a id="cherrypicking"></a>6.4 Cherry-picks work better with small check-ins
422	422
423	423	While working on a new feature in one branch, you may come across a bug
424	424	in the pre-existing code that you need to fix in order for work on that
425	425	feature to proceed. You could choose to switch briefly back to the
426	426	parent branch, develop the fix there, check it in, then merge the parent
		@@ -458,20 +458,20 @@
458	458	branch. Even if they manage to do their work without error, it takes
459	459	them more time to do the cherry-pick that way.
460	460
461	461	[rh]: https://en.wikipedia.org/wiki/Red_Hat
462	462
463		-### <a name="backouts"></a>6.5 Back-outs also work better with small check-ins
	463	+### <a id="backouts"></a>6.5 Back-outs also work better with small check-ins
464	464
465	465	The inverse of the cherry-pick merge is the back-out merge. If you push
466	466	only a collapsed version of a private working branch up to the parent
467	467	repo, those working from that parent repo cannot automatically back out
468	468	any of the individual check-ins that went into that private branch.
469	469	Others must either manually disentangle the problematic part of your
470	470	merge check-in or back out the entire feature.
471	471
472		-## <a name="better-plan"></a>7.0 Cherry-pick merges work better than rebase
	472	+## <a id="better-plan"></a>7.0 Cherry-pick merges work better than rebase
473	473
474	474	Perhaps there are some cases where a rebase-like transformation
475	475	is actually helpful, but those cases are rare, and when they do
476	476	come up, running a series of cherry-pick merges achieves the same
477	477	topology with several advantages:
		@@ -501,11 +501,11 @@
501	501	3. Cherry-picks keep both the original and the revised check-ins,
502	502	so both timestamps are preserved.
503	503
504	504	[tbc]: ./fossil-v-git.wiki#testing
505	505
506		-## <a name="conclusion"></a>8.0 Summary and conclusion
	506	+## <a id="conclusion"></a>8.0 Summary and conclusion
507	507
508	508	Rebasing is an anti-pattern. It is dishonest. It deliberately
509	509	omits historical information. It causes problems for collaboration.
510	510	And it has no offsetting benefits.
511	511
512	512

	--- www/rebaseharm.md
	+++ www/rebaseharm.md
	@@ -14,19 +14,19 @@
14	[golden rule of rebasing][golden]: never rebase on a public
15	branch. Horror stories of misused rebase abound, and the rebase
16	documentation devotes considerable space toward explaining how to
17	recover from rebase errors and/or misuse.
18
19	## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities
20
21	Sometimes sharp and dangerous tools are justified,
22	because they accomplish things that cannot be
23	done otherwise, or at least cannot be done easily.
24	Rebase does not fall into that category,
25	because it provides no new capabilities.
26
27	### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted
28
29	A rebase is really nothing more than a merge (or a series of merges)
30	that deliberately forgets one of the parents of each merge step.
31	To help illustrate this fact,
32	consider the first rebase example from the
	@@ -88,11 +88,11 @@
88	not overwhelm the weak history display mechanisms available in Git.
89	Wouldn't it be better, less error-prone, and easier on users
90	to enhance the history display mechanisms in Git so that rebasing
91	for a clean, linear history became unnecessary?
92
93	### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs
94
95	Another argument, often cited, is that rebasing a feature branch
96	allows one to see just the changes in the feature branch without
97	the concurrent changes in the main line of development.
98	Consider a hypothetical case:
	@@ -212,11 +212,11 @@
212
213	So, to help with the problem of viewing changes associated with a feature
214	branch, perhaps what is needed is not rebase but rather better tools to
215	help users identify an appropriate baseline for their diffs.
216
217	## <a name="siloing"></a>3.0 Rebase encourages siloed development
218
219	The [golden rule of rebasing][golden] is that you should never do it
220	on public branches, so if you are using rebase as intended, that means
221	you are keeping private branches. Or, to put it another way, you are
222	doing siloed development. You are not sharing your intermediate work
	@@ -251,11 +251,11 @@
251	while they're still isolated on a feature branch, or should that vetting
252	wait until you finally push a collapsed version of a private working
253	branch to the parent repo? Will the many eyeballs even see those errors
254	when they’re intermingled with code implementing some compelling new feature?
255
256	## <a name="timestamps"></a>4.0 Rebase causes timestamp confusion
257
258	Consider the earlier example of rebasing a feature branch:
259
260	~~~ pikchr toggle
261	# Copy of second diagram in section 2.2 above
	@@ -293,11 +293,11 @@
293	unique timestamps for C3' and C5' but then you lose the information
294	about when those check-ins were originally created, which can make
295	historical analysis of changes more difficult. It might also
296	complicate the legal defense of prior art claims.
297
298	## <a name="lying"></a>5.0 Rebase misrepresents the project history
299
300	By discarding parentage information, rebase attempts to deceive the
301	reader about how the code actually came together.
302
303	Git’s rebase feature is more than just an
	@@ -329,11 +329,11 @@
329	why Git lacks support for making editorial changes to check-ins without
330	modifying history? Wouldn't it be better to fix the version control
331	tool rather than requiring users to fabricate a fictitious project
332	history?
333
334	## <a name="collapsing"></a>6.0 Collapsing check-ins throws away valuable information
335
336	One of the oft-cited advantages of rebasing in Git is that it lets you
337	collapse multiple check-ins down to a single check-in to make the
338	development history “clean.” The intent is that development appear as
339	though every feature were created in a single step: no multi-step
	@@ -344,11 +344,11 @@
344
345	The common counterargument is that collapsed check-ins represent a
346	better world, the ideal we're striving for. What that argument overlooks
347	is that we must throw away valuable information to get there.
348
349	### <a name="empathy"></a>6.1 Individual check-ins support mutual understanding
350
351	Ideally, future developers of our software can understand every feature
352	in it using only context available in the version of the code they start
353	work with. Prior to widespread version control, developers had no choice
354	but to work that way. Pre-existing codebases could only be understood
	@@ -389,11 +389,11 @@
389	that collapses a whole branch's worth of changes down to a single
390	finished feature.
391
392	[sdm]: ./fossil-v-git.wiki#durable
393
394	### <a name="bisecting"></a>6.2 Bisecting works better on small check-ins
395
396	Git lets a developer write a feature in ten check-ins but collapse it
397	down to an eleventh check-in and then deliberately push only that final
398	collapsed check-in to the parent repo. Someone else may then do a bisect
399	that blames the merged check-in as the source of the problem they’re
	@@ -404,11 +404,11 @@
404	An equivalent push in Fossil will send all 11 check-ins to the parent
405	repository so that a later investigator doing the same sort of bisect
406	sees the complete check-in history. That bisect will point the
407	investigator at the single original check-in that caused the problem.
408
409	### <a name="comments"></a>6.3 Multiple check-ins require multiple check-in comments
410
411	The more comments you have from a given developer on a given body of
412	code, the more concise documentation you have of that developer's
413	thought process. To resume the bisecting example, a developer trying to
414	work out what the original developer was thinking with a given change
	@@ -416,11 +416,11 @@
416	one check-in out of ten blamed by the "bisect" command was trying to
417	accomplish than if they must work that out from the eleventh check-in's
418	comment, which only explains the "clean" version of the collapsed
419	feature.
420
421	### <a name="cherrypicking"></a>6.4 Cherry-picks work better with small check-ins
422
423	While working on a new feature in one branch, you may come across a bug
424	in the pre-existing code that you need to fix in order for work on that
425	feature to proceed. You could choose to switch briefly back to the
426	parent branch, develop the fix there, check it in, then merge the parent
	@@ -458,20 +458,20 @@
458	branch. Even if they manage to do their work without error, it takes
459	them more time to do the cherry-pick that way.
460
461	[rh]: https://en.wikipedia.org/wiki/Red_Hat
462
463	### <a name="backouts"></a>6.5 Back-outs also work better with small check-ins
464
465	The inverse of the cherry-pick merge is the back-out merge. If you push
466	only a collapsed version of a private working branch up to the parent
467	repo, those working from that parent repo cannot automatically back out
468	any of the individual check-ins that went into that private branch.
469	Others must either manually disentangle the problematic part of your
470	merge check-in or back out the entire feature.
471
472	## <a name="better-plan"></a>7.0 Cherry-pick merges work better than rebase
473
474	Perhaps there are some cases where a rebase-like transformation
475	is actually helpful, but those cases are rare, and when they do
476	come up, running a series of cherry-pick merges achieves the same
477	topology with several advantages:
	@@ -501,11 +501,11 @@
501	3. Cherry-picks keep both the original and the revised check-ins,
502	so both timestamps are preserved.
503
504	[tbc]: ./fossil-v-git.wiki#testing
505
506	## <a name="conclusion"></a>8.0 Summary and conclusion
507
508	Rebasing is an anti-pattern. It is dishonest. It deliberately
509	omits historical information. It causes problems for collaboration.
510	And it has no offsetting benefits.
511
512

	--- www/rebaseharm.md
	+++ www/rebaseharm.md
	@@ -14,19 +14,19 @@
14	[golden rule of rebasing][golden]: never rebase on a public
15	branch. Horror stories of misused rebase abound, and the rebase
16	documentation devotes considerable space toward explaining how to
17	recover from rebase errors and/or misuse.
18
19	## <a id="cap-loss"></a>2.0 Rebase provides no new capabilities
20
21	Sometimes sharp and dangerous tools are justified,
22	because they accomplish things that cannot be
23	done otherwise, or at least cannot be done easily.
24	Rebase does not fall into that category,
25	because it provides no new capabilities.
26
27	### <a id="orphaning"></a>2.1 A rebase is just a merge with historical references omitted
28
29	A rebase is really nothing more than a merge (or a series of merges)
30	that deliberately forgets one of the parents of each merge step.
31	To help illustrate this fact,
32	consider the first rebase example from the
	@@ -88,11 +88,11 @@
88	not overwhelm the weak history display mechanisms available in Git.
89	Wouldn't it be better, less error-prone, and easier on users
90	to enhance the history display mechanisms in Git so that rebasing
91	for a clean, linear history became unnecessary?
92
93	### <a id="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs
94
95	Another argument, often cited, is that rebasing a feature branch
96	allows one to see just the changes in the feature branch without
97	the concurrent changes in the main line of development.
98	Consider a hypothetical case:
	@@ -212,11 +212,11 @@
212
213	So, to help with the problem of viewing changes associated with a feature
214	branch, perhaps what is needed is not rebase but rather better tools to
215	help users identify an appropriate baseline for their diffs.
216
217	## <a id="siloing"></a>3.0 Rebase encourages siloed development
218
219	The [golden rule of rebasing][golden] is that you should never do it
220	on public branches, so if you are using rebase as intended, that means
221	you are keeping private branches. Or, to put it another way, you are
222	doing siloed development. You are not sharing your intermediate work
	@@ -251,11 +251,11 @@
251	while they're still isolated on a feature branch, or should that vetting
252	wait until you finally push a collapsed version of a private working
253	branch to the parent repo? Will the many eyeballs even see those errors
254	when they’re intermingled with code implementing some compelling new feature?
255
256	## <a id="timestamps"></a>4.0 Rebase causes timestamp confusion
257
258	Consider the earlier example of rebasing a feature branch:
259
260	~~~ pikchr toggle
261	# Copy of second diagram in section 2.2 above
	@@ -293,11 +293,11 @@
293	unique timestamps for C3' and C5' but then you lose the information
294	about when those check-ins were originally created, which can make
295	historical analysis of changes more difficult. It might also
296	complicate the legal defense of prior art claims.
297
298	## <a id="lying"></a>5.0 Rebase misrepresents the project history
299
300	By discarding parentage information, rebase attempts to deceive the
301	reader about how the code actually came together.
302
303	Git’s rebase feature is more than just an
	@@ -329,11 +329,11 @@
329	why Git lacks support for making editorial changes to check-ins without
330	modifying history? Wouldn't it be better to fix the version control
331	tool rather than requiring users to fabricate a fictitious project
332	history?
333
334	## <a id="collapsing"></a>6.0 Collapsing check-ins throws away valuable information
335
336	One of the oft-cited advantages of rebasing in Git is that it lets you
337	collapse multiple check-ins down to a single check-in to make the
338	development history “clean.” The intent is that development appear as
339	though every feature were created in a single step: no multi-step
	@@ -344,11 +344,11 @@
344
345	The common counterargument is that collapsed check-ins represent a
346	better world, the ideal we're striving for. What that argument overlooks
347	is that we must throw away valuable information to get there.
348
349	### <a id="empathy"></a>6.1 Individual check-ins support mutual understanding
350
351	Ideally, future developers of our software can understand every feature
352	in it using only context available in the version of the code they start
353	work with. Prior to widespread version control, developers had no choice
354	but to work that way. Pre-existing codebases could only be understood
	@@ -389,11 +389,11 @@
389	that collapses a whole branch's worth of changes down to a single
390	finished feature.
391
392	[sdm]: ./fossil-v-git.wiki#durable
393
394	### <a id="bisecting"></a>6.2 Bisecting works better on small check-ins
395
396	Git lets a developer write a feature in ten check-ins but collapse it
397	down to an eleventh check-in and then deliberately push only that final
398	collapsed check-in to the parent repo. Someone else may then do a bisect
399	that blames the merged check-in as the source of the problem they’re
	@@ -404,11 +404,11 @@
404	An equivalent push in Fossil will send all 11 check-ins to the parent
405	repository so that a later investigator doing the same sort of bisect
406	sees the complete check-in history. That bisect will point the
407	investigator at the single original check-in that caused the problem.
408
409	### <a id="comments"></a>6.3 Multiple check-ins require multiple check-in comments
410
411	The more comments you have from a given developer on a given body of
412	code, the more concise documentation you have of that developer's
413	thought process. To resume the bisecting example, a developer trying to
414	work out what the original developer was thinking with a given change
	@@ -416,11 +416,11 @@
416	one check-in out of ten blamed by the "bisect" command was trying to
417	accomplish than if they must work that out from the eleventh check-in's
418	comment, which only explains the "clean" version of the collapsed
419	feature.
420
421	### <a id="cherrypicking"></a>6.4 Cherry-picks work better with small check-ins
422
423	While working on a new feature in one branch, you may come across a bug
424	in the pre-existing code that you need to fix in order for work on that
425	feature to proceed. You could choose to switch briefly back to the
426	parent branch, develop the fix there, check it in, then merge the parent
	@@ -458,20 +458,20 @@
458	branch. Even if they manage to do their work without error, it takes
459	them more time to do the cherry-pick that way.
460
461	[rh]: https://en.wikipedia.org/wiki/Red_Hat
462
463	### <a id="backouts"></a>6.5 Back-outs also work better with small check-ins
464
465	The inverse of the cherry-pick merge is the back-out merge. If you push
466	only a collapsed version of a private working branch up to the parent
467	repo, those working from that parent repo cannot automatically back out
468	any of the individual check-ins that went into that private branch.
469	Others must either manually disentangle the problematic part of your
470	merge check-in or back out the entire feature.
471
472	## <a id="better-plan"></a>7.0 Cherry-pick merges work better than rebase
473
474	Perhaps there are some cases where a rebase-like transformation
475	is actually helpful, but those cases are rare, and when they do
476	come up, running a series of cherry-pick merges achieves the same
477	topology with several advantages:
	@@ -501,11 +501,11 @@
501	3. Cherry-picks keep both the original and the revised check-ins,
502	so both timestamps are preserved.
503
504	[tbc]: ./fossil-v-git.wiki#testing
505
506	## <a id="conclusion"></a>8.0 Summary and conclusion
507
508	Rebasing is an anti-pattern. It is dishonest. It deliberately
509	omits historical information. It causes problems for collaboration.
510	And it has no offsetting benefits.
511
512

M www/server/any/stunnel.md

+4 -2

		--- www/server/any/stunnel.md
		+++ www/server/any/stunnel.md
		@@ -10,11 +10,11 @@
10	10	You can run `stunnel` in one of two modes: socket listener — much like
11	11	in our [`inetd` doc](./inetd.md) — and as an HTTP reverse proxy. We’ll
12	12	cover both cases here, separately.
13	13
14	14
15		-## S<a name="sa"></a>ocket Activation
	15	+## <a id="sa"></a>Socket Activation
16	16
17	17	The following `stunnel.conf` configuration configures it to run Fossil
18	18	in socket listener mode, launching Fossil only when an HTTPS hit comes
19	19	in, then shutting it back down as soon as the transaction is complete:
20	20
		@@ -47,11 +47,11 @@
47	47	configuration include the `--https` option to let Fossil know to use
48	48	“`https://`” instead of “`http://`” in generated hyperlinks.
49	49
50	50
51	51
52		-## <a name="proxy"></a>Reverse Proxy
	52	+## <a id="proxy"></a>Reverse Proxy
53	53
54	54	You can instead have Fossil running in the background in [standalone
55	55	HTTP server mode](./none.md), bound to a high random TCP port number on
56	56	localhost via the `--localhost` and `--port` flags, then configure
57	57	`stunnel` to reverse proxy public HTTPS connections down to it via HTTP.
		@@ -75,5 +75,7 @@
75	75
76	76	2. The socket listener mode doesn’t work on all platforms that
77	77	`stunnel` runs on, particularly [on Windows](../windows/stunnel.md).
78	78
79	79	[Return to the top-level Fossil server article.](../)
	80	+
	81	+<div style="height:50em" id="this-space-intentionally-left-blank"></div>
80	82

	--- www/server/any/stunnel.md
	+++ www/server/any/stunnel.md
	@@ -10,11 +10,11 @@
10	You can run `stunnel` in one of two modes: socket listener — much like
11	in our [`inetd` doc](./inetd.md) — and as an HTTP reverse proxy. We’ll
12	cover both cases here, separately.
13
14
15	## S<a name="sa"></a>ocket Activation
16
17	The following `stunnel.conf` configuration configures it to run Fossil
18	in socket listener mode, launching Fossil only when an HTTPS hit comes
19	in, then shutting it back down as soon as the transaction is complete:
20
	@@ -47,11 +47,11 @@
47	configuration include the `--https` option to let Fossil know to use
48	“`https://`” instead of “`http://`” in generated hyperlinks.
49
50
51
52	## <a name="proxy"></a>Reverse Proxy
53
54	You can instead have Fossil running in the background in [standalone
55	HTTP server mode](./none.md), bound to a high random TCP port number on
56	localhost via the `--localhost` and `--port` flags, then configure
57	`stunnel` to reverse proxy public HTTPS connections down to it via HTTP.
	@@ -75,5 +75,7 @@
75
76	2. The socket listener mode doesn’t work on all platforms that
77	`stunnel` runs on, particularly [on Windows](../windows/stunnel.md).
78
79	[Return to the top-level Fossil server article.](../)


80

	--- www/server/any/stunnel.md
	+++ www/server/any/stunnel.md
	@@ -10,11 +10,11 @@
10	You can run `stunnel` in one of two modes: socket listener — much like
11	in our [`inetd` doc](./inetd.md) — and as an HTTP reverse proxy. We’ll
12	cover both cases here, separately.
13
14
15	## <a id="sa"></a>Socket Activation
16
17	The following `stunnel.conf` configuration configures it to run Fossil
18	in socket listener mode, launching Fossil only when an HTTPS hit comes
19	in, then shutting it back down as soon as the transaction is complete:
20
	@@ -47,11 +47,11 @@
47	configuration include the `--https` option to let Fossil know to use
48	“`https://`” instead of “`http://`” in generated hyperlinks.
49
50
51
52	## <a id="proxy"></a>Reverse Proxy
53
54	You can instead have Fossil running in the background in [standalone
55	HTTP server mode](./none.md), bound to a high random TCP port number on
56	localhost via the `--localhost` and `--port` flags, then configure
57	`stunnel` to reverse proxy public HTTPS connections down to it via HTTP.
	@@ -75,5 +75,7 @@
75
76	2. The socket listener mode doesn’t work on all platforms that
77	`stunnel` runs on, particularly [on Windows](../windows/stunnel.md).
78
79	[Return to the top-level Fossil server article.](../)
80
81	<div style="height:50em" id="this-space-intentionally-left-blank"></div>
82

M www/server/debian/nginx.md

+9 -9

		--- www/server/debian/nginx.md
		+++ www/server/debian/nginx.md
		@@ -16,11 +16,11 @@
16	16
17	17	[scgii]: ../any/scgi.md
18	18	[vps]: https://en.wikipedia.org/wiki/Virtual_private_server
19	19
20	20
21		-## <a name="benefits"></a>Benefits
	21	+## <a id="benefits"></a>Benefits
22	22
23	23	This scheme is considerably more complicated than the [standalone HTTP
24	24	server](../any/none.md) and [CGI options](../any/cgi.md). Even with the
25	25	benefit of this guide and pre-built binary packages, it requires quite a
26	26	bit of work to set it up. Why should you put up with this complexity?
		@@ -59,11 +59,11 @@
59	59
60	60	* Availability — nginx is already in most operating system binary
61	61	package repositories, so you don’t need to go out of your way to get it.
62	62
63	63
64		-## <a name="modes"></a>Fossil Service Modes
	64	+## <a id="modes"></a>Fossil Service Modes
65	65
66	66	Fossil provides four major ways to access a repository it’s serving
67	67	remotely, three of which are straightforward to use with nginx:
68	68
69	69	* HTTP — Fossil has [a built-in HTTP server](../any/none.md).
		@@ -94,11 +94,11 @@
94	94	SCGI it is, then.
95	95
96	96	[scgip]: https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
97	97
98	98
99		-## <a name="deps"></a>Installing the Dependencies
	99	+## <a id="deps"></a>Installing the Dependencies
100	100
101	101	The first step is to install some non-default packages we’ll need. SSH into
102	102	your server, then say:
103	103
104	104	$ sudo apt install fossil nginx
		@@ -106,11 +106,11 @@
106	106	You can leave “`fossil`” out of that if you’re building Fossil from
107	107	source to get a more up-to-date version than is shipped with the host
108	108	OS.
109	109
110	110
111		-## <a name="scgi"></a>Running Fossil in SCGI Mode
	111	+## <a id="scgi"></a>Running Fossil in SCGI Mode
112	112
113	113	For the following nginx configuration to work, it needs to contact a
114	114	Fossil instance speaking the SCGI protocol. There are [many ways](../)
115	115	to set that up. For Debian type systems, we recommend
116	116	following [our systemd system service guide](service.md).
		@@ -118,11 +118,11 @@
118	118	There are other ways to arrange for Fossil to run as a service backing
119	119	nginx, but however you do it, you need to match up the TCP port numbers between it
120	120	and those in the nginx configuration below.
121	121
122	122
123		-## <a name="config"></a>Configuration
	123	+## <a id="config"></a>Configuration
124	124
125	125	On Debian and Ubuntu systems the primary user-level configuration file
126	126	for nginx is `/etc/nginx/sites-enabled/default`. I recommend that this
127	127	file contain only a list of include statements, one for each site that
128	128	server hosts:
		@@ -194,11 +194,11 @@
194	194	The configuration for `foo.net` is similar.
195	195
196	196	See [the nginx docs](https://nginx.org/en/docs/) for more ideas.
197	197
198	198
199		-## <a name="http"></a>Proxying HTTP Anyway
	199	+## <a id="http"></a>Proxying HTTP Anyway
200	200
201	201	[Above](#modes), we argued that proxying SCGI is a better option than
202	202	making nginx reinterpret Fossil’s own implementation of HTTP. If you
203	203	want Fossil to speak HTTP, just [set Fossil up as a standalone
204	204	server](../any/none.md). And if you want nginx to [provide TLS
		@@ -218,11 +218,11 @@
218	218	like this is to get the slashes wrong. Fossil is sensitive to this. For
219	219	instance, Fossil will not collapse double slashes down to a single
220	220	slash, as some other HTTP servers will.
221	221
222	222
223		-## <a name="large-uv"></a> Allowing Large Unversioned Files
	223	+## <a id="large-uv"></a> Allowing Large Unversioned Files
224	224
225	225	By default, nginx only accepts HTTP messages [up to a
226	226	meg](http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)
227	227	in size. Fossil chunks its sync protocol such that this is not normally
228	228	a problem, but when sending [unversioned content][uv], it uses a single
		@@ -234,11 +234,11 @@
234	234	client_max_body_size 20M;
235	235
236	236	[uv]: ../../unvers.wiki
237	237
238	238
239		-## <a name="fail2ban"></a> Integrating `fail2ban`
	239	+## <a id="fail2ban"></a> Integrating `fail2ban`
240	240
241	241	One of the nice things that falls out of proxying Fossil behind nginx is
242	242	that it makes it easier to configure `fail2ban` to recognize attacks on
243	243	Fossil and automatically block them. Fossil logs the sorts of errors we
244	244	want to detect, but it does so in places like the repository’s admin
		@@ -279,11 +279,11 @@
279	279
280	280
281	281	[dof2b]: https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04
282	282
283	283
284		-## <a name="tls"></a> Adding TLS (HTTPS) Support
	284	+## <a id="tls"></a> Adding TLS (HTTPS) Support
285	285
286	286	One of the [many ways](../../ssl.wiki) to provide TLS-encrypted HTTP access
287	287	(a.k.a. HTTPS) to Fossil is to run it behind a web proxy that supports
288	288	TLS. One such option is nginx on Debian, so we show the details of that
289	289	here.
290	290

	--- www/server/debian/nginx.md
	+++ www/server/debian/nginx.md
	@@ -16,11 +16,11 @@
16
17	[scgii]: ../any/scgi.md
18	[vps]: https://en.wikipedia.org/wiki/Virtual_private_server
19
20
21	## <a name="benefits"></a>Benefits
22
23	This scheme is considerably more complicated than the [standalone HTTP
24	server](../any/none.md) and [CGI options](../any/cgi.md). Even with the
25	benefit of this guide and pre-built binary packages, it requires quite a
26	bit of work to set it up. Why should you put up with this complexity?
	@@ -59,11 +59,11 @@
59
60	* Availability — nginx is already in most operating system binary
61	package repositories, so you don’t need to go out of your way to get it.
62
63
64	## <a name="modes"></a>Fossil Service Modes
65
66	Fossil provides four major ways to access a repository it’s serving
67	remotely, three of which are straightforward to use with nginx:
68
69	* HTTP — Fossil has [a built-in HTTP server](../any/none.md).
	@@ -94,11 +94,11 @@
94	SCGI it is, then.
95
96	[scgip]: https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
97
98
99	## <a name="deps"></a>Installing the Dependencies
100
101	The first step is to install some non-default packages we’ll need. SSH into
102	your server, then say:
103
104	$ sudo apt install fossil nginx
	@@ -106,11 +106,11 @@
106	You can leave “`fossil`” out of that if you’re building Fossil from
107	source to get a more up-to-date version than is shipped with the host
108	OS.
109
110
111	## <a name="scgi"></a>Running Fossil in SCGI Mode
112
113	For the following nginx configuration to work, it needs to contact a
114	Fossil instance speaking the SCGI protocol. There are [many ways](../)
115	to set that up. For Debian type systems, we recommend
116	following [our systemd system service guide](service.md).
	@@ -118,11 +118,11 @@
118	There are other ways to arrange for Fossil to run as a service backing
119	nginx, but however you do it, you need to match up the TCP port numbers between it
120	and those in the nginx configuration below.
121
122
123	## <a name="config"></a>Configuration
124
125	On Debian and Ubuntu systems the primary user-level configuration file
126	for nginx is `/etc/nginx/sites-enabled/default`. I recommend that this
127	file contain only a list of include statements, one for each site that
128	server hosts:
	@@ -194,11 +194,11 @@
194	The configuration for `foo.net` is similar.
195
196	See [the nginx docs](https://nginx.org/en/docs/) for more ideas.
197
198
199	## <a name="http"></a>Proxying HTTP Anyway
200
201	[Above](#modes), we argued that proxying SCGI is a better option than
202	making nginx reinterpret Fossil’s own implementation of HTTP. If you
203	want Fossil to speak HTTP, just [set Fossil up as a standalone
204	server](../any/none.md). And if you want nginx to [provide TLS
	@@ -218,11 +218,11 @@
218	like this is to get the slashes wrong. Fossil is sensitive to this. For
219	instance, Fossil will not collapse double slashes down to a single
220	slash, as some other HTTP servers will.
221
222
223	## <a name="large-uv"></a> Allowing Large Unversioned Files
224
225	By default, nginx only accepts HTTP messages [up to a
226	meg](http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)
227	in size. Fossil chunks its sync protocol such that this is not normally
228	a problem, but when sending [unversioned content][uv], it uses a single
	@@ -234,11 +234,11 @@
234	client_max_body_size 20M;
235
236	[uv]: ../../unvers.wiki
237
238
239	## <a name="fail2ban"></a> Integrating `fail2ban`
240
241	One of the nice things that falls out of proxying Fossil behind nginx is
242	that it makes it easier to configure `fail2ban` to recognize attacks on
243	Fossil and automatically block them. Fossil logs the sorts of errors we
244	want to detect, but it does so in places like the repository’s admin
	@@ -279,11 +279,11 @@
279
280
281	[dof2b]: https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04
282
283
284	## <a name="tls"></a> Adding TLS (HTTPS) Support
285
286	One of the [many ways](../../ssl.wiki) to provide TLS-encrypted HTTP access
287	(a.k.a. HTTPS) to Fossil is to run it behind a web proxy that supports
288	TLS. One such option is nginx on Debian, so we show the details of that
289	here.
290

	--- www/server/debian/nginx.md
	+++ www/server/debian/nginx.md
	@@ -16,11 +16,11 @@
16
17	[scgii]: ../any/scgi.md
18	[vps]: https://en.wikipedia.org/wiki/Virtual_private_server
19
20
21	## <a id="benefits"></a>Benefits
22
23	This scheme is considerably more complicated than the [standalone HTTP
24	server](../any/none.md) and [CGI options](../any/cgi.md). Even with the
25	benefit of this guide and pre-built binary packages, it requires quite a
26	bit of work to set it up. Why should you put up with this complexity?
	@@ -59,11 +59,11 @@
59
60	* Availability — nginx is already in most operating system binary
61	package repositories, so you don’t need to go out of your way to get it.
62
63
64	## <a id="modes"></a>Fossil Service Modes
65
66	Fossil provides four major ways to access a repository it’s serving
67	remotely, three of which are straightforward to use with nginx:
68
69	* HTTP — Fossil has [a built-in HTTP server](../any/none.md).
	@@ -94,11 +94,11 @@
94	SCGI it is, then.
95
96	[scgip]: https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
97
98
99	## <a id="deps"></a>Installing the Dependencies
100
101	The first step is to install some non-default packages we’ll need. SSH into
102	your server, then say:
103
104	$ sudo apt install fossil nginx
	@@ -106,11 +106,11 @@
106	You can leave “`fossil`” out of that if you’re building Fossil from
107	source to get a more up-to-date version than is shipped with the host
108	OS.
109
110
111	## <a id="scgi"></a>Running Fossil in SCGI Mode
112
113	For the following nginx configuration to work, it needs to contact a
114	Fossil instance speaking the SCGI protocol. There are [many ways](../)
115	to set that up. For Debian type systems, we recommend
116	following [our systemd system service guide](service.md).
	@@ -118,11 +118,11 @@
118	There are other ways to arrange for Fossil to run as a service backing
119	nginx, but however you do it, you need to match up the TCP port numbers between it
120	and those in the nginx configuration below.
121
122
123	## <a id="config"></a>Configuration
124
125	On Debian and Ubuntu systems the primary user-level configuration file
126	for nginx is `/etc/nginx/sites-enabled/default`. I recommend that this
127	file contain only a list of include statements, one for each site that
128	server hosts:
	@@ -194,11 +194,11 @@
194	The configuration for `foo.net` is similar.
195
196	See [the nginx docs](https://nginx.org/en/docs/) for more ideas.
197
198
199	## <a id="http"></a>Proxying HTTP Anyway
200
201	[Above](#modes), we argued that proxying SCGI is a better option than
202	making nginx reinterpret Fossil’s own implementation of HTTP. If you
203	want Fossil to speak HTTP, just [set Fossil up as a standalone
204	server](../any/none.md). And if you want nginx to [provide TLS
	@@ -218,11 +218,11 @@
218	like this is to get the slashes wrong. Fossil is sensitive to this. For
219	instance, Fossil will not collapse double slashes down to a single
220	slash, as some other HTTP servers will.
221
222
223	## <a id="large-uv"></a> Allowing Large Unversioned Files
224
225	By default, nginx only accepts HTTP messages [up to a
226	meg](http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)
227	in size. Fossil chunks its sync protocol such that this is not normally
228	a problem, but when sending [unversioned content][uv], it uses a single
	@@ -234,11 +234,11 @@
234	client_max_body_size 20M;
235
236	[uv]: ../../unvers.wiki
237
238
239	## <a id="fail2ban"></a> Integrating `fail2ban`
240
241	One of the nice things that falls out of proxying Fossil behind nginx is
242	that it makes it easier to configure `fail2ban` to recognize attacks on
243	Fossil and automatically block them. Fossil logs the sorts of errors we
244	want to detect, but it does so in places like the repository’s admin
	@@ -279,11 +279,11 @@
279
280
281	[dof2b]: https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04
282
283
284	## <a id="tls"></a> Adding TLS (HTTPS) Support
285
286	One of the [many ways](../../ssl.wiki) to provide TLS-encrypted HTTP access
287	(a.k.a. HTTPS) to Fossil is to run it behind a web proxy that supports
288	TLS. One such option is nginx on Debian, so we show the details of that
289	here.
290

M www/server/openbsd/fastcgi.md

+6 -6

		--- www/server/openbsd/fastcgi.md
		+++ www/server/openbsd/fastcgi.md
		@@ -12,11 +12,11 @@
12	12
13	13	NOTE: The following instructions assume an OpenBSD 6.7 installation.
14	14
15	15	[httpd]: https://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf
16	16
17		-## <a name="fslinstall"></a>Install Fossil
	17	+## <a id="fslinstall"></a>Install Fossil
18	18
19	19	Use the OpenBSD package manager `pkg_add` to install Fossil, making sure
20	20	to select the statically linked binary.
21	21
22	22	```console
		@@ -62,11 +62,11 @@
62	62	$ doas chown www /var/www/logs/fossil.log
63	63	$ doas chmod 660 /var/www/logs/fossil.log
64	64	$ doas chmod 755 /var/www/cgi-bin/scm
65	65	```
66	66
67		-## <a name="chroot"></a>Setup chroot
	67	+## <a id="chroot"></a>Setup chroot
68	68
69	69	Fossil needs both `/dev/random` and `/dev/null`, which aren't accessible
70	70	from within the chroot, so need to be constructed; `/var`, however, is
71	71	mounted with the `nodev` option. Rather than removing this default
72	72	setting, create a small memory filesystem and then mount it on to
		@@ -108,11 +108,11 @@
108	108	```console
109	109	$ doas chown -R user:www /var/www/htdocs/fsl.domain.tld
110	110	$ doas chmod 770 /var/www/htdocs/fsl.domain.tld
111	111	```
112	112
113		-## <a name="httpdconfig"></a>Configure httpd
	113	+## <a id="httpdconfig"></a>Configure httpd
114	114
115	115	On OpenBSD, [httpd.conf(5)][httpd] is the configuration file for
116	116	`httpd`. To setup the server to serve all Fossil repositores within the
117	117	directory specified in the CGI script, and automatically redirect
118	118	standard HTTP requests to HTTPS—apart from [Let's Encrypt][LE]
		@@ -178,11 +178,11 @@
178	178	out the `https` server block and proceed to securing a free
179	179	[Let's Encrypt Certificate](#letsencrypt); otherwise skip to
180	180	[Start `httpd`](#starthttpd).
181	181
182	182
183		-## <a name="letsencrypt"></a>Let's Encrypt Certificate
	183	+## <a id="letsencrypt"></a>Let's Encrypt Certificate
184	184
185	185	In order for `httpd` to serve HTTPS, secure a free certificate from
186	186	Let's Encrypt using `acme-client`. Before issuing the request, however,
187	187	ensure you have a zone record for the subdomain with your registrar or
188	188	nameserver. Then open `/etc/acme-client.conf` as a privileged user to
		@@ -239,11 +239,11 @@
239	239	```
240	240
241	241	Make sure to reopen `/etc/httpd.conf` to uncomment the second server
242	242	block responsible for serving HTTPS requests before proceeding.
243	243
244		-## <a name="starthttpd"></a>Start `httpd`
	244	+## <a id="starthttpd"></a>Start `httpd`
245	245
246	246	With `httpd` configured to serve Fossil repositories out of
247	247	`/var/www/htdocs/fsl.domain.tld`, and the certificates and key in place,
248	248	enable and start `slowcgi`—OpenBSD's FastCGI wrapper server that will
249	249	execute the above Fossil CGI script—before checking that the syntax of
		@@ -258,11 +258,11 @@
258	258	configuration OK
259	259	$ doas rcctl start httpd
260	260	httpd(ok)
261	261	```
262	262
263		-## <a name="clientconfig"></a>Configure Client
	263	+## <a id="clientconfig"></a>Configure Client
264	264
265	265	To facilitate creating new repositories and pushing them to the server,
266	266	add the following function to your `~/.cshrc` or `~/.zprofile` or the
267	267	config file for whichever shell you are using on your development box.
268	268
269	269

	--- www/server/openbsd/fastcgi.md
	+++ www/server/openbsd/fastcgi.md
	@@ -12,11 +12,11 @@
12
13	NOTE: The following instructions assume an OpenBSD 6.7 installation.
14
15	[httpd]: https://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf
16
17	## <a name="fslinstall"></a>Install Fossil
18
19	Use the OpenBSD package manager `pkg_add` to install Fossil, making sure
20	to select the statically linked binary.
21
22	```console
	@@ -62,11 +62,11 @@
62	$ doas chown www /var/www/logs/fossil.log
63	$ doas chmod 660 /var/www/logs/fossil.log
64	$ doas chmod 755 /var/www/cgi-bin/scm
65	```
66
67	## <a name="chroot"></a>Setup chroot
68
69	Fossil needs both `/dev/random` and `/dev/null`, which aren't accessible
70	from within the chroot, so need to be constructed; `/var`, however, is
71	mounted with the `nodev` option. Rather than removing this default
72	setting, create a small memory filesystem and then mount it on to
	@@ -108,11 +108,11 @@
108	```console
109	$ doas chown -R user:www /var/www/htdocs/fsl.domain.tld
110	$ doas chmod 770 /var/www/htdocs/fsl.domain.tld
111	```
112
113	## <a name="httpdconfig"></a>Configure httpd
114
115	On OpenBSD, [httpd.conf(5)][httpd] is the configuration file for
116	`httpd`. To setup the server to serve all Fossil repositores within the
117	directory specified in the CGI script, and automatically redirect
118	standard HTTP requests to HTTPS—apart from [Let's Encrypt][LE]
	@@ -178,11 +178,11 @@
178	out the `https` server block and proceed to securing a free
179	[Let's Encrypt Certificate](#letsencrypt); otherwise skip to
180	[Start `httpd`](#starthttpd).
181
182
183	## <a name="letsencrypt"></a>Let's Encrypt Certificate
184
185	In order for `httpd` to serve HTTPS, secure a free certificate from
186	Let's Encrypt using `acme-client`. Before issuing the request, however,
187	ensure you have a zone record for the subdomain with your registrar or
188	nameserver. Then open `/etc/acme-client.conf` as a privileged user to
	@@ -239,11 +239,11 @@
239	```
240
241	Make sure to reopen `/etc/httpd.conf` to uncomment the second server
242	block responsible for serving HTTPS requests before proceeding.
243
244	## <a name="starthttpd"></a>Start `httpd`
245
246	With `httpd` configured to serve Fossil repositories out of
247	`/var/www/htdocs/fsl.domain.tld`, and the certificates and key in place,
248	enable and start `slowcgi`—OpenBSD's FastCGI wrapper server that will
249	execute the above Fossil CGI script—before checking that the syntax of
	@@ -258,11 +258,11 @@
258	configuration OK
259	$ doas rcctl start httpd
260	httpd(ok)
261	```
262
263	## <a name="clientconfig"></a>Configure Client
264
265	To facilitate creating new repositories and pushing them to the server,
266	add the following function to your `~/.cshrc` or `~/.zprofile` or the
267	config file for whichever shell you are using on your development box.
268
269

	--- www/server/openbsd/fastcgi.md
	+++ www/server/openbsd/fastcgi.md
	@@ -12,11 +12,11 @@
12
13	NOTE: The following instructions assume an OpenBSD 6.7 installation.
14
15	[httpd]: https://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf
16
17	## <a id="fslinstall"></a>Install Fossil
18
19	Use the OpenBSD package manager `pkg_add` to install Fossil, making sure
20	to select the statically linked binary.
21
22	```console
	@@ -62,11 +62,11 @@
62	$ doas chown www /var/www/logs/fossil.log
63	$ doas chmod 660 /var/www/logs/fossil.log
64	$ doas chmod 755 /var/www/cgi-bin/scm
65	```
66
67	## <a id="chroot"></a>Setup chroot
68
69	Fossil needs both `/dev/random` and `/dev/null`, which aren't accessible
70	from within the chroot, so need to be constructed; `/var`, however, is
71	mounted with the `nodev` option. Rather than removing this default
72	setting, create a small memory filesystem and then mount it on to
	@@ -108,11 +108,11 @@
108	```console
109	$ doas chown -R user:www /var/www/htdocs/fsl.domain.tld
110	$ doas chmod 770 /var/www/htdocs/fsl.domain.tld
111	```
112
113	## <a id="httpdconfig"></a>Configure httpd
114
115	On OpenBSD, [httpd.conf(5)][httpd] is the configuration file for
116	`httpd`. To setup the server to serve all Fossil repositores within the
117	directory specified in the CGI script, and automatically redirect
118	standard HTTP requests to HTTPS—apart from [Let's Encrypt][LE]
	@@ -178,11 +178,11 @@
178	out the `https` server block and proceed to securing a free
179	[Let's Encrypt Certificate](#letsencrypt); otherwise skip to
180	[Start `httpd`](#starthttpd).
181
182
183	## <a id="letsencrypt"></a>Let's Encrypt Certificate
184
185	In order for `httpd` to serve HTTPS, secure a free certificate from
186	Let's Encrypt using `acme-client`. Before issuing the request, however,
187	ensure you have a zone record for the subdomain with your registrar or
188	nameserver. Then open `/etc/acme-client.conf` as a privileged user to
	@@ -239,11 +239,11 @@
239	```
240
241	Make sure to reopen `/etc/httpd.conf` to uncomment the second server
242	block responsible for serving HTTPS requests before proceeding.
243
244	## <a id="starthttpd"></a>Start `httpd`
245
246	With `httpd` configured to serve Fossil repositories out of
247	`/var/www/htdocs/fsl.domain.tld`, and the certificates and key in place,
248	enable and start `slowcgi`—OpenBSD's FastCGI wrapper server that will
249	execute the above Fossil CGI script—before checking that the syntax of
	@@ -258,11 +258,11 @@
258	configuration OK
259	$ doas rcctl start httpd
260	httpd(ok)
261	```
262
263	## <a id="clientconfig"></a>Configure Client
264
265	To facilitate creating new repositories and pushing them to the server,
266	add the following function to your `~/.cshrc` or `~/.zprofile` or the
267	config file for whichever shell you are using on your development box.
268
269

M www/server/windows/iis.md

+1 -1

		--- www/server/windows/iis.md
		+++ www/server/windows/iis.md
		@@ -43,11 +43,11 @@
43	43	For a more robust setup, we recommend that you [install Fossil as a
44	44	Windows service](./service.md), which will allow Fossil to start at
45	45	system boot, before anyone has logged in interactively.
46	46
47	47
48		-## <a name="install"></a>Install IIS
	48	+## <a id="install"></a>Install IIS
49	49
50	50	IIS might not be installed in your system yet, so follow the path
51	51	appropriate to your host OS. We’ve tested only the latest Microsoft
52	52	OSes as of the time of this writing, but the basic process should be
53	53	similar on older OSes.
54	54

	--- www/server/windows/iis.md
	+++ www/server/windows/iis.md
	@@ -43,11 +43,11 @@
43	For a more robust setup, we recommend that you [install Fossil as a
44	Windows service](./service.md), which will allow Fossil to start at
45	system boot, before anyone has logged in interactively.
46
47
48	## <a name="install"></a>Install IIS
49
50	IIS might not be installed in your system yet, so follow the path
51	appropriate to your host OS. We’ve tested only the latest Microsoft
52	OSes as of the time of this writing, but the basic process should be
53	similar on older OSes.
54

	--- www/server/windows/iis.md
	+++ www/server/windows/iis.md
	@@ -43,11 +43,11 @@
43	For a more robust setup, we recommend that you [install Fossil as a
44	Windows service](./service.md), which will allow Fossil to start at
45	system boot, before anyone has logged in interactively.
46
47
48	## <a id="install"></a>Install IIS
49
50	IIS might not be installed in your system yet, so follow the path
51	appropriate to your host OS. We’ve tested only the latest Microsoft
52	OSes as of the time of this writing, but the basic process should be
53	similar on older OSes.
54

M www/server/windows/service.md

+2 -2

		--- www/server/windows/service.md
		+++ www/server/windows/service.md
		@@ -46,12 +46,12 @@
46	46
47	47	```
48	48	fossil winsrv create --repository D:/Path/to/Repos --repolist
49	49	```
50	50
51		-<a name='PowerShell'></a>
52		-### Advanced service installation using PowerShell
	51	+
	52	+### <a id='PowerShell'></a>Advanced service installation using PowerShell
53	53
54	54	As great as `fossil winsrv` is, it does not have one to one reflection of all of
55	55	the `fossil server` [options](/help?cmd=server). When you need to use some of
56	56	the more advanced options, such as `--https`, `--skin`, or `--extroot`, you will
57	57	need to use PowerShell to configure and install the Windows service.
58	58

	--- www/server/windows/service.md
	+++ www/server/windows/service.md
	@@ -46,12 +46,12 @@
46
47	```
48	fossil winsrv create --repository D:/Path/to/Repos --repolist
49	```
50
51	<a name='PowerShell'></a>
52	### Advanced service installation using PowerShell
53
54	As great as `fossil winsrv` is, it does not have one to one reflection of all of
55	the `fossil server` [options](/help?cmd=server). When you need to use some of
56	the more advanced options, such as `--https`, `--skin`, or `--extroot`, you will
57	need to use PowerShell to configure and install the Windows service.
58

	--- www/server/windows/service.md
	+++ www/server/windows/service.md
	@@ -46,12 +46,12 @@
46
47	```
48	fossil winsrv create --repository D:/Path/to/Repos --repolist
49	```
50
51
52	### <a id='PowerShell'></a>Advanced service installation using PowerShell
53
54	As great as `fossil winsrv` is, it does not have one to one reflection of all of
55	the `fossil server` [options](/help?cmd=server). When you need to use some of
56	the more advanced options, such as `--https`, `--skin`, or `--extroot`, you will
57	need to use PowerShell to configure and install the Windows service.
58

M www/server/windows/stunnel.md

+1 -1

		--- www/server/windows/stunnel.md
		+++ www/server/windows/stunnel.md
		@@ -107,11 +107,11 @@
107	107	Export-PfxCertificate -FilePath fossil-scm.pfx -Password $passwd
108	108	```
109	109
110	110	You will now have your certificate stored as a PFX file.
111	111
112		-<a name="convert"></a>
	112	+<a id="convert"></a>
113	113	### Convert Certificate from PFX to PEM
114	114
115	115	For this step you will need the openssl tools that were installed with stunnel.
116	116
117	117	```PowerShell
118	118

	--- www/server/windows/stunnel.md
	+++ www/server/windows/stunnel.md
	@@ -107,11 +107,11 @@
107	Export-PfxCertificate -FilePath fossil-scm.pfx -Password $passwd
108	```
109
110	You will now have your certificate stored as a PFX file.
111
112	<a name="convert"></a>
113	### Convert Certificate from PFX to PEM
114
115	For this step you will need the openssl tools that were installed with stunnel.
116
117	```PowerShell
118

	--- www/server/windows/stunnel.md
	+++ www/server/windows/stunnel.md
	@@ -107,11 +107,11 @@
107	Export-PfxCertificate -FilePath fossil-scm.pfx -Password $passwd
108	```
109
110	You will now have your certificate stored as a PFX file.
111
112	<a id="convert"></a>
113	### Convert Certificate from PFX to PEM
114
115	For this step you will need the openssl tools that were installed with stunnel.
116
117	```PowerShell
118

M www/sync.wiki

+1 -2

		--- www/sync.wiki
		+++ www/sync.wiki
		@@ -30,12 +30,11 @@
30	30	an administrator can sync local state using
31	31	the [/help?cmd=configuration\|config push] and
32	32	[/help?cmd=configuration\|config pull]
33	33	commands.
34	34
35		-<a name="crdt"></a>
36		-<h3>1.1 Conflict-Free Replicated Datatypes</h3>
	35	+<h3 id="crdt">1.1 Conflict-Free Replicated Datatypes</h3>
37	36
38	37	<p>The "bag of artifacts" data model used by Fossil
39	38	Fossil is apparently an implementation of a particular
40	39	[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|Conflict-Free Replicated
41	40	Datatype (CRDT)]
42	41

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -30,12 +30,11 @@
30	an administrator can sync local state using
31	the [/help?cmd=configuration\|config push] and
32	[/help?cmd=configuration\|config pull]
33	commands.
34
35	<a name="crdt"></a>
36	<h3>1.1 Conflict-Free Replicated Datatypes</h3>
37
38	<p>The "bag of artifacts" data model used by Fossil
39	Fossil is apparently an implementation of a particular
40	[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|Conflict-Free Replicated
41	Datatype (CRDT)]
42

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -30,12 +30,11 @@
30	an administrator can sync local state using
31	the [/help?cmd=configuration\|config push] and
32	[/help?cmd=configuration\|config pull]
33	commands.
34
35	<h3 id="crdt">1.1 Conflict-Free Replicated Datatypes</h3>

36
37	<p>The "bag of artifacts" data model used by Fossil
38	Fossil is apparently an implementation of a particular
39	[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type\|Conflict-Free Replicated
40	Datatype (CRDT)]
41

M www/tech_overview.wiki

+3 -6

		--- www/tech_overview.wiki
		+++ www/tech_overview.wiki
		@@ -105,12 +105,11 @@
105	105	</ul>
106	106	</td>
107	107	</tr>
108	108	</table>
109	109
110		-<a name='configdb'></a>
111		-<h3>2.1 The Configuration Database</h3>
	110	+<h3 id="configdb">2.1 The Configuration Database</h3>
112	111
113	112	The configuration database holds cross-repository preferences and a list of all
114	113	repositories for a single user.
115	114
116	115	The [/help/settings \| fossil settings] command can be used to specify various
		@@ -125,12 +124,11 @@
125	124
126	125	The configuration database also maintains a list of repositories. This
127	126	list is used by the [/help/all \| fossil all] command in order to run various
128	127	operations such as "sync" or "rebuild" on all repositories managed by a user.
129	128
130		-<a name='configloc'></a>
131		-<h4>2.1.1 Location Of The Configuration Database</h4>
	129	+<h4 id="configloc">2.1.1 Location Of The Configuration Database</h4>
132	130
133	131	On Unix systems, the configuration database is named by the following
134	132	algorithm:
135	133
136	134	<blockquote><table border="0">
		@@ -329,12 +327,11 @@
329	327
330	328	The shun table can be pushed or pulled using
331	329	the [/help/config \| fossil config] command with the "shun" AREA argument.
332	330	The shun table is also copied during a [/help/clone \| clone].
333	331
334		-<a name='localdb'></a>
335		-<h3>2.3 Checkout Databases</h3>
	332	+<h3 id="localdb">2.3 Checkout Databases</h3>
336	333
337	334	Fossil allows a single repository
338	335	to have multiple working checkouts. Each working checkout has a single
339	336	database in its root directory that records the state of that checkout.
340	337	The checkout database is named "_FOSSIL_" or ".fslckout".
341	338

	--- www/tech_overview.wiki
	+++ www/tech_overview.wiki
	@@ -105,12 +105,11 @@
105	</ul>
106	</td>
107	</tr>
108	</table>
109
110	<a name='configdb'></a>
111	<h3>2.1 The Configuration Database</h3>
112
113	The configuration database holds cross-repository preferences and a list of all
114	repositories for a single user.
115
116	The [/help/settings \| fossil settings] command can be used to specify various
	@@ -125,12 +124,11 @@
125
126	The configuration database also maintains a list of repositories. This
127	list is used by the [/help/all \| fossil all] command in order to run various
128	operations such as "sync" or "rebuild" on all repositories managed by a user.
129
130	<a name='configloc'></a>
131	<h4>2.1.1 Location Of The Configuration Database</h4>
132
133	On Unix systems, the configuration database is named by the following
134	algorithm:
135
136	<blockquote><table border="0">
	@@ -329,12 +327,11 @@
329
330	The shun table can be pushed or pulled using
331	the [/help/config \| fossil config] command with the "shun" AREA argument.
332	The shun table is also copied during a [/help/clone \| clone].
333
334	<a name='localdb'></a>
335	<h3>2.3 Checkout Databases</h3>
336
337	Fossil allows a single repository
338	to have multiple working checkouts. Each working checkout has a single
339	database in its root directory that records the state of that checkout.
340	The checkout database is named "_FOSSIL_" or ".fslckout".
341

	--- www/tech_overview.wiki
	+++ www/tech_overview.wiki
	@@ -105,12 +105,11 @@
105	</ul>
106	</td>
107	</tr>
108	</table>
109
110	<h3 id="configdb">2.1 The Configuration Database</h3>

111
112	The configuration database holds cross-repository preferences and a list of all
113	repositories for a single user.
114
115	The [/help/settings \| fossil settings] command can be used to specify various
	@@ -125,12 +124,11 @@
124
125	The configuration database also maintains a list of repositories. This
126	list is used by the [/help/all \| fossil all] command in order to run various
127	operations such as "sync" or "rebuild" on all repositories managed by a user.
128
129	<h4 id="configloc">2.1.1 Location Of The Configuration Database</h4>

130
131	On Unix systems, the configuration database is named by the following
132	algorithm:
133
134	<blockquote><table border="0">
	@@ -329,12 +327,11 @@
327
328	The shun table can be pushed or pulled using
329	the [/help/config \| fossil config] command with the "shun" AREA argument.
330	The shun table is also copied during a [/help/clone \| clone].
331
332	<h3 id="localdb">2.3 Checkout Databases</h3>

333
334	Fossil allows a single repository
335	to have multiple working checkouts. Each working checkout has a single
336	database in its root directory that records the state of that checkout.
337	The checkout database is named "_FOSSIL_" or ".fslckout".
338

M www/th1-hooks.md

+7 -7

		--- www/th1-hooks.md
		+++ www/th1-hooks.md
		@@ -36,11 +36,11 @@
36	36
37	37	* web\_name -- _Name of web page being rendered._
38	38	* web\_args -- _Current web page arguments._
39	39	* web\_flags -- _Bitmask of CMDFLAG values for the web page being rendered._
40	40
41		-<a name="cmdReturnCodes"></a>TH1 Hook Related Return Codes for Commands
	41	+<a id="cmdReturnCodes"></a>TH1 Hook Related Return Codes for Commands
42	42	-----------------------------------------------------------------------
43	43
44	44	* TH\_OK -- _Command will be executed, notification will be executed._
45	45	* TH\_ERROR -- _Command will be skipped, notification will be skipped,
46	46	error message will be emitted._
		@@ -51,11 +51,11 @@
51	51	For commands that are not included in the Fossil binary, allowing their
52	52	execution will cause the standard "unknown command" error message to be
53	53	generated, which will typically exit the process. Therefore, adding a
54	54	new command generally requires using the TH_CONTINUE return code.
55	55
56		-<a name="webReturnCodes"></a>TH1 Hook Related Return Codes for Web Pages
	56	+<a id="webReturnCodes"></a>TH1 Hook Related Return Codes for Web Pages
57	57	------------------------------------------------------------------------
58	58
59	59	* TH\_OK -- _Web page will be rendered, notification will be executed._
60	60	* TH\_ERROR -- _Web page will be skipped, notification will be skipped,
61	61	error message will be emitted._
		@@ -66,20 +66,20 @@
66	66	For web pages that are not included in the Fossil binary, allowing their
67	67	rendering will cause the standard "Not Found" error message to be generated,
68	68	which will cause an HTTP 404 status code to be sent. Therefore, adding a
69	69	new web page generally requires using the TH_CONTINUE return code.
70	70
71		-<a name="triggerReturnCodes"></a>Triggering TH1 Return Codes from a Script
	71	+<a id="triggerReturnCodes"></a>Triggering TH1 Return Codes from a Script
72	72	--------------------------------------------------------------------------
73	73
74	74	* TH\_OK -- _This is the default return code, nothing special needed._
75	75	* TH\_ERROR -- _Use the error command._
76	76	* TH\_BREAK -- _Use the break command._
77	77	* TH\_RETURN -- _Use the return -code 5 command._
78	78	* TH\_CONTINUE -- _Use the continue command._
79	79
80		-<a name="command_hook"></a>TH1 command_hook Procedure
	80	+<a id="command_hook"></a>TH1 command_hook Procedure
81	81	-----------------------------------------------------
82	82
83	83	* command\_hook
84	84
85	85	This user-defined procedure, if present, is called just before the
		@@ -89,11 +89,11 @@
89	89	The associated CMDFLAG value will be stored in the "cmd\_flags" global
90	90	variable. Before exiting, the procedure should trigger the return
91	91	<a href="#cmdReturnCodes">code</a> that corresponds to the desired action
92	92	to take next.
93	93
94		-<a name="command_notify"></a>TH1 command_notify Procedure
	94	+<a id="command_notify"></a>TH1 command_notify Procedure
95	95	---------------------------------------------------------
96	96
97	97	* command\_notify
98	98
99	99	This user-defined procedure, if present, is called just after the
		@@ -103,11 +103,11 @@
103	103	The associated CMDFLAG value will be stored in the "cmd\_flags" global
104	104	variable. Before exiting, the procedure should trigger the return
105	105	<a href="#cmdReturnCodes">code</a> that corresponds to the desired action
106	106	to take next.
107	107
108		-<a name="webpage_hook"></a>TH1 webpage_hook Procedure
	108	+<a id="webpage_hook"></a>TH1 webpage_hook Procedure
109	109	-----------------------------------------------------
110	110
111	111	* webpage\_hook
112	112
113	113	This user-defined procedure, if present, is called just before the
		@@ -117,11 +117,11 @@
117	117	The associated CMDFLAG value will be stored in the "web\_flags" global
118	118	variable. Before exiting, the procedure should trigger the return
119	119	<a href="#webReturnCodes">code</a> that corresponds to the desired action
120	120	to take next.
121	121
122		-<a name="webpage_notify"></a>TH1 webpage_notify Procedure
	122	+<a id="webpage_notify"></a>TH1 webpage_notify Procedure
123	123	---------------------------------------------------------
124	124
125	125	* webpage\_notify
126	126
127	127	This user-defined procedure, if present, is called just after the
128	128

	--- www/th1-hooks.md
	+++ www/th1-hooks.md
	@@ -36,11 +36,11 @@
36
37	* web\_name -- _Name of web page being rendered._
38	* web\_args -- _Current web page arguments._
39	* web\_flags -- _Bitmask of CMDFLAG values for the web page being rendered._
40
41	<a name="cmdReturnCodes"></a>TH1 Hook Related Return Codes for Commands
42	-----------------------------------------------------------------------
43
44	* TH\_OK -- _Command will be executed, notification will be executed._
45	* TH\_ERROR -- _Command will be skipped, notification will be skipped,
46	error message will be emitted._
	@@ -51,11 +51,11 @@
51	For commands that are not included in the Fossil binary, allowing their
52	execution will cause the standard "unknown command" error message to be
53	generated, which will typically exit the process. Therefore, adding a
54	new command generally requires using the TH_CONTINUE return code.
55
56	<a name="webReturnCodes"></a>TH1 Hook Related Return Codes for Web Pages
57	------------------------------------------------------------------------
58
59	* TH\_OK -- _Web page will be rendered, notification will be executed._
60	* TH\_ERROR -- _Web page will be skipped, notification will be skipped,
61	error message will be emitted._
	@@ -66,20 +66,20 @@
66	For web pages that are not included in the Fossil binary, allowing their
67	rendering will cause the standard "Not Found" error message to be generated,
68	which will cause an HTTP 404 status code to be sent. Therefore, adding a
69	new web page generally requires using the TH_CONTINUE return code.
70
71	<a name="triggerReturnCodes"></a>Triggering TH1 Return Codes from a Script
72	--------------------------------------------------------------------------
73
74	* TH\_OK -- _This is the default return code, nothing special needed._
75	* TH\_ERROR -- _Use the error command._
76	* TH\_BREAK -- _Use the break command._
77	* TH\_RETURN -- _Use the return -code 5 command._
78	* TH\_CONTINUE -- _Use the continue command._
79
80	<a name="command_hook"></a>TH1 command_hook Procedure
81	-----------------------------------------------------
82
83	* command\_hook
84
85	This user-defined procedure, if present, is called just before the
	@@ -89,11 +89,11 @@
89	The associated CMDFLAG value will be stored in the "cmd\_flags" global
90	variable. Before exiting, the procedure should trigger the return
91	<a href="#cmdReturnCodes">code</a> that corresponds to the desired action
92	to take next.
93
94	<a name="command_notify"></a>TH1 command_notify Procedure
95	---------------------------------------------------------
96
97	* command\_notify
98
99	This user-defined procedure, if present, is called just after the
	@@ -103,11 +103,11 @@
103	The associated CMDFLAG value will be stored in the "cmd\_flags" global
104	variable. Before exiting, the procedure should trigger the return
105	<a href="#cmdReturnCodes">code</a> that corresponds to the desired action
106	to take next.
107
108	<a name="webpage_hook"></a>TH1 webpage_hook Procedure
109	-----------------------------------------------------
110
111	* webpage\_hook
112
113	This user-defined procedure, if present, is called just before the
	@@ -117,11 +117,11 @@
117	The associated CMDFLAG value will be stored in the "web\_flags" global
118	variable. Before exiting, the procedure should trigger the return
119	<a href="#webReturnCodes">code</a> that corresponds to the desired action
120	to take next.
121
122	<a name="webpage_notify"></a>TH1 webpage_notify Procedure
123	---------------------------------------------------------
124
125	* webpage\_notify
126
127	This user-defined procedure, if present, is called just after the
128

	--- www/th1-hooks.md
	+++ www/th1-hooks.md
	@@ -36,11 +36,11 @@
36
37	* web\_name -- _Name of web page being rendered._
38	* web\_args -- _Current web page arguments._
39	* web\_flags -- _Bitmask of CMDFLAG values for the web page being rendered._
40
41	<a id="cmdReturnCodes"></a>TH1 Hook Related Return Codes for Commands
42	-----------------------------------------------------------------------
43
44	* TH\_OK -- _Command will be executed, notification will be executed._
45	* TH\_ERROR -- _Command will be skipped, notification will be skipped,
46	error message will be emitted._
	@@ -51,11 +51,11 @@
51	For commands that are not included in the Fossil binary, allowing their
52	execution will cause the standard "unknown command" error message to be
53	generated, which will typically exit the process. Therefore, adding a
54	new command generally requires using the TH_CONTINUE return code.
55
56	<a id="webReturnCodes"></a>TH1 Hook Related Return Codes for Web Pages
57	------------------------------------------------------------------------
58
59	* TH\_OK -- _Web page will be rendered, notification will be executed._
60	* TH\_ERROR -- _Web page will be skipped, notification will be skipped,
61	error message will be emitted._
	@@ -66,20 +66,20 @@
66	For web pages that are not included in the Fossil binary, allowing their
67	rendering will cause the standard "Not Found" error message to be generated,
68	which will cause an HTTP 404 status code to be sent. Therefore, adding a
69	new web page generally requires using the TH_CONTINUE return code.
70
71	<a id="triggerReturnCodes"></a>Triggering TH1 Return Codes from a Script
72	--------------------------------------------------------------------------
73
74	* TH\_OK -- _This is the default return code, nothing special needed._
75	* TH\_ERROR -- _Use the error command._
76	* TH\_BREAK -- _Use the break command._
77	* TH\_RETURN -- _Use the return -code 5 command._
78	* TH\_CONTINUE -- _Use the continue command._
79
80	<a id="command_hook"></a>TH1 command_hook Procedure
81	-----------------------------------------------------
82
83	* command\_hook
84
85	This user-defined procedure, if present, is called just before the
	@@ -89,11 +89,11 @@
89	The associated CMDFLAG value will be stored in the "cmd\_flags" global
90	variable. Before exiting, the procedure should trigger the return
91	<a href="#cmdReturnCodes">code</a> that corresponds to the desired action
92	to take next.
93
94	<a id="command_notify"></a>TH1 command_notify Procedure
95	---------------------------------------------------------
96
97	* command\_notify
98
99	This user-defined procedure, if present, is called just after the
	@@ -103,11 +103,11 @@
103	The associated CMDFLAG value will be stored in the "cmd\_flags" global
104	variable. Before exiting, the procedure should trigger the return
105	<a href="#cmdReturnCodes">code</a> that corresponds to the desired action
106	to take next.
107
108	<a id="webpage_hook"></a>TH1 webpage_hook Procedure
109	-----------------------------------------------------
110
111	* webpage\_hook
112
113	This user-defined procedure, if present, is called just before the
	@@ -117,11 +117,11 @@
117	The associated CMDFLAG value will be stored in the "web\_flags" global
118	variable. Before exiting, the procedure should trigger the return
119	<a href="#webReturnCodes">code</a> that corresponds to the desired action
120	to take next.
121
122	<a id="webpage_notify"></a>TH1 webpage_notify Procedure
123	---------------------------------------------------------
124
125	* webpage\_notify
126
127	This user-defined procedure, if present, is called just after the
128

M www/whyusefossil.wiki

+1 -2

		--- www/whyusefossil.wiki
		+++ www/whyusefossil.wiki
		@@ -37,12 +37,11 @@
37	37	<li>Avoid wasting time doing manual file copying
38	38	<li>Avoid human errors during manual backups
39	39	</ol>
40	40	</ol>
41	41
42		-<a name='definitions'></a>
43		-<p><b>II. Definitions</b></p>
	42	+<p id="definitions"><b>II. Definitions</b></p>
44	43
45	44	<ul>
46	45	<li><p><b>Project</b> →
47	46	a collection of computer files that serve some common
48	47	purpose. Often the project is a software application and the
49	48

	--- www/whyusefossil.wiki
	+++ www/whyusefossil.wiki
	@@ -37,12 +37,11 @@
37	<li>Avoid wasting time doing manual file copying
38	<li>Avoid human errors during manual backups
39	</ol>
40	</ol>
41
42	<a name='definitions'></a>
43	<p><b>II. Definitions</b></p>
44
45	<ul>
46	<li><p><b>Project</b> →
47	a collection of computer files that serve some common
48	purpose. Often the project is a software application and the
49

	--- www/whyusefossil.wiki
	+++ www/whyusefossil.wiki
	@@ -37,12 +37,11 @@
37	<li>Avoid wasting time doing manual file copying
38	<li>Avoid human errors during manual backups
39	</ol>
40	</ol>
41
42	<p id="definitions"><b>II. Definitions</b></p>

43
44	<ul>
45	<li><p><b>Project</b> →
46	a collection of computer files that serve some common
47	purpose. Often the project is a software application and the
48

M www/wikitheory.wiki

+1 -2

		--- www/wikitheory.wiki
		+++ www/wikitheory.wiki
		@@ -65,12 +65,11 @@
65	65	The comments on check-ins and the text in the descriptions of bug reports
66	66	both use wiki formatting. Exactly the same set of formatting rules apply.
67	67	There is never a need to learn one formatting language for documentation
68	68	and a different markup for bugs or for check-in comments.
69	69
70		-<a name="assocwiki"></a>
71		-<h2>Auxiliary notes attached to check-ins or branches</h2>
	70	+<h2 id="assocwiki">Auxiliary notes attached to check-ins or branches</h2>
72	71
73	72	Stand-alone wiki pages with special names "branch/<i>BRANCHNAME</i>"
74	73	or "checkin/<i>HASH</i>" are associated with the corresponding
75	74	branch or check-in. The wiki text appears in an "About" section of
76	75	timelines and info screens. Examples:
77	76

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -65,12 +65,11 @@
65	The comments on check-ins and the text in the descriptions of bug reports
66	both use wiki formatting. Exactly the same set of formatting rules apply.
67	There is never a need to learn one formatting language for documentation
68	and a different markup for bugs or for check-in comments.
69
70	<a name="assocwiki"></a>
71	<h2>Auxiliary notes attached to check-ins or branches</h2>
72
73	Stand-alone wiki pages with special names "branch/<i>BRANCHNAME</i>"
74	or "checkin/<i>HASH</i>" are associated with the corresponding
75	branch or check-in. The wiki text appears in an "About" section of
76	timelines and info screens. Examples:
77

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -65,12 +65,11 @@
65	The comments on check-ins and the text in the descriptions of bug reports
66	both use wiki formatting. Exactly the same set of formatting rules apply.
67	There is never a need to learn one formatting language for documentation
68	and a different markup for bugs or for check-in comments.
69
70	<h2 id="assocwiki">Auxiliary notes attached to check-ins or branches</h2>

71
72	Stand-alone wiki pages with special names "branch/<i>BRANCHNAME</i>"
73	or "checkin/<i>HASH</i>" are associated with the corresponding
74	branch or check-in. The wiki text appears in an "About" section of
75	timelines and info screens. Examples:
76

Fossil SCM

Keyboard Shortcuts