a3be0b80ceb… — Fossil SCM

M www/caps/index.md

+1 -1

		--- www/caps/index.md
		+++ www/caps/index.md
		@@ -294,11 +294,11 @@
294	294	Fossil requires write access to a repo DB while cloning from it, so you
295	295	can’t clone from a read-only repo DB file over a local file path.
296	296
297	297	Even more surprising to you may be the fact that user caps do not affect
298	298	cloning and syncing over SSH! (Not unless you go [out of your way][sshfc]
299		-patch around it, at any rate.) When you make a change to such a
	299	+to patch around it, at any rate.) When you make a change to such a
300	300	repository, the stock Fossil behavior is that the change first goes to the
301	301	local repo clone where file system
302	302	permissions are all that matter, but then upon sync, the situation is
303	303	effectively the same as when the parent repo is on the local file
304	304	system. The reason behind this is that if you can log into the remote
305	305

	--- www/caps/index.md
	+++ www/caps/index.md
	@@ -294,11 +294,11 @@
294	Fossil requires write access to a repo DB while cloning from it, so you
295	can’t clone from a read-only repo DB file over a local file path.
296
297	Even more surprising to you may be the fact that user caps do not affect
298	cloning and syncing over SSH! (Not unless you go [out of your way][sshfc]
299	patch around it, at any rate.) When you make a change to such a
300	repository, the stock Fossil behavior is that the change first goes to the
301	local repo clone where file system
302	permissions are all that matter, but then upon sync, the situation is
303	effectively the same as when the parent repo is on the local file
304	system. The reason behind this is that if you can log into the remote
305

	--- www/caps/index.md
	+++ www/caps/index.md
	@@ -294,11 +294,11 @@
294	Fossil requires write access to a repo DB while cloning from it, so you
295	can’t clone from a read-only repo DB file over a local file path.
296
297	Even more surprising to you may be the fact that user caps do not affect
298	cloning and syncing over SSH! (Not unless you go [out of your way][sshfc]
299	to patch around it, at any rate.) When you make a change to such a
300	repository, the stock Fossil behavior is that the change first goes to the
301	local repo clone where file system
302	permissions are all that matter, but then upon sync, the situation is
303	effectively the same as when the parent repo is on the local file
304	system. The reason behind this is that if you can log into the remote
305

M www/custom_ticket.wiki

+8 -6

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

	--- www/custom_ticket.wiki
	+++ www/custom_ticket.wiki
	@@ -82,16 +82,18 @@
82
83	Look for the text "Contact:" (about halfway through). Then insert these lines
84	after the closing tr tag and before the "enable_output" line:
85
86	<verbatim>
87	<td align="right">Assigned to:</td><td bgcolor="#d0d0d0">
88	$<assigned_to>
89	</td>
90	<td align="right">Opened by:</td><td bgcolor="#d0d0d0">
91	$<opened_by>
92	</td>


93	</verbatim>
94
95	This will add a row which displays these two fields, in the event the user has
96	<a href="./caps/ref.html#w">ticket "edit" capability</a>.
97
98

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

M www/json-api/api-artifact.md

+1 -1

		--- www/json-api/api-artifact.md
		+++ www/json-api/api-artifact.md
		@@ -71,11 +71,11 @@
71	71	# File Artifacts
72	72
73	73	Fetches information about file artifacts.
74	74
75	75	FIXME: the content type guessing is currently very primitive, and
76		-may (but i haven't seen this) mis-diagnose some non-binary files as
	76	+may (but I haven't seen this) mis-diagnose some non-binary files as
77	77	binary. Fossil doesn't yet have a mechanism for mime-type mappings.
78	78
79	79	Status: implemented 20111020
80	80
81	81	Required permissions: "o"
82	82

	--- www/json-api/api-artifact.md
	+++ www/json-api/api-artifact.md
	@@ -71,11 +71,11 @@
71	# File Artifacts
72
73	Fetches information about file artifacts.
74
75	FIXME: the content type guessing is currently very primitive, and
76	may (but i haven't seen this) mis-diagnose some non-binary files as
77	binary. Fossil doesn't yet have a mechanism for mime-type mappings.
78
79	Status: implemented 20111020
80
81	Required permissions: "o"
82

	--- www/json-api/api-artifact.md
	+++ www/json-api/api-artifact.md
	@@ -71,11 +71,11 @@
71	# File Artifacts
72
73	Fetches information about file artifacts.
74
75	FIXME: the content type guessing is currently very primitive, and
76	may (but I haven't seen this) mis-diagnose some non-binary files as
77	binary. Fossil doesn't yet have a mechanism for mime-type mappings.
78
79	Status: implemented 20111020
80
81	Required permissions: "o"
82

M www/json-api/api-auth.md

+3 -3

		--- www/json-api/api-auth.md
		+++ www/json-api/api-auth.md
		@@ -33,11 +33,11 @@
33	33	purposes, the "auth token" and the "login cookie" are the same thing (or
34	34	serve the same purpose), and the auth token is in fact just the value
35	35	part of the login cookie (which has a project-specific key).
36	36
37	37	Note that fossil has two conventional user names which can show up in
38		-various response but do not refer to specific people: nobody and
	38	+various responses but do not refer to specific people: nobody and
39	39	anonymous. The nobody user is anyone who is not logged in. The anonymous
40	40	user is logged in but has no persistent user data (no associated user
41	41	name, email address, or similar). Normally the guest (nobody) user has
42	42	more access restrictions. The distinction between the two is largely
43	43	historical - it is a mechanism to keep bots from following the
		@@ -158,11 +158,11 @@
158	158	tickets is disabled for the guest user then all non-guest users must
159	159	send authentication info in their requests in order to be able to fetch
160	160	ticket info.
161	161
162	162	Cookie-aware clients should send the login-generated cookie with each
163		-request, in which case they do not need explicitly include the
	163	+request, in which case they do not need to explicitly include the
164	164	`authToken` in the JSON envelope/GET arguments. If submitted, the
165	165	`authToken` is used, otherwise the cookie, if set, is used. Note that
166	166	fossil uses a project-dependent cookie name in order to help thwart
167	167	attacks, so there is no simple mapping of cookie name to auth
168	168	token. That said, the cookie's value is also the auth token's value.
		@@ -200,11 +200,11 @@
200	200
201	201	The password value may be time-limited, and may eventually become
202	202	invalidated due to old age. This is unspecified.
203	203
204	204	*Potential* (low-probability) bug regarding the seed value: from
205		-what i hear, some unusual JSON platforms don't support full 32-bit
	205	+what I hear, some unusual JSON platforms don't support full 32-bit
206	206	precision. If absolutely necessary we could chop off a bit or two from
207	207	the seed value (if it ever becomes a problem and if DRH blesses it).
208	208	Or we could just make it a double.
209	209
210	210
211	211

	--- www/json-api/api-auth.md
	+++ www/json-api/api-auth.md
	@@ -33,11 +33,11 @@
33	purposes, the "auth token" and the "login cookie" are the same thing (or
34	serve the same purpose), and the auth token is in fact just the value
35	part of the login cookie (which has a project-specific key).
36
37	Note that fossil has two conventional user names which can show up in
38	various response but do not refer to specific people: nobody and
39	anonymous. The nobody user is anyone who is not logged in. The anonymous
40	user is logged in but has no persistent user data (no associated user
41	name, email address, or similar). Normally the guest (nobody) user has
42	more access restrictions. The distinction between the two is largely
43	historical - it is a mechanism to keep bots from following the
	@@ -158,11 +158,11 @@
158	tickets is disabled for the guest user then all non-guest users must
159	send authentication info in their requests in order to be able to fetch
160	ticket info.
161
162	Cookie-aware clients should send the login-generated cookie with each
163	request, in which case they do not need explicitly include the
164	`authToken` in the JSON envelope/GET arguments. If submitted, the
165	`authToken` is used, otherwise the cookie, if set, is used. Note that
166	fossil uses a project-dependent cookie name in order to help thwart
167	attacks, so there is no simple mapping of cookie name to auth
168	token. That said, the cookie's value is also the auth token's value.
	@@ -200,11 +200,11 @@
200
201	The password value may be time-limited, and may eventually become
202	invalidated due to old age. This is unspecified.
203
204	*Potential* (low-probability) bug regarding the seed value: from
205	what i hear, some unusual JSON platforms don't support full 32-bit
206	precision. If absolutely necessary we could chop off a bit or two from
207	the seed value (if it ever becomes a problem and if DRH blesses it).
208	Or we could just make it a double.
209
210
211

	--- www/json-api/api-auth.md
	+++ www/json-api/api-auth.md
	@@ -33,11 +33,11 @@
33	purposes, the "auth token" and the "login cookie" are the same thing (or
34	serve the same purpose), and the auth token is in fact just the value
35	part of the login cookie (which has a project-specific key).
36
37	Note that fossil has two conventional user names which can show up in
38	various responses but do not refer to specific people: nobody and
39	anonymous. The nobody user is anyone who is not logged in. The anonymous
40	user is logged in but has no persistent user data (no associated user
41	name, email address, or similar). Normally the guest (nobody) user has
42	more access restrictions. The distinction between the two is largely
43	historical - it is a mechanism to keep bots from following the
	@@ -158,11 +158,11 @@
158	tickets is disabled for the guest user then all non-guest users must
159	send authentication info in their requests in order to be able to fetch
160	ticket info.
161
162	Cookie-aware clients should send the login-generated cookie with each
163	request, in which case they do not need to explicitly include the
164	`authToken` in the JSON envelope/GET arguments. If submitted, the
165	`authToken` is used, otherwise the cookie, if set, is used. Note that
166	fossil uses a project-dependent cookie name in order to help thwart
167	attacks, so there is no simple mapping of cookie name to auth
168	token. That said, the cookie's value is also the auth token's value.
	@@ -200,11 +200,11 @@
200
201	The password value may be time-limited, and may eventually become
202	invalidated due to old age. This is unspecified.
203
204	*Potential* (low-probability) bug regarding the seed value: from
205	what I hear, some unusual JSON platforms don't support full 32-bit
206	precision. If absolutely necessary we could chop off a bit or two from
207	the seed value (if it ever becomes a problem and if DRH blesses it).
208	Or we could just make it a double.
209
210
211

M www/json-api/api-checkout.md

+1 -1

		--- www/json-api/api-checkout.md
		+++ www/json-api/api-checkout.md
		@@ -7,11 +7,11 @@
7	7
8	8	Required permissions: n/a (local access only)
9	9
10	10	Request: `/json/status`
11	11
12		-This command requires a local checkout and is analog to the "fossil
	12	+This command requires a local checkout and is the analog to the "fossil
13	13	status" command.
14	14
15	15	Request Options: currently none.
16	16
17	17	Payload example:
18	18

	--- www/json-api/api-checkout.md
	+++ www/json-api/api-checkout.md
	@@ -7,11 +7,11 @@
7
8	Required permissions: n/a (local access only)
9
10	Request: `/json/status`
11
12	This command requires a local checkout and is analog to the "fossil
13	status" command.
14
15	Request Options: currently none.
16
17	Payload example:
18

	--- www/json-api/api-checkout.md
	+++ www/json-api/api-checkout.md
	@@ -7,11 +7,11 @@
7
8	Required permissions: n/a (local access only)
9
10	Request: `/json/status`
11
12	This command requires a local checkout and is the analog to the "fossil
13	status" command.
14
15	Request Options: currently none.
16
17	Payload example:
18

M www/json-api/api-finfo.md

+1 -1

		--- www/json-api/api-finfo.md
		+++ www/json-api/api-finfo.md
		@@ -20,11 +20,11 @@
20	20	as opposed to listing all checkins. If set, neither "before" nor
21	21	"after" have any effect.\
22	22	CLI mode: `--checkin\|-ci`
23	23	- `before=DATETIME` only lists checkins from on or before this time.\
24	24	CLI mode: `--before\|-b`
25		-- `after=DATETIME` only lists checkins from on or before this time.
	25	+- `after=DATETIME` only lists checkins from on or after this time.
26	26	Using this option swaps the sort order, to provide reasonable
27	27	behaviour in conjunction with the limit option.\
28	28	Only one of "before" and "after" may be specified, and if both are
29	29	specified then which one takes precedence is unspecified.\
30	30	CLI mode: `--after\|-a`
31	31

	--- www/json-api/api-finfo.md
	+++ www/json-api/api-finfo.md
	@@ -20,11 +20,11 @@
20	as opposed to listing all checkins. If set, neither "before" nor
21	"after" have any effect.\
22	CLI mode: `--checkin\|-ci`
23	- `before=DATETIME` only lists checkins from on or before this time.\
24	CLI mode: `--before\|-b`
25	- `after=DATETIME` only lists checkins from on or before this time.
26	Using this option swaps the sort order, to provide reasonable
27	behaviour in conjunction with the limit option.\
28	Only one of "before" and "after" may be specified, and if both are
29	specified then which one takes precedence is unspecified.\
30	CLI mode: `--after\|-a`
31

	--- www/json-api/api-finfo.md
	+++ www/json-api/api-finfo.md
	@@ -20,11 +20,11 @@
20	as opposed to listing all checkins. If set, neither "before" nor
21	"after" have any effect.\
22	CLI mode: `--checkin\|-ci`
23	- `before=DATETIME` only lists checkins from on or before this time.\
24	CLI mode: `--before\|-b`
25	- `after=DATETIME` only lists checkins from on or after this time.
26	Using this option swaps the sort order, to provide reasonable
27	behaviour in conjunction with the limit option.\
28	Only one of "before" and "after" may be specified, and if both are
29	specified then which one takes precedence is unspecified.\
30	CLI mode: `--after\|-a`
31

M www/json-api/api-query.md

+2 -2

		--- www/json-api/api-query.md
		+++ www/json-api/api-query.md
		@@ -60,11 +60,11 @@
60	60	…
61	61	]
62	62	}
63	63	```
64	64
65		-The column names are provided in a separate field is because their order
	65	+The column names are provided in a separate field because their order
66	66	is guaranteed to match the order of the query columns, whereas object
67	67	key/value pairs might get reordered (typically sorted by key) when
68	68	travelling through different JSON implementations. In this manner,
69	69	clients can e.g. be sure to render the columns in the proper
70	70	(query-specified) order.
		@@ -76,10 +76,10 @@
76	76
77	77	Note the column names are never guaranteed to be exactly as they
78	78	appear in the SQL unless they are qualified with an AS, e.g. `SELECT
79	79	foo AS foo...`. When generating reports which need fixed column names, it
80	80	is highly recommended to use an AS qualifier for every column, even if
81		-they use the same name as the column. This is the only way to guaranty
	81	+they use the same name as the column. This is the only way to guarantee
82	82	that the result column names will be stable. (FYI: that behaviour comes
83	83	from sqlite3, not the JSON bits, and this behaviour has been known to
84	84	change between sqlite3 versions (so this is not just an idle threat of
85	85	potential future incompatibility).)
86	86

	--- www/json-api/api-query.md
	+++ www/json-api/api-query.md
	@@ -60,11 +60,11 @@
60	…
61	]
62	}
63	```
64
65	The column names are provided in a separate field is because their order
66	is guaranteed to match the order of the query columns, whereas object
67	key/value pairs might get reordered (typically sorted by key) when
68	travelling through different JSON implementations. In this manner,
69	clients can e.g. be sure to render the columns in the proper
70	(query-specified) order.
	@@ -76,10 +76,10 @@
76
77	Note the column names are never guaranteed to be exactly as they
78	appear in the SQL unless they are qualified with an AS, e.g. `SELECT
79	foo AS foo...`. When generating reports which need fixed column names, it
80	is highly recommended to use an AS qualifier for every column, even if
81	they use the same name as the column. This is the only way to guaranty
82	that the result column names will be stable. (FYI: that behaviour comes
83	from sqlite3, not the JSON bits, and this behaviour has been known to
84	change between sqlite3 versions (so this is not just an idle threat of
85	potential future incompatibility).)
86

	--- www/json-api/api-query.md
	+++ www/json-api/api-query.md
	@@ -60,11 +60,11 @@
60	…
61	]
62	}
63	```
64
65	The column names are provided in a separate field because their order
66	is guaranteed to match the order of the query columns, whereas object
67	key/value pairs might get reordered (typically sorted by key) when
68	travelling through different JSON implementations. In this manner,
69	clients can e.g. be sure to render the columns in the proper
70	(query-specified) order.
	@@ -76,10 +76,10 @@
76
77	Note the column names are never guaranteed to be exactly as they
78	appear in the SQL unless they are qualified with an AS, e.g. `SELECT
79	foo AS foo...`. When generating reports which need fixed column names, it
80	is highly recommended to use an AS qualifier for every column, even if
81	they use the same name as the column. This is the only way to guarantee
82	that the result column names will be stable. (FYI: that behaviour comes
83	from sqlite3, not the JSON bits, and this behaviour has been known to
84	change between sqlite3 versions (so this is not just an idle threat of
85	potential future incompatibility).)
86

M www/json-api/api-tag.md

+2 -2

		--- www/json-api/api-tag.md
		+++ www/json-api/api-tag.md
		@@ -98,15 +98,15 @@
98	98	path element.
99	99	- `limit=int` (defalt=0) Limits the number of results (0=no limit).
100	100	Since they are ordered from oldest to newest, the newest N results
101	101	will be returned.
102	102	- `type=string` (default=`*`) Searches only for the given type of
103		- artifact (using fossil's conventional type naming: ci, e, t, w.
	103	+ artifact (using fossil's conventional type naming: ci, e, t, w.)
104	104	- `raw=bool` (=false) If enabled, the response is an array of hashes
105	105	of the requested artifact type; otherwise,
106	106	it is an array of higher-level objects. If this is
107		- true, the "name" property is interpretted as-is. If it is false, the
	107	+ true, the "name" property is interpreted as-is. If it is false, the
108	108	name is automatically prepended with "sym-" (meaning a branch).
109	109	(FIXME: the current semantics are confusing and hard to remember.
110	110	Re-do them.)
111	111
112	112	**Response payload example, in RAW mode: (expect this format to change
113	113

	--- www/json-api/api-tag.md
	+++ www/json-api/api-tag.md
	@@ -98,15 +98,15 @@
98	path element.
99	- `limit=int` (defalt=0) Limits the number of results (0=no limit).
100	Since they are ordered from oldest to newest, the newest N results
101	will be returned.
102	- `type=string` (default=`*`) Searches only for the given type of
103	artifact (using fossil's conventional type naming: ci, e, t, w.
104	- `raw=bool` (=false) If enabled, the response is an array of hashes
105	of the requested artifact type; otherwise,
106	it is an array of higher-level objects. If this is
107	true, the "name" property is interpretted as-is. If it is false, the
108	name is automatically prepended with "sym-" (meaning a branch).
109	(FIXME: the current semantics are confusing and hard to remember.
110	Re-do them.)
111
112	**Response payload example, in RAW mode: (expect this format to change
113

	--- www/json-api/api-tag.md
	+++ www/json-api/api-tag.md
	@@ -98,15 +98,15 @@
98	path element.
99	- `limit=int` (defalt=0) Limits the number of results (0=no limit).
100	Since they are ordered from oldest to newest, the newest N results
101	will be returned.
102	- `type=string` (default=`*`) Searches only for the given type of
103	artifact (using fossil's conventional type naming: ci, e, t, w.)
104	- `raw=bool` (=false) If enabled, the response is an array of hashes
105	of the requested artifact type; otherwise,
106	it is an array of higher-level objects. If this is
107	true, the "name" property is interpreted as-is. If it is false, the
108	name is automatically prepended with "sym-" (meaning a branch).
109	(FIXME: the current semantics are confusing and hard to remember.
110	Re-do them.)
111
112	**Response payload example, in RAW mode: (expect this format to change
113

M www/json-api/conventions.md

+8 -8

		--- www/json-api/conventions.md
		+++ www/json-api/conventions.md
		@@ -100,11 +100,11 @@
100	100
101	101	The API allows most of those (normally all but the payload) to come in
102	102	as either GET parameters or properties of the top-level POSTed request
103	103	JSON envelope, with GET taking priority over POST. (Reminder to self: we
104	104	could potentially also use values from cookies. Fossil currently only
105		-uses 1 cookie (the login token), and i'd prefer to keep it that way.)
	105	+uses 1 cookie (the login token), and I'd prefer to keep it that way.)
106	106
107	107	POST requests without such an envelope will be rejected, generating a
108	108	Fossil/JSON error response (as opposed to an HTTP error response). GET
109	109	requests, by definition, never have an envelope.
110	110
		@@ -169,11 +169,11 @@
169	169	No higher-level constructs, e.g. JSON arrays or objects, are
170	170	accepted in string form. Such parameters must be set in the POST
171	171	envelope or payload, as specified by the specific API.
172	172
173	173	This API does not currently use any floating-point parameters, but
174		-does return floating-point results in a couple places.
	174	+does return floating-point results in a couple of places.
175	175
176	176	For integer parameters we use a conventional string-to-int algorithm
177	177	and assume base 10 (analog to atoi(3)). The API may err on the side of
178	178	usability when given technically invalid values. e.g. "123abc" will
179	179	likely be interpreted as the integer 123. No APIs currently rely on
		@@ -205,11 +205,11 @@
205	205	cause inconsistencies vis-a-vis the HTML interface).
206	206
207	207	<a id="response-envelope"></a>
208	208	# Response Envelope
209	209
210		-Every response comes in the form of a HTTP response or (in CLI mode)
	210	+Every response comes in the form of an HTTP response or (in CLI mode)
211	211	JSON sent to stdout. The body of the response is a JSON object following
212	212	a common envelope format. The envelope has the following properties:
213	213
214	214
215	215	- `fossil`: Fossil server version string. This property is basically
		@@ -216,11 +216,11 @@
216	216	"the official response envelope marker" - if it is set, clients can
217	217	"probably safely assume" that the object indeed came from one of the
218	218	Fossil/JSON APIs. This API never creates responses which do not
219	219	contain this property.
220	220	- `requestId`: Only set if the request contained it, and then it is
221		- echoed back to the caller as-is. This can be use to determine
	221	+ echoed back to the caller as-is. This can be used to determine
222	222	(client-side) which request a given response is coming in for
223	223	(assuming multiple asynchronous requests are pending). In practice
224	224	this generally isn’t needed because response handling tends to be
225	225	done by closures associated with the original request object (at
226	226	least in JavaScript code). In languages without closures it might
		@@ -235,11 +235,11 @@
235	235	- `payload`: Request-specific response payload (data type/structure is
236	236	request-specific). The payload is never set for error responses,
237	237	only for success responses (and only those which actually have a
238	238	payload - not all do).
239	239	- `timestamp`: Response timestamp (GMT Unix Epoch). We use seconds
240		- precision because i did not know at the time that Fossil actually
	240	+ precision because I did not know at the time that Fossil actually
241	241	records millisecond precision.
242	242	- `payloadVersion`: Not initially needed, but reserved for future use
243	243	in maintaining version compatibility when the format of a given
244	244	response type's payload changes. If needed, the "first version"
245	245	value is assumed to be 0, for semantic [near-]compatibility with the
		@@ -402,11 +402,11 @@
402	402	(they are represented by `\t`) there is no chance that such a global
403	403	replacement will corrupt JSON string contents - only the formatting will
404	404	be affected.
405	405
406	406	Potential TODO: because extraneous indention "could potentially" be used
407		-as a form DoS, the option might be subject to later removed from HTTP
	407	+as a form of DoS, the option might be subject to later removal from HTTP
408	408	mode (in CLI it's fine).
409	409
410	410	In HTTP mode no trailing newline is added to the output, whereas in CLI
411	411	mode one is normally appended (exception: in JSONP mode no newline is
412	412	appended, to (rather pedantically and arbitraily) allow the client to
		@@ -482,11 +482,11 @@
482	482	normally want to see very specific error codes when tracking down a
483	483	problem. We can offer a configuration option to "dumb down" error
484	484	codes to their generic category by simply doing a modulo 100
485	485	(or 1000) against the native error code number. e.g. FOSSIL-1271
486	486	could (via a simple modulo) be reduced to FOSSIL-1200 or
487		- FOSSIL-1000, depending on the paranoia level of the sysadmin. i have
	487	+ FOSSIL-1000, depending on the paranoia level of the sysadmin. I have
488	488	tried to order the result code numbers so that a dumb-down level of
489	489	2 provides reasonably usable results without giving away too much
490	490	detail to malicious clients.\
491	491	(TODO: `g.json.errorDetailParanoia` is used to set the
492	492	default dumb-down level, but it is currently set at compile-time.
		@@ -533,11 +533,11 @@
533	533	can actually implement this one, though.)
534	534	- `FOSSIL-1106`: Assertion failed (or would have had we
535	535	continued). Note: if an `assert()` fails in CGI/server modes, the HTTP
536	536	response will be code 500 (Internal Server Error). We want to avoid
537	537	that and return a JSON response instead. All of that said - there seems
538		- to be little reason to implementi this, since assertions are "truly
	538	+ to be little reason to implement this, since assertions are "truly
539	539	serious" errors.
540	540	- `FOSSIL-1107`: Allocation/out of memory error. This cannot be reasonably
541	541	reported because fossil aborts if an allocation fails.
542	542	- `FOSSIL-1108`: Requested API is not yet implemented.
543	543	- `FOSSIL-1109`: Panic! Fossil's `fossil_panic()` or `cgi_panic()` was
544	544

	--- www/json-api/conventions.md
	+++ www/json-api/conventions.md
	@@ -100,11 +100,11 @@
100
101	The API allows most of those (normally all but the payload) to come in
102	as either GET parameters or properties of the top-level POSTed request
103	JSON envelope, with GET taking priority over POST. (Reminder to self: we
104	could potentially also use values from cookies. Fossil currently only
105	uses 1 cookie (the login token), and i'd prefer to keep it that way.)
106
107	POST requests without such an envelope will be rejected, generating a
108	Fossil/JSON error response (as opposed to an HTTP error response). GET
109	requests, by definition, never have an envelope.
110
	@@ -169,11 +169,11 @@
169	No higher-level constructs, e.g. JSON arrays or objects, are
170	accepted in string form. Such parameters must be set in the POST
171	envelope or payload, as specified by the specific API.
172
173	This API does not currently use any floating-point parameters, but
174	does return floating-point results in a couple places.
175
176	For integer parameters we use a conventional string-to-int algorithm
177	and assume base 10 (analog to atoi(3)). The API may err on the side of
178	usability when given technically invalid values. e.g. "123abc" will
179	likely be interpreted as the integer 123. No APIs currently rely on
	@@ -205,11 +205,11 @@
205	cause inconsistencies vis-a-vis the HTML interface).
206
207	<a id="response-envelope"></a>
208	# Response Envelope
209
210	Every response comes in the form of a HTTP response or (in CLI mode)
211	JSON sent to stdout. The body of the response is a JSON object following
212	a common envelope format. The envelope has the following properties:
213
214
215	- `fossil`: Fossil server version string. This property is basically
	@@ -216,11 +216,11 @@
216	"the official response envelope marker" - if it is set, clients can
217	"probably safely assume" that the object indeed came from one of the
218	Fossil/JSON APIs. This API never creates responses which do not
219	contain this property.
220	- `requestId`: Only set if the request contained it, and then it is
221	echoed back to the caller as-is. This can be use to determine
222	(client-side) which request a given response is coming in for
223	(assuming multiple asynchronous requests are pending). In practice
224	this generally isn’t needed because response handling tends to be
225	done by closures associated with the original request object (at
226	least in JavaScript code). In languages without closures it might
	@@ -235,11 +235,11 @@
235	- `payload`: Request-specific response payload (data type/structure is
236	request-specific). The payload is never set for error responses,
237	only for success responses (and only those which actually have a
238	payload - not all do).
239	- `timestamp`: Response timestamp (GMT Unix Epoch). We use seconds
240	precision because i did not know at the time that Fossil actually
241	records millisecond precision.
242	- `payloadVersion`: Not initially needed, but reserved for future use
243	in maintaining version compatibility when the format of a given
244	response type's payload changes. If needed, the "first version"
245	value is assumed to be 0, for semantic [near-]compatibility with the
	@@ -402,11 +402,11 @@
402	(they are represented by `\t`) there is no chance that such a global
403	replacement will corrupt JSON string contents - only the formatting will
404	be affected.
405
406	Potential TODO: because extraneous indention "could potentially" be used
407	as a form DoS, the option might be subject to later removed from HTTP
408	mode (in CLI it's fine).
409
410	In HTTP mode no trailing newline is added to the output, whereas in CLI
411	mode one is normally appended (exception: in JSONP mode no newline is
412	appended, to (rather pedantically and arbitraily) allow the client to
	@@ -482,11 +482,11 @@
482	normally want to see very specific error codes when tracking down a
483	problem. We can offer a configuration option to "dumb down" error
484	codes to their generic category by simply doing a modulo 100
485	(or 1000) against the native error code number. e.g. FOSSIL-1271
486	could (via a simple modulo) be reduced to FOSSIL-1200 or
487	FOSSIL-1000, depending on the paranoia level of the sysadmin. i have
488	tried to order the result code numbers so that a dumb-down level of
489	2 provides reasonably usable results without giving away too much
490	detail to malicious clients.\
491	(TODO: `g.json.errorDetailParanoia` is used to set the
492	default dumb-down level, but it is currently set at compile-time.
	@@ -533,11 +533,11 @@
533	can actually implement this one, though.)
534	- `FOSSIL-1106`: Assertion failed (or would have had we
535	continued). Note: if an `assert()` fails in CGI/server modes, the HTTP
536	response will be code 500 (Internal Server Error). We want to avoid
537	that and return a JSON response instead. All of that said - there seems
538	to be little reason to implementi this, since assertions are "truly
539	serious" errors.
540	- `FOSSIL-1107`: Allocation/out of memory error. This cannot be reasonably
541	reported because fossil aborts if an allocation fails.
542	- `FOSSIL-1108`: Requested API is not yet implemented.
543	- `FOSSIL-1109`: Panic! Fossil's `fossil_panic()` or `cgi_panic()` was
544

	--- www/json-api/conventions.md
	+++ www/json-api/conventions.md
	@@ -100,11 +100,11 @@
100
101	The API allows most of those (normally all but the payload) to come in
102	as either GET parameters or properties of the top-level POSTed request
103	JSON envelope, with GET taking priority over POST. (Reminder to self: we
104	could potentially also use values from cookies. Fossil currently only
105	uses 1 cookie (the login token), and I'd prefer to keep it that way.)
106
107	POST requests without such an envelope will be rejected, generating a
108	Fossil/JSON error response (as opposed to an HTTP error response). GET
109	requests, by definition, never have an envelope.
110
	@@ -169,11 +169,11 @@
169	No higher-level constructs, e.g. JSON arrays or objects, are
170	accepted in string form. Such parameters must be set in the POST
171	envelope or payload, as specified by the specific API.
172
173	This API does not currently use any floating-point parameters, but
174	does return floating-point results in a couple of places.
175
176	For integer parameters we use a conventional string-to-int algorithm
177	and assume base 10 (analog to atoi(3)). The API may err on the side of
178	usability when given technically invalid values. e.g. "123abc" will
179	likely be interpreted as the integer 123. No APIs currently rely on
	@@ -205,11 +205,11 @@
205	cause inconsistencies vis-a-vis the HTML interface).
206
207	<a id="response-envelope"></a>
208	# Response Envelope
209
210	Every response comes in the form of an HTTP response or (in CLI mode)
211	JSON sent to stdout. The body of the response is a JSON object following
212	a common envelope format. The envelope has the following properties:
213
214
215	- `fossil`: Fossil server version string. This property is basically
	@@ -216,11 +216,11 @@
216	"the official response envelope marker" - if it is set, clients can
217	"probably safely assume" that the object indeed came from one of the
218	Fossil/JSON APIs. This API never creates responses which do not
219	contain this property.
220	- `requestId`: Only set if the request contained it, and then it is
221	echoed back to the caller as-is. This can be used to determine
222	(client-side) which request a given response is coming in for
223	(assuming multiple asynchronous requests are pending). In practice
224	this generally isn’t needed because response handling tends to be
225	done by closures associated with the original request object (at
226	least in JavaScript code). In languages without closures it might
	@@ -235,11 +235,11 @@
235	- `payload`: Request-specific response payload (data type/structure is
236	request-specific). The payload is never set for error responses,
237	only for success responses (and only those which actually have a
238	payload - not all do).
239	- `timestamp`: Response timestamp (GMT Unix Epoch). We use seconds
240	precision because I did not know at the time that Fossil actually
241	records millisecond precision.
242	- `payloadVersion`: Not initially needed, but reserved for future use
243	in maintaining version compatibility when the format of a given
244	response type's payload changes. If needed, the "first version"
245	value is assumed to be 0, for semantic [near-]compatibility with the
	@@ -402,11 +402,11 @@
402	(they are represented by `\t`) there is no chance that such a global
403	replacement will corrupt JSON string contents - only the formatting will
404	be affected.
405
406	Potential TODO: because extraneous indention "could potentially" be used
407	as a form of DoS, the option might be subject to later removal from HTTP
408	mode (in CLI it's fine).
409
410	In HTTP mode no trailing newline is added to the output, whereas in CLI
411	mode one is normally appended (exception: in JSONP mode no newline is
412	appended, to (rather pedantically and arbitraily) allow the client to
	@@ -482,11 +482,11 @@
482	normally want to see very specific error codes when tracking down a
483	problem. We can offer a configuration option to "dumb down" error
484	codes to their generic category by simply doing a modulo 100
485	(or 1000) against the native error code number. e.g. FOSSIL-1271
486	could (via a simple modulo) be reduced to FOSSIL-1200 or
487	FOSSIL-1000, depending on the paranoia level of the sysadmin. I have
488	tried to order the result code numbers so that a dumb-down level of
489	2 provides reasonably usable results without giving away too much
490	detail to malicious clients.\
491	(TODO: `g.json.errorDetailParanoia` is used to set the
492	default dumb-down level, but it is currently set at compile-time.
	@@ -533,11 +533,11 @@
533	can actually implement this one, though.)
534	- `FOSSIL-1106`: Assertion failed (or would have had we
535	continued). Note: if an `assert()` fails in CGI/server modes, the HTTP
536	response will be code 500 (Internal Server Error). We want to avoid
537	that and return a JSON response instead. All of that said - there seems
538	to be little reason to implement this, since assertions are "truly
539	serious" errors.
540	- `FOSSIL-1107`: Allocation/out of memory error. This cannot be reasonably
541	reported because fossil aborts if an allocation fails.
542	- `FOSSIL-1108`: Requested API is not yet implemented.
543	- `FOSSIL-1109`: Panic! Fossil's `fossil_panic()` or `cgi_panic()` was
544

M www/json-api/hacking.md

+7 -7

		--- www/json-api/hacking.md
		+++ www/json-api/hacking.md
		@@ -79,11 +79,11 @@
79	79	core. The disadvantages of this are that we lose fossil's conventional
80	80	help text mechanism (which is based on code comments in the
81	81	command/path's dispatcher impl) and the ability to write abbreviated
82	82	command names in CLI mode ("json" itself may be abbreviated, but not the
83	83	subcommands). The advantages are that we can handle CLI/HTTP modes
84		-almost identically (there are a couple minor differences) by unifying
	84	+almost identically (there are a couple of minor differences) by unifying
85	85	them under the same callback functions much more easily.
86	86
87	87	The top-level "json" command/path uses its own dispatching mechanism
88	88	which uses either the path (in HTTP mode) or CLI positional arguments to
89	89	dispatch commands (stopping at the first "flag option" (e.g. -foo) in
		@@ -125,11 +125,11 @@
125	125	(e.g. `db_prepare()` can be fatal, and callbacks may call `fossil_panic()`
126	126	if they really want to). One exception is `fossil_exit()`, which does
127	127	_not_ generate any extra output and will `exit()` the app. In the JSON
128	128	API, as a rule of thumb, `fossil_exit()` is only used when we want a
129	129	failed request to cause an HTTP 500 error, and it is reserved for
130		-allocation errors and similar truly catostrophic failures. That said...
	130	+allocation errors and similar truly catastrophic failures. That said...
131	131	libcson has been hacked to use `fossil_alloc()` and friends for memory
132	132	management, and those routines exit on error, so alloc error handling in
133	133	the JSON command handler code can afford to be a little lax (the
134	134	majority of potential errors clients get from the cson API have
135	135	allocation failure as their root cause).
		@@ -259,11 +259,11 @@
259	259	- `json_getenv()` and `json_getenv_TYPE()` search the so-called "JSON
260	260	environment," which is a superset of the GET/POST/`POST.payload` (if
261	261	`POST.payload` is-a Object).
262	262	- `json_find_option_TYPE()`: searches the CLI args (only when in CLI
263	263	mode) and the JSON environment.
264		-- The use of fossil's `P()` and `PD()` macros is discourages in JSON
	264	+- The use of fossil's `P()` and `PD()` macros is discouraged in JSON
265	265	callbacks because they can only handle String data from the CLI or
266	266	GET parameters (not POST/`POST.payload`). (Note that `P()` and `PD()`
267	267	normally also handle POSTed keys, but they only "see" values
268	268	posted as form-urlencoded fields, and not JSON format.)
269	269	- `find_option()` (from `src/main.c`) "should" also be avoided in
		@@ -280,11 +280,11 @@
280	280
281	281	<a href="creating-json-values"></a>
282	282	## Creating JSON Values
283	283
284	284	cson has a fairly rich API for creating and manipulating the various
285		-JSON-defined value types. For a detailed overview and demonstration i
	285	+JSON-defined value types. For a detailed overview and demonstration I
286	286	recommend reading:
287	287
288	288	[](https://fossil.wanderinghorse.net/wikis/cson/?page=HowTo)
289	289
290	290	That said, the Fossil/JSON API has several convenience wrappers to save
		@@ -310,15 +310,15 @@
310	310	to Arrays or Objects, or convert single columns to a JSON-compatible
311	311	form. See `json_stmt_to_array_of_obj()`,
312	312	`json_stmt_to_array_of_array()` (both in `src/json.c`), and
313	313	`cson_sqlite3_column_to_value()` and friends (in
314	314	`extsrc/cson_amalgamation.h`). They work in an intuitive way for numeric
315		-types, but they optimistically/natively assume that any fields of type
	315	+types, but they optimistically/naively assume that any fields of type
316	316	TEXT or BLOB are actually UTF8 data, and treat them as such. cson's
317	317	string class only handles UTF8 data and it is semantically illegal to
318	318	feed them anything but UTF8. Violating this will likely result in
319		-down-stream errors (e.g. when emiting the JSON string output). **The
	319	+down-stream errors (e.g. when emitting the JSON string output). **The
320	320	moral of this story is:** do not use these APIs to fetch binary data.
321	321	JSON doesn't do binary and the `cson_string` class does not
322	322	protect itself against clients feeding it non-UTF8 data.
323	323
324	324	Here's a basic example of using these features:
		@@ -347,7 +347,7 @@
347	347	AS clauses to be guaranteed that the db driver will return the column
348	348	names we want. Note that the AS clause is often used to translate column
349	349	names into something more JSON-conventional or user-friendly, e.g.
350	350	"SELECT cap AS capabilities...". Alternately, we can convert the
351	351	individual `sqlite3_stmt` column values to JSON using
352		-`cson_sqlite3_column_to_value()`, without refering directly to the
	352	+`cson_sqlite3_column_to_value()`, without referring directly to the
353	353	db-reported column name.
354	354

	--- www/json-api/hacking.md
	+++ www/json-api/hacking.md
	@@ -79,11 +79,11 @@
79	core. The disadvantages of this are that we lose fossil's conventional
80	help text mechanism (which is based on code comments in the
81	command/path's dispatcher impl) and the ability to write abbreviated
82	command names in CLI mode ("json" itself may be abbreviated, but not the
83	subcommands). The advantages are that we can handle CLI/HTTP modes
84	almost identically (there are a couple minor differences) by unifying
85	them under the same callback functions much more easily.
86
87	The top-level "json" command/path uses its own dispatching mechanism
88	which uses either the path (in HTTP mode) or CLI positional arguments to
89	dispatch commands (stopping at the first "flag option" (e.g. -foo) in
	@@ -125,11 +125,11 @@
125	(e.g. `db_prepare()` can be fatal, and callbacks may call `fossil_panic()`
126	if they really want to). One exception is `fossil_exit()`, which does
127	_not_ generate any extra output and will `exit()` the app. In the JSON
128	API, as a rule of thumb, `fossil_exit()` is only used when we want a
129	failed request to cause an HTTP 500 error, and it is reserved for
130	allocation errors and similar truly catostrophic failures. That said...
131	libcson has been hacked to use `fossil_alloc()` and friends for memory
132	management, and those routines exit on error, so alloc error handling in
133	the JSON command handler code can afford to be a little lax (the
134	majority of potential errors clients get from the cson API have
135	allocation failure as their root cause).
	@@ -259,11 +259,11 @@
259	- `json_getenv()` and `json_getenv_TYPE()` search the so-called "JSON
260	environment," which is a superset of the GET/POST/`POST.payload` (if
261	`POST.payload` is-a Object).
262	- `json_find_option_TYPE()`: searches the CLI args (only when in CLI
263	mode) and the JSON environment.
264	- The use of fossil's `P()` and `PD()` macros is discourages in JSON
265	callbacks because they can only handle String data from the CLI or
266	GET parameters (not POST/`POST.payload`). (Note that `P()` and `PD()`
267	normally also handle POSTed keys, but they only "see" values
268	posted as form-urlencoded fields, and not JSON format.)
269	- `find_option()` (from `src/main.c`) "should" also be avoided in
	@@ -280,11 +280,11 @@
280
281	<a href="creating-json-values"></a>
282	## Creating JSON Values
283
284	cson has a fairly rich API for creating and manipulating the various
285	JSON-defined value types. For a detailed overview and demonstration i
286	recommend reading:
287
288	[](https://fossil.wanderinghorse.net/wikis/cson/?page=HowTo)
289
290	That said, the Fossil/JSON API has several convenience wrappers to save
	@@ -310,15 +310,15 @@
310	to Arrays or Objects, or convert single columns to a JSON-compatible
311	form. See `json_stmt_to_array_of_obj()`,
312	`json_stmt_to_array_of_array()` (both in `src/json.c`), and
313	`cson_sqlite3_column_to_value()` and friends (in
314	`extsrc/cson_amalgamation.h`). They work in an intuitive way for numeric
315	types, but they optimistically/natively assume that any fields of type
316	TEXT or BLOB are actually UTF8 data, and treat them as such. cson's
317	string class only handles UTF8 data and it is semantically illegal to
318	feed them anything but UTF8. Violating this will likely result in
319	down-stream errors (e.g. when emiting the JSON string output). **The
320	moral of this story is:** do not use these APIs to fetch binary data.
321	JSON doesn't do binary and the `cson_string` class does not
322	protect itself against clients feeding it non-UTF8 data.
323
324	Here's a basic example of using these features:
	@@ -347,7 +347,7 @@
347	AS clauses to be guaranteed that the db driver will return the column
348	names we want. Note that the AS clause is often used to translate column
349	names into something more JSON-conventional or user-friendly, e.g.
350	"SELECT cap AS capabilities...". Alternately, we can convert the
351	individual `sqlite3_stmt` column values to JSON using
352	`cson_sqlite3_column_to_value()`, without refering directly to the
353	db-reported column name.
354

	--- www/json-api/hacking.md
	+++ www/json-api/hacking.md
	@@ -79,11 +79,11 @@
79	core. The disadvantages of this are that we lose fossil's conventional
80	help text mechanism (which is based on code comments in the
81	command/path's dispatcher impl) and the ability to write abbreviated
82	command names in CLI mode ("json" itself may be abbreviated, but not the
83	subcommands). The advantages are that we can handle CLI/HTTP modes
84	almost identically (there are a couple of minor differences) by unifying
85	them under the same callback functions much more easily.
86
87	The top-level "json" command/path uses its own dispatching mechanism
88	which uses either the path (in HTTP mode) or CLI positional arguments to
89	dispatch commands (stopping at the first "flag option" (e.g. -foo) in
	@@ -125,11 +125,11 @@
125	(e.g. `db_prepare()` can be fatal, and callbacks may call `fossil_panic()`
126	if they really want to). One exception is `fossil_exit()`, which does
127	_not_ generate any extra output and will `exit()` the app. In the JSON
128	API, as a rule of thumb, `fossil_exit()` is only used when we want a
129	failed request to cause an HTTP 500 error, and it is reserved for
130	allocation errors and similar truly catastrophic failures. That said...
131	libcson has been hacked to use `fossil_alloc()` and friends for memory
132	management, and those routines exit on error, so alloc error handling in
133	the JSON command handler code can afford to be a little lax (the
134	majority of potential errors clients get from the cson API have
135	allocation failure as their root cause).
	@@ -259,11 +259,11 @@
259	- `json_getenv()` and `json_getenv_TYPE()` search the so-called "JSON
260	environment," which is a superset of the GET/POST/`POST.payload` (if
261	`POST.payload` is-a Object).
262	- `json_find_option_TYPE()`: searches the CLI args (only when in CLI
263	mode) and the JSON environment.
264	- The use of fossil's `P()` and `PD()` macros is discouraged in JSON
265	callbacks because they can only handle String data from the CLI or
266	GET parameters (not POST/`POST.payload`). (Note that `P()` and `PD()`
267	normally also handle POSTed keys, but they only "see" values
268	posted as form-urlencoded fields, and not JSON format.)
269	- `find_option()` (from `src/main.c`) "should" also be avoided in
	@@ -280,11 +280,11 @@
280
281	<a href="creating-json-values"></a>
282	## Creating JSON Values
283
284	cson has a fairly rich API for creating and manipulating the various
285	JSON-defined value types. For a detailed overview and demonstration I
286	recommend reading:
287
288	[](https://fossil.wanderinghorse.net/wikis/cson/?page=HowTo)
289
290	That said, the Fossil/JSON API has several convenience wrappers to save
	@@ -310,15 +310,15 @@
310	to Arrays or Objects, or convert single columns to a JSON-compatible
311	form. See `json_stmt_to_array_of_obj()`,
312	`json_stmt_to_array_of_array()` (both in `src/json.c`), and
313	`cson_sqlite3_column_to_value()` and friends (in
314	`extsrc/cson_amalgamation.h`). They work in an intuitive way for numeric
315	types, but they optimistically/naively assume that any fields of type
316	TEXT or BLOB are actually UTF8 data, and treat them as such. cson's
317	string class only handles UTF8 data and it is semantically illegal to
318	feed them anything but UTF8. Violating this will likely result in
319	down-stream errors (e.g. when emitting the JSON string output). **The
320	moral of this story is:** do not use these APIs to fetch binary data.
321	JSON doesn't do binary and the `cson_string` class does not
322	protect itself against clients feeding it non-UTF8 data.
323
324	Here's a basic example of using these features:
	@@ -347,7 +347,7 @@
347	AS clauses to be guaranteed that the db driver will return the column
348	names we want. Note that the AS clause is often used to translate column
349	names into something more JSON-conventional or user-friendly, e.g.
350	"SELECT cap AS capabilities...". Alternately, we can convert the
351	individual `sqlite3_stmt` column values to JSON using
352	`cson_sqlite3_column_to_value()`, without referring directly to the
353	db-reported column name.
354

M www/mdtest/test1.md

+1 -1

		--- www/mdtest/test1.md
		+++ www/mdtest/test1.md
		@@ -1,8 +1,8 @@
1	1	# Markdown Link-test
2	2
3		-This document exist solely as a test for some of the hyperlinking
	3	+This document exists solely as a test for some of the hyperlinking
4	4	capabilities of Markdown as implemented by Fossil.
5	5
6	6	## Relative-Path Links
7	7
8	8	* The index: [](../index.wiki)
9	9

	--- www/mdtest/test1.md
	+++ www/mdtest/test1.md
	@@ -1,8 +1,8 @@
1	# Markdown Link-test
2
3	This document exist solely as a test for some of the hyperlinking
4	capabilities of Markdown as implemented by Fossil.
5
6	## Relative-Path Links
7
8	* The index: [](../index.wiki)
9

	--- www/mdtest/test1.md
	+++ www/mdtest/test1.md
	@@ -1,8 +1,8 @@
1	# Markdown Link-test
2
3	This document exists solely as a test for some of the hyperlinking
4	capabilities of Markdown as implemented by Fossil.
5
6	## Relative-Path Links
7
8	* The index: [](../index.wiki)
9

M www/server/debian/service.md

+1 -1

		--- www/server/debian/service.md
		+++ www/server/debian/service.md
		@@ -183,11 +183,11 @@
183	183	to the system level. We need to start this socket listener at the root
184	184	level because of the low-numbered TCP port restriction we brought up
185	185	above.
186	186
187	187	This configuration says more or less the same thing as the socket part
188		-of an `inted` entry [exemplified elsewhere in this
	188	+of an `inetd` entry [exemplified elsewhere in this
189	189	documentation](../any/inetd.md).
190	190
191	191	Next, create the service definition file in that same directory as
192	192	`[email protected]`:
193	193
194	194

	--- www/server/debian/service.md
	+++ www/server/debian/service.md
	@@ -183,11 +183,11 @@
183	to the system level. We need to start this socket listener at the root
184	level because of the low-numbered TCP port restriction we brought up
185	above.
186
187	This configuration says more or less the same thing as the socket part
188	of an `inted` entry [exemplified elsewhere in this
189	documentation](../any/inetd.md).
190
191	Next, create the service definition file in that same directory as
192	`[email protected]`:
193
194

	--- www/server/debian/service.md
	+++ www/server/debian/service.md
	@@ -183,11 +183,11 @@
183	to the system level. We need to start this socket listener at the root
184	level because of the low-numbered TCP port restriction we brought up
185	above.
186
187	This configuration says more or less the same thing as the socket part
188	of an `inetd` entry [exemplified elsewhere in this
189	documentation](../any/inetd.md).
190
191	Next, create the service definition file in that same directory as
192	`[email protected]`:
193
194

M www/server/openbsd/fastcgi.md

+1 -1

		--- www/server/openbsd/fastcgi.md
		+++ www/server/openbsd/fastcgi.md
		@@ -172,11 +172,11 @@
172	172	setting, raising the limit to 100 MiB.
173	173
174	174	[dlim]: https://man.openbsd.org/httpd.conf.5#connection
175	175	[uv]: ../../unvers.wiki
176	176
177		-NOTE: If not already in possession of a HTTPS certificate, comment
	177	+NOTE: If not already in possession of an HTTPS certificate, comment
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	183

	--- www/server/openbsd/fastcgi.md
	+++ www/server/openbsd/fastcgi.md
	@@ -172,11 +172,11 @@
172	setting, raising the limit to 100 MiB.
173
174	[dlim]: https://man.openbsd.org/httpd.conf.5#connection
175	[uv]: ../../unvers.wiki
176
177	NOTE: If not already in possession of a HTTPS certificate, comment
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

	--- www/server/openbsd/fastcgi.md
	+++ www/server/openbsd/fastcgi.md
	@@ -172,11 +172,11 @@
172	setting, raising the limit to 100 MiB.
173
174	[dlim]: https://man.openbsd.org/httpd.conf.5#connection
175	[uv]: ../../unvers.wiki
176
177	NOTE: If not already in possession of an HTTPS certificate, comment
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

M www/server/windows/service.md

+1 -1

		--- www/server/windows/service.md
		+++ www/server/windows/service.md
		@@ -39,11 +39,11 @@
39	39	This will create a windows service named 'Fossil-DSCM' running under the local
40	40	system account and accessible on port 8080 by default. `fossil winsrv` can also
41	41	start, stop, and delete the service. For all available options, please execute
42	42	`fossil help winsrv` on a windows install of Fossil.
43	43
44		-If you wish to server a directory of repositories, the `fossil winsrv` command
	44	+If you wish to serve a directory of repositories, the `fossil winsrv` command
45	45	requires a slightly different set of options vs. `fossil server`:
46	46
47	47	```
48	48	fossil winsrv create --repository D:/Path/to/Repos --repolist
49	49	```
50	50

	--- www/server/windows/service.md
	+++ www/server/windows/service.md
	@@ -39,11 +39,11 @@
39	This will create a windows service named 'Fossil-DSCM' running under the local
40	system account and accessible on port 8080 by default. `fossil winsrv` can also
41	start, stop, and delete the service. For all available options, please execute
42	`fossil help winsrv` on a windows install of Fossil.
43
44	If you wish to server a directory of repositories, the `fossil winsrv` command
45	requires a slightly different set of options vs. `fossil server`:
46
47	```
48	fossil winsrv create --repository D:/Path/to/Repos --repolist
49	```
50

	--- www/server/windows/service.md
	+++ www/server/windows/service.md
	@@ -39,11 +39,11 @@
39	This will create a windows service named 'Fossil-DSCM' running under the local
40	system account and accessible on port 8080 by default. `fossil winsrv` can also
41	start, stop, and delete the service. For all available options, please execute
42	`fossil help winsrv` on a windows install of Fossil.
43
44	If you wish to serve a directory of repositories, the `fossil winsrv` command
45	requires a slightly different set of options vs. `fossil server`:
46
47	```
48	fossil winsrv create --repository D:/Path/to/Repos --repolist
49	```
50

M www/th1.md

+5 -5

		--- www/th1.md
		+++ www/th1.md
		@@ -32,11 +32,11 @@
32	32	the computation, then converting the result back into a string. (This might
33	33	seem inefficient, but it is faster than people imagine, and numeric
34	34	computations do not come up very often for the kinds of work that TH1 does,
35	35	so it has never been a factor.)
36	36
37		-A TH1 script consist of a sequence of commands.
	37	+A TH1 script consists of a sequence of commands.
38	38	Each command is terminated by the first unescaped newline or ";" character.
39	39	The text of the command (excluding the newline or semicolon terminator)
40	40	is broken into space-separated tokens. The first token is the command
41	41	name and subsequent tokens are the arguments. In this sense, TH1 syntax
42	42	is similar to the familiar command-line shell syntax.
		@@ -288,11 +288,11 @@
288	288	The capability expression is a list. Each term of the list is a
289	289	cluster of [capability letters](./caps/ref.html).
290	290	The overall expression is true if any
291	291	one term is true. A single term is true if all letters within that
292	292	term are true. Or, if the term begins with "!", then the term is true
293		-if none of the terms or true. Or, if the term begins with "@" then
	293	+if none of the terms are true. Or, if the term begins with "@" then
294	294	the term is true if all of the capability letters in that term are
295	295	available to the "anonymous" user. Or, if the term is "*" then it is
296	296	always true.
297	297
298	298	Examples:
		@@ -383,11 +383,11 @@
383	383	<a id="date"></a>TH1 date Command
384	384	-----------------------------------
385	385
386	386	* date ?-local?
387	387
388		-Return a strings which is the current time and date. If the -local
	388	+Return a string which is the current time and date. If the -local
389	389	option is used, the date appears using localtime instead of UTC.
390	390
391	391	<a id="decorate"></a>TH1 decorate Command
392	392	-------------------------------------------
393	393
		@@ -570,11 +570,11 @@
570	570	<a id="linecount"></a>TH1 linecount Command
571	571	---------------------------------------------
572	572
573	573	* linecount STRING MAX MIN
574	574
575		-Returns one more than the number of \n characters in STRING. But
	575	+Returns one more than the number of `\n` characters in STRING. But
576	576	never returns less than MIN or more than MAX.
577	577
578	578	<a id="markdown"></a>TH1 markdown Command
579	579	-------------------------------------------
580	580
		@@ -842,11 +842,11 @@
842	842	-----------------------------------------------
843	843
844	844	* verifyCsrf
845	845
846	846	Before using the results of a form, first call this command to verify
847		-that this Anti-CSRF token is present and is valid. If the Anti-CSRF token
	847	+that the Anti-CSRF token is present and is valid. If the Anti-CSRF token
848	848	is missing or is incorrect, that indicates a cross-site scripting attack.
849	849	If the event of an attack is detected, an error message is generated and
850	850	all further processing is aborted.
851	851
852	852	<a id="verifyLogin"></a>TH1 verifyLogin Command
853	853

	--- www/th1.md
	+++ www/th1.md
	@@ -32,11 +32,11 @@
32	the computation, then converting the result back into a string. (This might
33	seem inefficient, but it is faster than people imagine, and numeric
34	computations do not come up very often for the kinds of work that TH1 does,
35	so it has never been a factor.)
36
37	A TH1 script consist of a sequence of commands.
38	Each command is terminated by the first unescaped newline or ";" character.
39	The text of the command (excluding the newline or semicolon terminator)
40	is broken into space-separated tokens. The first token is the command
41	name and subsequent tokens are the arguments. In this sense, TH1 syntax
42	is similar to the familiar command-line shell syntax.
	@@ -288,11 +288,11 @@
288	The capability expression is a list. Each term of the list is a
289	cluster of [capability letters](./caps/ref.html).
290	The overall expression is true if any
291	one term is true. A single term is true if all letters within that
292	term are true. Or, if the term begins with "!", then the term is true
293	if none of the terms or true. Or, if the term begins with "@" then
294	the term is true if all of the capability letters in that term are
295	available to the "anonymous" user. Or, if the term is "*" then it is
296	always true.
297
298	Examples:
	@@ -383,11 +383,11 @@
383	<a id="date"></a>TH1 date Command
384	-----------------------------------
385
386	* date ?-local?
387
388	Return a strings which is the current time and date. If the -local
389	option is used, the date appears using localtime instead of UTC.
390
391	<a id="decorate"></a>TH1 decorate Command
392	-------------------------------------------
393
	@@ -570,11 +570,11 @@
570	<a id="linecount"></a>TH1 linecount Command
571	---------------------------------------------
572
573	* linecount STRING MAX MIN
574
575	Returns one more than the number of \n characters in STRING. But
576	never returns less than MIN or more than MAX.
577
578	<a id="markdown"></a>TH1 markdown Command
579	-------------------------------------------
580
	@@ -842,11 +842,11 @@
842	-----------------------------------------------
843
844	* verifyCsrf
845
846	Before using the results of a form, first call this command to verify
847	that this Anti-CSRF token is present and is valid. If the Anti-CSRF token
848	is missing or is incorrect, that indicates a cross-site scripting attack.
849	If the event of an attack is detected, an error message is generated and
850	all further processing is aborted.
851
852	<a id="verifyLogin"></a>TH1 verifyLogin Command
853

	--- www/th1.md
	+++ www/th1.md
	@@ -32,11 +32,11 @@
32	the computation, then converting the result back into a string. (This might
33	seem inefficient, but it is faster than people imagine, and numeric
34	computations do not come up very often for the kinds of work that TH1 does,
35	so it has never been a factor.)
36
37	A TH1 script consists of a sequence of commands.
38	Each command is terminated by the first unescaped newline or ";" character.
39	The text of the command (excluding the newline or semicolon terminator)
40	is broken into space-separated tokens. The first token is the command
41	name and subsequent tokens are the arguments. In this sense, TH1 syntax
42	is similar to the familiar command-line shell syntax.
	@@ -288,11 +288,11 @@
288	The capability expression is a list. Each term of the list is a
289	cluster of [capability letters](./caps/ref.html).
290	The overall expression is true if any
291	one term is true. A single term is true if all letters within that
292	term are true. Or, if the term begins with "!", then the term is true
293	if none of the terms are true. Or, if the term begins with "@" then
294	the term is true if all of the capability letters in that term are
295	available to the "anonymous" user. Or, if the term is "*" then it is
296	always true.
297
298	Examples:
	@@ -383,11 +383,11 @@
383	<a id="date"></a>TH1 date Command
384	-----------------------------------
385
386	* date ?-local?
387
388	Return a string which is the current time and date. If the -local
389	option is used, the date appears using localtime instead of UTC.
390
391	<a id="decorate"></a>TH1 decorate Command
392	-------------------------------------------
393
	@@ -570,11 +570,11 @@
570	<a id="linecount"></a>TH1 linecount Command
571	---------------------------------------------
572
573	* linecount STRING MAX MIN
574
575	Returns one more than the number of `\n` characters in STRING. But
576	never returns less than MIN or more than MAX.
577
578	<a id="markdown"></a>TH1 markdown Command
579	-------------------------------------------
580
	@@ -842,11 +842,11 @@
842	-----------------------------------------------
843
844	* verifyCsrf
845
846	Before using the results of a form, first call this command to verify
847	that the Anti-CSRF token is present and is valid. If the Anti-CSRF token
848	is missing or is incorrect, that indicates a cross-site scripting attack.
849	If the event of an attack is detected, an error message is generated and
850	all further processing is aborted.
851
852	<a id="verifyLogin"></a>TH1 verifyLogin Command
853

M www/theory1.wiki

+2 -2

		--- www/theory1.wiki
		+++ www/theory1.wiki
		@@ -73,14 +73,14 @@
73	73	implementation detail which currently happens to use SQLite.
74	74
75	75	Another way to think of the relational tables in a Fossil repository is
76	76	as an index for the artifacts. Without the relational tables,
77	77	to generate a report like a timeline would require scanning every artifact -
78		-the equivalent of a full table scan. The relational tables hold pointers
	78	+the equivalent of a full table scan. The relational tables hold pointers to
79	79	the relevant artifacts in presorted order so that generating a timeline
80	80	is much more efficient. So like an index in a relational database, the
81		-relational tables in an Fossil repository do not add any new information,
	81	+relational tables in a Fossil repository do not add any new information,
82	82	they merely make the information in the artifacts faster and easier to
83	83	look up.
84	84
85	85	Fossil is not "based" on SQLite. Fossil simply exploits SQLite as
86	86	a powerful tool to make the implementation easier.
87	87

	--- www/theory1.wiki
	+++ www/theory1.wiki
	@@ -73,14 +73,14 @@
73	implementation detail which currently happens to use SQLite.
74
75	Another way to think of the relational tables in a Fossil repository is
76	as an index for the artifacts. Without the relational tables,
77	to generate a report like a timeline would require scanning every artifact -
78	the equivalent of a full table scan. The relational tables hold pointers
79	the relevant artifacts in presorted order so that generating a timeline
80	is much more efficient. So like an index in a relational database, the
81	relational tables in an Fossil repository do not add any new information,
82	they merely make the information in the artifacts faster and easier to
83	look up.
84
85	Fossil is not "based" on SQLite. Fossil simply exploits SQLite as
86	a powerful tool to make the implementation easier.
87

	--- www/theory1.wiki
	+++ www/theory1.wiki
	@@ -73,14 +73,14 @@
73	implementation detail which currently happens to use SQLite.
74
75	Another way to think of the relational tables in a Fossil repository is
76	as an index for the artifacts. Without the relational tables,
77	to generate a report like a timeline would require scanning every artifact -
78	the equivalent of a full table scan. The relational tables hold pointers to
79	the relevant artifacts in presorted order so that generating a timeline
80	is much more efficient. So like an index in a relational database, the
81	relational tables in a Fossil repository do not add any new information,
82	they merely make the information in the artifacts faster and easier to
83	look up.
84
85	Fossil is not "based" on SQLite. Fossil simply exploits SQLite as
86	a powerful tool to make the implementation easier.
87

M www/tickets.wiki

+2 -2

		--- www/tickets.wiki
		+++ www/tickets.wiki
		@@ -27,11 +27,11 @@
27	27	that key, or the value may be appended to the prior value.
28	28
29	29	<h2>2.0 Ticket Tables</h2>
30	30
31	31	The low-level artifact format for ticket content is tedious and
32		-cumbersome to access in real time. To facility reporting and display
	32	+cumbersome to access in real time. To facilitate reporting and display
33	33	of tickets, the low-level artifact information is collected and
34	34	summarized in a pair of SQL tables in each local repository. Display
35	35	and reporting of tickets is accomplished by querying these two tables.
36	36
37	37	Note that only the low-level ticket change artifacts are synced. The
		@@ -191,9 +191,9 @@
191	191	comment according to its chosen format. Hence, Fossil was enhanced to
192	192	support the "new-style" tickets.
193	193
194	194	The TICKETCHNG table was added to support new-style tickets. In the new
195	195	style, comment text is stored with the "icomment" (for "Incremental Comment")
196		-key and appears separately, and with its on mimetype, in multiple rows
	196	+key and appears separately, and with its own mimetype, in multiple rows
197	197	of the TICKETCHNG table. It then falls to the TH1 script code on the
198	198	View Ticket Page to query the TICKETCHNG table and extract and format
199	199	the various comments in time stamp order.
200	200

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -27,11 +27,11 @@
27	that key, or the value may be appended to the prior value.
28
29	<h2>2.0 Ticket Tables</h2>
30
31	The low-level artifact format for ticket content is tedious and
32	cumbersome to access in real time. To facility reporting and display
33	of tickets, the low-level artifact information is collected and
34	summarized in a pair of SQL tables in each local repository. Display
35	and reporting of tickets is accomplished by querying these two tables.
36
37	Note that only the low-level ticket change artifacts are synced. The
	@@ -191,9 +191,9 @@
191	comment according to its chosen format. Hence, Fossil was enhanced to
192	support the "new-style" tickets.
193
194	The TICKETCHNG table was added to support new-style tickets. In the new
195	style, comment text is stored with the "icomment" (for "Incremental Comment")
196	key and appears separately, and with its on mimetype, in multiple rows
197	of the TICKETCHNG table. It then falls to the TH1 script code on the
198	View Ticket Page to query the TICKETCHNG table and extract and format
199	the various comments in time stamp order.
200

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -27,11 +27,11 @@
27	that key, or the value may be appended to the prior value.
28
29	<h2>2.0 Ticket Tables</h2>
30
31	The low-level artifact format for ticket content is tedious and
32	cumbersome to access in real time. To facilitate reporting and display
33	of tickets, the low-level artifact information is collected and
34	summarized in a pair of SQL tables in each local repository. Display
35	and reporting of tickets is accomplished by querying these two tables.
36
37	Note that only the low-level ticket change artifacts are synced. The
	@@ -191,9 +191,9 @@
191	comment according to its chosen format. Hence, Fossil was enhanced to
192	support the "new-style" tickets.
193
194	The TICKETCHNG table was added to support new-style tickets. In the new
195	style, comment text is stored with the "icomment" (for "Incremental Comment")
196	key and appears separately, and with its own mimetype, in multiple rows
197	of the TICKETCHNG table. It then falls to the TH1 script code on the
198	View Ticket Page to query the TICKETCHNG table and extract and format
199	the various comments in time stamp order.
200

M www/unvers.wiki

+2 -2

		--- www/unvers.wiki
		+++ www/unvers.wiki
		@@ -53,12 +53,12 @@
53	53	[/help?cmd=push\|fossil push] or [/help?cmd=pull\|fossil pull].
54	54	The "-u" option is only available on "sync" and "clone".
55	55	A rough equivalent of an unversioned pull would be the
56	56	[/help?cmd=unversioned\|fossil unversioned revert] command. The
57	57	"unversioned revert"
58		-command causes the unversioned content on the local repository to overwritten
59		-by the unversioned content found on the remote repository.
	58	+command causes the unversioned content on the local repository to be
	59	+overwritten by the unversioned content found on the remote repository.
60	60
61	61	Beware that because unversioned file sync is an uncommonly dangerous
62	62	capability — there being no history to revert to in the case of human
63	63	error — even the all-powerful Fossil "setup" user does not get
64	64	unversioned file sync capability by default. See
65	65

	--- www/unvers.wiki
	+++ www/unvers.wiki
	@@ -53,12 +53,12 @@
53	[/help?cmd=push\|fossil push] or [/help?cmd=pull\|fossil pull].
54	The "-u" option is only available on "sync" and "clone".
55	A rough equivalent of an unversioned pull would be the
56	[/help?cmd=unversioned\|fossil unversioned revert] command. The
57	"unversioned revert"
58	command causes the unversioned content on the local repository to overwritten
59	by the unversioned content found on the remote repository.
60
61	Beware that because unversioned file sync is an uncommonly dangerous
62	capability — there being no history to revert to in the case of human
63	error — even the all-powerful Fossil "setup" user does not get
64	unversioned file sync capability by default. See
65

	--- www/unvers.wiki
	+++ www/unvers.wiki
	@@ -53,12 +53,12 @@
53	[/help?cmd=push\|fossil push] or [/help?cmd=pull\|fossil pull].
54	The "-u" option is only available on "sync" and "clone".
55	A rough equivalent of an unversioned pull would be the
56	[/help?cmd=unversioned\|fossil unversioned revert] command. The
57	"unversioned revert"
58	command causes the unversioned content on the local repository to be
59	overwritten by the unversioned content found on the remote repository.
60
61	Beware that because unversioned file sync is an uncommonly dangerous
62	capability — there being no history to revert to in the case of human
63	error — even the all-powerful Fossil "setup" user does not get
64	unversioned file sync capability by default. See
65

M www/userlinks.wiki

+1 -1

		--- www/userlinks.wiki
		+++ www/userlinks.wiki
		@@ -23,11 +23,11 @@
23	23	* Fossil contains a [./wikitheory.wiki \| built-in wiki].
24	24	* An [./event.wiki \| Event] is a special kind of wiki page associated
25	25	with a point in time rather than a name.
26	26	* [./settings.wiki \| Settings] control the behaviour of Fossil.
27	27	* [./ssl.wiki \| Use SSL] to encrypt communication with the server.
28		- * The [https://fossil-scm.org/forum\|Fossil forum] is, as of mid-2018,
	28	+ * The [https://fossil-scm.org/forum\|Fossil forum] is, as of late-2024,
29	29	the project's central communication channel. The
30	30	[https://www.mail-archive.com/[email protected]
31	31	\| read-only mailing list archives] house discussions spanning Fossil's
32	32	first decade.
33	33	* [./stats.wiki \| Performance statistics] taken from real-world projects
34	34

	--- www/userlinks.wiki
	+++ www/userlinks.wiki
	@@ -23,11 +23,11 @@
23	* Fossil contains a [./wikitheory.wiki \| built-in wiki].
24	* An [./event.wiki \| Event] is a special kind of wiki page associated
25	with a point in time rather than a name.
26	* [./settings.wiki \| Settings] control the behaviour of Fossil.
27	* [./ssl.wiki \| Use SSL] to encrypt communication with the server.
28	* The [https://fossil-scm.org/forum\|Fossil forum] is, as of mid-2018,
29	the project's central communication channel. The
30	[https://www.mail-archive.com/[email protected]
31	\| read-only mailing list archives] house discussions spanning Fossil's
32	first decade.
33	* [./stats.wiki \| Performance statistics] taken from real-world projects
34

	--- www/userlinks.wiki
	+++ www/userlinks.wiki
	@@ -23,11 +23,11 @@
23	* Fossil contains a [./wikitheory.wiki \| built-in wiki].
24	* An [./event.wiki \| Event] is a special kind of wiki page associated
25	with a point in time rather than a name.
26	* [./settings.wiki \| Settings] control the behaviour of Fossil.
27	* [./ssl.wiki \| Use SSL] to encrypt communication with the server.
28	* The [https://fossil-scm.org/forum\|Fossil forum] is, as of late-2024,
29	the project's central communication channel. The
30	[https://www.mail-archive.com/[email protected]
31	\| read-only mailing list archives] house discussions spanning Fossil's
32	first decade.
33	* [./stats.wiki \| Performance statistics] taken from real-world projects
34

M www/webui.wiki

+5 -5

		--- www/webui.wiki
		+++ www/webui.wiki
		@@ -116,15 +116,15 @@
116	116	The "Files" link on the menu allows you to browse through the <b>file
117	117	hierarchy</b> of the project and to view complete changes histories on
118	118	individual files, with hyperlinks to the check-ins that made those
119	119	changes, and with diffs and annotated diffs between versions.
120	120
121		-The web interface supports [./embeddeddoc.wiki \| embedded documentation].
122		-Embedded documentation is documentation files (usually in wiki format)
123		-that are checked into project as part of the source tree. Such files
124		-can be viewed as if they were ordinary web pages. This document that
125		-you are now reading is an example of embedded documentation.
	121	+The web interface supports [./embeddeddoc.wiki \| embedded documentation]
	122	+files (usually in wiki format) that are checked into the project as
	123	+part of the source tree. Such files can be viewed as if they were
	124	+ordinary web pages. This document that you are now reading is an
	125	+example of embedded documentation.
126	126
127	127	<h2>Customizing The Web Interface Appearance</h2>
128	128
129	129	Users with appropriate permissions can customize the look and feel of
130	130	the web interface using the "Admin" link on the main menu of the web
131	131

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -116,15 +116,15 @@
116	The "Files" link on the menu allows you to browse through the <b>file
117	hierarchy</b> of the project and to view complete changes histories on
118	individual files, with hyperlinks to the check-ins that made those
119	changes, and with diffs and annotated diffs between versions.
120
121	The web interface supports [./embeddeddoc.wiki \| embedded documentation].
122	Embedded documentation is documentation files (usually in wiki format)
123	that are checked into project as part of the source tree. Such files
124	can be viewed as if they were ordinary web pages. This document that
125	you are now reading is an example of embedded documentation.
126
127	<h2>Customizing The Web Interface Appearance</h2>
128
129	Users with appropriate permissions can customize the look and feel of
130	the web interface using the "Admin" link on the main menu of the web
131

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -116,15 +116,15 @@
116	The "Files" link on the menu allows you to browse through the <b>file
117	hierarchy</b> of the project and to view complete changes histories on
118	individual files, with hyperlinks to the check-ins that made those
119	changes, and with diffs and annotated diffs between versions.
120
121	The web interface supports [./embeddeddoc.wiki \| embedded documentation]
122	files (usually in wiki format) that are checked into the project as
123	part of the source tree. Such files can be viewed as if they were
124	ordinary web pages. This document that you are now reading is an
125	example of embedded documentation.
126
127	<h2>Customizing The Web Interface Appearance</h2>
128
129	Users with appropriate permissions can customize the look and feel of
130	the web interface using the "Admin" link on the main menu of the web
131

M www/wikitheory.wiki

+1 -1

		--- www/wikitheory.wiki
		+++ www/wikitheory.wiki
		@@ -84,7 +84,7 @@
84	84	wiki page at the top of the timeline
85	85	* [/info/19c60b7fc9e2] shows the text of the
86	86	[/wiki?name=checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6&p\|checkin/19c60b7fc9e2...]
87	87	wiki page in the "About" section.
88	88
89		-This special wiki pages are very useful for recording historical
	89	+These special wiki pages are very useful for recording historical
90	90	notes.
91	91

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -84,7 +84,7 @@
84	wiki page at the top of the timeline
85	* [/info/19c60b7fc9e2] shows the text of the
86	[/wiki?name=checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6&p\|checkin/19c60b7fc9e2...]
87	wiki page in the "About" section.
88
89	This special wiki pages are very useful for recording historical
90	notes.
91

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -84,7 +84,7 @@
84	wiki page at the top of the timeline
85	* [/info/19c60b7fc9e2] shows the text of the
86	[/wiki?name=checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6&p\|checkin/19c60b7fc9e2...]
87	wiki page in the "About" section.
88
89	These special wiki pages are very useful for recording historical
90	notes.
91

Fossil SCM

Keyboard Shortcuts