0996347d4ab… — Fossil SCM

M www/aboutdownload.wiki

+1 -1

		--- www/aboutdownload.wiki
		+++ www/aboutdownload.wiki
		@@ -51,11 +51,11 @@
51	51	With each new release, the "releases" variable in the javascript on
52	52	the [/uv/download.js?mimetype=text/plain\|download.js] page is
53	53	edited (using "[/help?cmd=uv\|fossil uv edit download.js]") to add
54	54	details of the release.
55	55
56		-When the javascript in the "download.js" file runs, it requests
	56	+When the JavaScript in the "download.js" file runs, it requests
57	57	a listing of all unversioned content using the /juvlist URL.
58	58	([/juvlist\|sample /juvlist output]). The content of the download page is
59	59	constructed by matching unversioned files against regular expressions
60	60	in the "releases" variable.
61	61
62	62

	--- www/aboutdownload.wiki
	+++ www/aboutdownload.wiki
	@@ -51,11 +51,11 @@
51	With each new release, the "releases" variable in the javascript on
52	the [/uv/download.js?mimetype=text/plain\|download.js] page is
53	edited (using "[/help?cmd=uv\|fossil uv edit download.js]") to add
54	details of the release.
55
56	When the javascript in the "download.js" file runs, it requests
57	a listing of all unversioned content using the /juvlist URL.
58	([/juvlist\|sample /juvlist output]). The content of the download page is
59	constructed by matching unversioned files against regular expressions
60	in the "releases" variable.
61
62

	--- www/aboutdownload.wiki
	+++ www/aboutdownload.wiki
	@@ -51,11 +51,11 @@
51	With each new release, the "releases" variable in the javascript on
52	the [/uv/download.js?mimetype=text/plain\|download.js] page is
53	edited (using "[/help?cmd=uv\|fossil uv edit download.js]") to add
54	details of the release.
55
56	When the JavaScript in the "download.js" file runs, it requests
57	a listing of all unversioned content using the /juvlist URL.
58	([/juvlist\|sample /juvlist output]). The content of the download page is
59	constructed by matching unversioned files against regular expressions
60	in the "releases" variable.
61
62

M www/alerts.md

+1 -1

		--- www/alerts.md
		+++ www/alerts.md
		@@ -29,11 +29,11 @@
29	29	## Setup Prerequisites
30	30
31	31	Much of this document describes how to set up Fossil's email alert
32	32	system. To follow this guide, you will need a Fossil UI browser window
33	33	open to the [Admin → Notification](/setup_notification) Fossil UI screen
34		-on the the Fossil server that will be sending these email alerts, logged
	34	+on the Fossil server that will be sending these email alerts, logged
35	35	in as a user with Admin capability. It is not possible to work on a
36	36	clone of the server's repository and push the configuration changes up
37	37	to that repo as an Admin user, [on purpose](#backup).
38	38
39	39	Important: Do not confuse that screen with Admin → Email-Server,
40	40

	--- www/alerts.md
	+++ www/alerts.md
	@@ -29,11 +29,11 @@
29	## Setup Prerequisites
30
31	Much of this document describes how to set up Fossil's email alert
32	system. To follow this guide, you will need a Fossil UI browser window
33	open to the [Admin → Notification](/setup_notification) Fossil UI screen
34	on the the Fossil server that will be sending these email alerts, logged
35	in as a user with Admin capability. It is not possible to work on a
36	clone of the server's repository and push the configuration changes up
37	to that repo as an Admin user, [on purpose](#backup).
38
39	Important: Do not confuse that screen with Admin → Email-Server,
40

	--- www/alerts.md
	+++ www/alerts.md
	@@ -29,11 +29,11 @@
29	## Setup Prerequisites
30
31	Much of this document describes how to set up Fossil's email alert
32	system. To follow this guide, you will need a Fossil UI browser window
33	open to the [Admin → Notification](/setup_notification) Fossil UI screen
34	on the Fossil server that will be sending these email alerts, logged
35	in as a user with Admin capability. It is not possible to work on a
36	clone of the server's repository and push the configuration changes up
37	to that repo as an Admin user, [on purpose](#backup).
38
39	Important: Do not confuse that screen with Admin → Email-Server,
40

M www/antibot.wiki

+13 -13

		--- www/antibot.wiki
		+++ www/antibot.wiki
		@@ -62,14 +62,14 @@
62	62
63	63	The first two UserAgent strings above identify Firefox 19 and
64	64	Internet Explorer 8.0, both running on Windows NT. The third
65	65	example is the spider used by Google to index the internet.
66	66	The fourth example is the "wget" utility running on OpenBSD.
67		-Thus the first two UserAgent strings above identify the requestor
68		-as human whereas the second two identify the requestor as a spider.
	67	+Thus the first two UserAgent strings above identify the requester
	68	+as human whereas the second two identify the requester as a spider.
69	69	Note that the UserAgent string is completely under the control
70		-of the requestor and so a malicious spider can forge a UserAgent
	70	+of the requester and so a malicious spider can forge a UserAgent
71	71	string that makes it look like a human. But most spiders truly
72	72	seem to desire to "play nicely" on the internet and are quite open
73	73	about the fact that they are a spider. And so the UserAgent string
74	74	provides a good first-guess about whether or not a request originates
75	75	from a human or a spider.
		@@ -82,26 +82,26 @@
82	82	gives humans easy access to the hyperlinks while preventing spiders
83	83	from walking the millions of pages on a typical Fossil site.
84	84
85	85	But the hyperlinks are not enabled directly with the setting above.
86	86	Instead, the HTML code that is generated contains anchor tags ("<a>")
87		-without "href=" attributes. Then, javascript code is added to the
	87	+without "href=" attributes. Then, JavaScript code is added to the
88	88	end of the page that goes back and fills in the "href=" attributes of
89	89	the anchor tags with the hyperlink targets, thus enabling the hyperlinks.
90		-This extra step of using javascript to enable the hyperlink targets
	90	+This extra step of using JavaScript to enable the hyperlink targets
91	91	is a security measure against spiders that forge a human-looking
92		-UserAgent string. Most spiders do not bother to run javascript and
	92	+UserAgent string. Most spiders do not bother to run JavaScript and
93	93	so to the spider the empty anchor tag will be useless. But all modern
94		-web browsers implement javascript, so hyperlinks will show up
	94	+web browsers implement JavaScript, so hyperlinks will show up
95	95	normally for human users.
96	96
97	97	<h2>Further defenses</h2>
98	98
99	99	Recently (as of this writing, in the spring of 2013) the Fossil server
100	100	on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101	101	by Chinese spiders that use forged UserAgent strings to make them look
102		-like normal web browsers and which interpret javascript. We do not
	102	+like normal web browsers and which interpret JavaScript. We do not
103	103	believe these attacks to be nefarious since SQLite is public domain
104	104	and the attackers could obtain all information they ever wanted to
105	105	know about SQLite simply by cloning the repository. Instead, we
106	106	believe these "attacks" are coming from "script kiddies". But regardless
107	107	of whether or not malice is involved, these attacks do present
		@@ -110,27 +110,27 @@
110	110	For this reason, additional defenses against
111	111	spiders have been put in place.
112	112
113	113	On the Admin/Access page of Fossil, just below the
114	114	"<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115		-setting, there are now two additional subsettings that can be optionally
	115	+setting, there are now two additional sub-settings that can be optionally
116	116	enabled to control hyperlinks.
117	117
118		-The first subsetting waits to run the
119		-javascript that sets the "href=" attributes on anchor tags until after
	118	+The first sub-setting waits to run the
	119	+JavaScript that sets the "href=" attributes on anchor tags until after
120	120	at least one "mouseover" event has been detected on the <body>
121	121	element of the page. The thinking here is that spiders will not be
122	122	simulating mouse motion and so no mouseover events will ever occur and
123	123	hence the hyperlinks will never become enabled for spiders.
124	124
125		-The second new subsetting is a delay (in milliseconds) before setting
	125	+The second new sub-setting is a delay (in milliseconds) before setting
126	126	the "href=" attributes on anchor tags. The default value for this
127	127	delay is 10 milliseconds. The idea here is that a spider will try to
128	128	render the page immediately, and will not wait for delayed scripts
129	129	to be run, thus will never enable the hyperlinks.
130	130
131		-These two subsettings can be used separately or together. If used together,
	131	+These two sub-settings can be used separately or together. If used together,
132	132	then the delay timer does not start until after the first mouse movement
133	133	is detected.
134	134
135	135	See also [./server.wiki#loadmgmt\|Managing Server Load] for a description
136	136	of how expensive pages can be disabled when the server is under heavy
137	137

	--- www/antibot.wiki
	+++ www/antibot.wiki
	@@ -62,14 +62,14 @@
62
63	The first two UserAgent strings above identify Firefox 19 and
64	Internet Explorer 8.0, both running on Windows NT. The third
65	example is the spider used by Google to index the internet.
66	The fourth example is the "wget" utility running on OpenBSD.
67	Thus the first two UserAgent strings above identify the requestor
68	as human whereas the second two identify the requestor as a spider.
69	Note that the UserAgent string is completely under the control
70	of the requestor and so a malicious spider can forge a UserAgent
71	string that makes it look like a human. But most spiders truly
72	seem to desire to "play nicely" on the internet and are quite open
73	about the fact that they are a spider. And so the UserAgent string
74	provides a good first-guess about whether or not a request originates
75	from a human or a spider.
	@@ -82,26 +82,26 @@
82	gives humans easy access to the hyperlinks while preventing spiders
83	from walking the millions of pages on a typical Fossil site.
84
85	But the hyperlinks are not enabled directly with the setting above.
86	Instead, the HTML code that is generated contains anchor tags ("<a>")
87	without "href=" attributes. Then, javascript code is added to the
88	end of the page that goes back and fills in the "href=" attributes of
89	the anchor tags with the hyperlink targets, thus enabling the hyperlinks.
90	This extra step of using javascript to enable the hyperlink targets
91	is a security measure against spiders that forge a human-looking
92	UserAgent string. Most spiders do not bother to run javascript and
93	so to the spider the empty anchor tag will be useless. But all modern
94	web browsers implement javascript, so hyperlinks will show up
95	normally for human users.
96
97	<h2>Further defenses</h2>
98
99	Recently (as of this writing, in the spring of 2013) the Fossil server
100	on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101	by Chinese spiders that use forged UserAgent strings to make them look
102	like normal web browsers and which interpret javascript. We do not
103	believe these attacks to be nefarious since SQLite is public domain
104	and the attackers could obtain all information they ever wanted to
105	know about SQLite simply by cloning the repository. Instead, we
106	believe these "attacks" are coming from "script kiddies". But regardless
107	of whether or not malice is involved, these attacks do present
	@@ -110,27 +110,27 @@
110	For this reason, additional defenses against
111	spiders have been put in place.
112
113	On the Admin/Access page of Fossil, just below the
114	"<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115	setting, there are now two additional subsettings that can be optionally
116	enabled to control hyperlinks.
117
118	The first subsetting waits to run the
119	javascript that sets the "href=" attributes on anchor tags until after
120	at least one "mouseover" event has been detected on the <body>
121	element of the page. The thinking here is that spiders will not be
122	simulating mouse motion and so no mouseover events will ever occur and
123	hence the hyperlinks will never become enabled for spiders.
124
125	The second new subsetting is a delay (in milliseconds) before setting
126	the "href=" attributes on anchor tags. The default value for this
127	delay is 10 milliseconds. The idea here is that a spider will try to
128	render the page immediately, and will not wait for delayed scripts
129	to be run, thus will never enable the hyperlinks.
130
131	These two subsettings can be used separately or together. If used together,
132	then the delay timer does not start until after the first mouse movement
133	is detected.
134
135	See also [./server.wiki#loadmgmt\|Managing Server Load] for a description
136	of how expensive pages can be disabled when the server is under heavy
137

	--- www/antibot.wiki
	+++ www/antibot.wiki
	@@ -62,14 +62,14 @@
62
63	The first two UserAgent strings above identify Firefox 19 and
64	Internet Explorer 8.0, both running on Windows NT. The third
65	example is the spider used by Google to index the internet.
66	The fourth example is the "wget" utility running on OpenBSD.
67	Thus the first two UserAgent strings above identify the requester
68	as human whereas the second two identify the requester as a spider.
69	Note that the UserAgent string is completely under the control
70	of the requester and so a malicious spider can forge a UserAgent
71	string that makes it look like a human. But most spiders truly
72	seem to desire to "play nicely" on the internet and are quite open
73	about the fact that they are a spider. And so the UserAgent string
74	provides a good first-guess about whether or not a request originates
75	from a human or a spider.
	@@ -82,26 +82,26 @@
82	gives humans easy access to the hyperlinks while preventing spiders
83	from walking the millions of pages on a typical Fossil site.
84
85	But the hyperlinks are not enabled directly with the setting above.
86	Instead, the HTML code that is generated contains anchor tags ("<a>")
87	without "href=" attributes. Then, JavaScript code is added to the
88	end of the page that goes back and fills in the "href=" attributes of
89	the anchor tags with the hyperlink targets, thus enabling the hyperlinks.
90	This extra step of using JavaScript to enable the hyperlink targets
91	is a security measure against spiders that forge a human-looking
92	UserAgent string. Most spiders do not bother to run JavaScript and
93	so to the spider the empty anchor tag will be useless. But all modern
94	web browsers implement JavaScript, so hyperlinks will show up
95	normally for human users.
96
97	<h2>Further defenses</h2>
98
99	Recently (as of this writing, in the spring of 2013) the Fossil server
100	on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101	by Chinese spiders that use forged UserAgent strings to make them look
102	like normal web browsers and which interpret JavaScript. We do not
103	believe these attacks to be nefarious since SQLite is public domain
104	and the attackers could obtain all information they ever wanted to
105	know about SQLite simply by cloning the repository. Instead, we
106	believe these "attacks" are coming from "script kiddies". But regardless
107	of whether or not malice is involved, these attacks do present
	@@ -110,27 +110,27 @@
110	For this reason, additional defenses against
111	spiders have been put in place.
112
113	On the Admin/Access page of Fossil, just below the
114	"<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115	setting, there are now two additional sub-settings that can be optionally
116	enabled to control hyperlinks.
117
118	The first sub-setting waits to run the
119	JavaScript that sets the "href=" attributes on anchor tags until after
120	at least one "mouseover" event has been detected on the <body>
121	element of the page. The thinking here is that spiders will not be
122	simulating mouse motion and so no mouseover events will ever occur and
123	hence the hyperlinks will never become enabled for spiders.
124
125	The second new sub-setting is a delay (in milliseconds) before setting
126	the "href=" attributes on anchor tags. The default value for this
127	delay is 10 milliseconds. The idea here is that a spider will try to
128	render the page immediately, and will not wait for delayed scripts
129	to be run, thus will never enable the hyperlinks.
130
131	These two sub-settings can be used separately or together. If used together,
132	then the delay timer does not start until after the first mouse movement
133	is detected.
134
135	See also [./server.wiki#loadmgmt\|Managing Server Load] for a description
136	of how expensive pages can be disabled when the server is under heavy
137

M www/branching.wiki

+2 -2

		--- www/branching.wiki
		+++ www/branching.wiki
		@@ -239,11 +239,11 @@
239	239	<li><p id="offline">By Fossil itself when two users check in children to the same
240	240	leaf of a branch, as in Figure 2. If the fork occurs because
241	241	autosync is disabled on one or both of the repositories or because
242	242	the user doing the check-in has no network connection at the moment
243	243	of the commit, Fossil has no way of knowing that it is creating a
244		- fork until the two repositories are later sync'd.</p></li>
	244	+ fork until the two repositories are later synchronized.</p></li>
245	245
246	246	<li><p id="dist-clone">By Fossil when the cloning hierarchy is more
247	247	than 2 levels deep.
248	248	<br><br>
249	249	[./sync.wiki\|Fossil's synchronization protocol] is a two-party
		@@ -591,10 +591,10 @@
591	591	workaround for Fossil's [./shunning.wiki\|normal inability to forget
592	592	history]: we usually don't want to actually <i>remove</i> history, but
593	593	would like to sometimes set some of it aside under a new label.
594	594
595	595	Because some VCSes can't cope with duplicate branch names, Fossil
596		-collapses such names down on export using the same timestamp based
	596	+collapses such names down on export using the same time stamp based
597	597	arbitration logic, so that only the branch with the newest checkin gets
598	598	the branch name in the export.
599	599
600	600	All of the above is true of tags in general, not just branches.
601	601

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -239,11 +239,11 @@
239	<li><p id="offline">By Fossil itself when two users check in children to the same
240	leaf of a branch, as in Figure 2. If the fork occurs because
241	autosync is disabled on one or both of the repositories or because
242	the user doing the check-in has no network connection at the moment
243	of the commit, Fossil has no way of knowing that it is creating a
244	fork until the two repositories are later sync'd.</p></li>
245
246	<li><p id="dist-clone">By Fossil when the cloning hierarchy is more
247	than 2 levels deep.
248	<br><br>
249	[./sync.wiki\|Fossil's synchronization protocol] is a two-party
	@@ -591,10 +591,10 @@
591	workaround for Fossil's [./shunning.wiki\|normal inability to forget
592	history]: we usually don't want to actually <i>remove</i> history, but
593	would like to sometimes set some of it aside under a new label.
594
595	Because some VCSes can't cope with duplicate branch names, Fossil
596	collapses such names down on export using the same timestamp based
597	arbitration logic, so that only the branch with the newest checkin gets
598	the branch name in the export.
599
600	All of the above is true of tags in general, not just branches.
601

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -239,11 +239,11 @@
239	<li><p id="offline">By Fossil itself when two users check in children to the same
240	leaf of a branch, as in Figure 2. If the fork occurs because
241	autosync is disabled on one or both of the repositories or because
242	the user doing the check-in has no network connection at the moment
243	of the commit, Fossil has no way of knowing that it is creating a
244	fork until the two repositories are later synchronized.</p></li>
245
246	<li><p id="dist-clone">By Fossil when the cloning hierarchy is more
247	than 2 levels deep.
248	<br><br>
249	[./sync.wiki\|Fossil's synchronization protocol] is a two-party
	@@ -591,10 +591,10 @@
591	workaround for Fossil's [./shunning.wiki\|normal inability to forget
592	history]: we usually don't want to actually <i>remove</i> history, but
593	would like to sometimes set some of it aside under a new label.
594
595	Because some VCSes can't cope with duplicate branch names, Fossil
596	collapses such names down on export using the same time stamp based
597	arbitration logic, so that only the branch with the newest checkin gets
598	the branch name in the export.
599
600	All of the above is true of tags in general, not just branches.
601

M www/concepts.wiki

+1 -1

		--- www/concepts.wiki
		+++ www/concepts.wiki
		@@ -196,11 +196,11 @@
196	196	or [./build.wiki \| compiling it yourself]) and then
197	197	putting that file somewhere on your PATH.
198	198
199	199	Fossil is completely self-contained. It is not necessary to
200	200	install any other software in order to use Fossil. You do <u>not</u> need
201		-CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL,
	201	+CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, Apache, PostgreSQL, MySQL,
202	202	SQLite, patch, or any similar software on your system in order to use
203	203	Fossil effectively. You will want to have some kind of text editor
204	204	for entering check-in comments. Fossil will use whatever text editor
205	205	is identified by your VISUAL environment variable. Fossil will also
206	206	use GPG to clearsign your manifests if you happen to have it installed,
207	207

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -196,11 +196,11 @@
196	or [./build.wiki \| compiling it yourself]) and then
197	putting that file somewhere on your PATH.
198
199	Fossil is completely self-contained. It is not necessary to
200	install any other software in order to use Fossil. You do <u>not</u> need
201	CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL,
202	SQLite, patch, or any similar software on your system in order to use
203	Fossil effectively. You will want to have some kind of text editor
204	for entering check-in comments. Fossil will use whatever text editor
205	is identified by your VISUAL environment variable. Fossil will also
206	use GPG to clearsign your manifests if you happen to have it installed,
207

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -196,11 +196,11 @@
196	or [./build.wiki \| compiling it yourself]) and then
197	putting that file somewhere on your PATH.
198
199	Fossil is completely self-contained. It is not necessary to
200	install any other software in order to use Fossil. You do <u>not</u> need
201	CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, Apache, PostgreSQL, MySQL,
202	SQLite, patch, or any similar software on your system in order to use
203	Fossil effectively. You will want to have some kind of text editor
204	for entering check-in comments. Fossil will use whatever text editor
205	is identified by your VISUAL environment variable. Fossil will also
206	use GPG to clearsign your manifests if you happen to have it installed,
207

M www/contribute.wiki

+1 -1

		--- www/contribute.wiki
		+++ www/contribute.wiki
		@@ -55,11 +55,11 @@
55	55	Contributors are required to following the
56	56	[./checkin.wiki \| pre-checkin checklist] prior to every check-in to
57	57	the Fossil self-hosting repository. This checklist is short and succinct
58	58	and should only require a few seconds to follow. Contributors
59	59	should print out a copy of the pre-checkin checklist and keep
60		-it on a notecard beside their workstations, for quick reference.
	60	+it on a note card beside their workstations, for quick reference.
61	61
62	62	Contributors should review the
63	63	[./style.wiki \| Coding Style Guidelines] and mimic the coding style
64	64	used through the rest of the Fossil source code. Your code should
65	65	blend in. A third-party reader should be unable to distinguish your
66	66

	--- www/contribute.wiki
	+++ www/contribute.wiki
	@@ -55,11 +55,11 @@
55	Contributors are required to following the
56	[./checkin.wiki \| pre-checkin checklist] prior to every check-in to
57	the Fossil self-hosting repository. This checklist is short and succinct
58	and should only require a few seconds to follow. Contributors
59	should print out a copy of the pre-checkin checklist and keep
60	it on a notecard beside their workstations, for quick reference.
61
62	Contributors should review the
63	[./style.wiki \| Coding Style Guidelines] and mimic the coding style
64	used through the rest of the Fossil source code. Your code should
65	blend in. A third-party reader should be unable to distinguish your
66

	--- www/contribute.wiki
	+++ www/contribute.wiki
	@@ -55,11 +55,11 @@
55	Contributors are required to following the
56	[./checkin.wiki \| pre-checkin checklist] prior to every check-in to
57	the Fossil self-hosting repository. This checklist is short and succinct
58	and should only require a few seconds to follow. Contributors
59	should print out a copy of the pre-checkin checklist and keep
60	it on a note card beside their workstations, for quick reference.
61
62	Contributors should review the
63	[./style.wiki \| Coding Style Guidelines] and mimic the coding style
64	used through the rest of the Fossil source code. Your code should
65	blend in. A third-party reader should be unable to distinguish your
66

M www/event.wiki

+1 -1

		--- www/event.wiki
		+++ www/event.wiki
		@@ -33,11 +33,11 @@
33	33	various process steps. For example, a technote can be used to record
34	34	the successful completion of a long-running test, perhaps with
35	35	performance results and details of where the test was run and who
36	36	ran it recorded in the wiki content.
37	37
38		- * <b>News Articles</b>. Significant occurrences in the lifecycle of
	38	+ * <b>News Articles</b>. Significant occurrences in the life cycle of
39	39	a project can be recorded as news articles using technotes. Perhaps the
40	40	domain name of the canonical website for a project changes, or new
41	41	server hardware is obtained. Such happenings are appropriate for
42	42	reporting as news.
43	43
44	44

	--- www/event.wiki
	+++ www/event.wiki
	@@ -33,11 +33,11 @@
33	various process steps. For example, a technote can be used to record
34	the successful completion of a long-running test, perhaps with
35	performance results and details of where the test was run and who
36	ran it recorded in the wiki content.
37
38	* <b>News Articles</b>. Significant occurrences in the lifecycle of
39	a project can be recorded as news articles using technotes. Perhaps the
40	domain name of the canonical website for a project changes, or new
41	server hardware is obtained. Such happenings are appropriate for
42	reporting as news.
43
44

	--- www/event.wiki
	+++ www/event.wiki
	@@ -33,11 +33,11 @@
33	various process steps. For example, a technote can be used to record
34	the successful completion of a long-running test, perhaps with
35	performance results and details of where the test was run and who
36	ran it recorded in the wiki content.
37
38	* <b>News Articles</b>. Significant occurrences in the life cycle of
39	a project can be recorded as news articles using technotes. Perhaps the
40	domain name of the canonical website for a project changes, or new
41	server hardware is obtained. Such happenings are appropriate for
42	reporting as news.
43
44

M www/forum.wiki

+1 -1

		--- www/forum.wiki
		+++ www/forum.wiki
		@@ -59,11 +59,11 @@
59	59	* <b>Contribute Off-Line:</b> Fossil forum posts work like any other
60	60	insertion into the repository, so a user can create new threads and
61	61	reply to existing ones while off-line, then sync their
62	62	contributions to the server they cloned from when back on-line.
63	63	Yes, you can post to the forum from inside a tent, miles from the
64		- nearest wifi router or cellular data tower.
	64	+ nearest WiFi router or cellular data tower.
65	65
66	66	* <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum
67	67	posts are normal Fossil artifacts, you can interlink them with
68	68	other Fossil artifacts using short internal links: link to forum
69	69	threads from a [./tickets.wiki \| ticket], link to a wiki document
70	70

	--- www/forum.wiki
	+++ www/forum.wiki
	@@ -59,11 +59,11 @@
59	* <b>Contribute Off-Line:</b> Fossil forum posts work like any other
60	insertion into the repository, so a user can create new threads and
61	reply to existing ones while off-line, then sync their
62	contributions to the server they cloned from when back on-line.
63	Yes, you can post to the forum from inside a tent, miles from the
64	nearest wifi router or cellular data tower.
65
66	* <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum
67	posts are normal Fossil artifacts, you can interlink them with
68	other Fossil artifacts using short internal links: link to forum
69	threads from a [./tickets.wiki \| ticket], link to a wiki document
70

	--- www/forum.wiki
	+++ www/forum.wiki
	@@ -59,11 +59,11 @@
59	* <b>Contribute Off-Line:</b> Fossil forum posts work like any other
60	insertion into the repository, so a user can create new threads and
61	reply to existing ones while off-line, then sync their
62	contributions to the server they cloned from when back on-line.
63	Yes, you can post to the forum from inside a tent, miles from the
64	nearest WiFi router or cellular data tower.
65
66	* <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum
67	posts are normal Fossil artifacts, you can interlink them with
68	other Fossil artifacts using short internal links: link to forum
69	threads from a [./tickets.wiki \| ticket], link to a wiki document
70

M www/fossil-v-git.wiki

+8 -8

		--- www/fossil-v-git.wiki
		+++ www/fossil-v-git.wiki
		@@ -8,11 +8,11 @@
8	8	version control systems] which store a tree of check-in objects to a
9	9	local repository clone. In both systems, the local clone starts out as a
10	10	full copy of the remote parent. New content gets added to the local
11	11	clone and then later optionally pushed up to the remote, and changes to
12	12	the remote can be pulled down to the local clone at will. Both systems
13		-offer diffing, patching, branching, merging, cherrypicking, bisecting,
	13	+offer diffing, patching, branching, merging, cherry-picking, bisecting,
14	14	private branches, a stash, etc.
15	15
16	16	Fossil has inbound and outbound Git conversion features, so if you start
17	17	out using one DVCS and later decide you like the other better, you can
18	18	easily [./inout.wiki \| move your version-controlled file content].¹
		@@ -234,14 +234,14 @@
234	234	an expressive, declarative language, it has an outsized contribution to
235	235	Fossil's user-visible functionality.
236	236
237	237	Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
238	238	necessary.⁵ The server-side
239		-UI scripting usse a custom minimal
	239	+UI scripting uses a custom minimal
240	240	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
241	241	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
242		-embedeed into Fossil itself. Fossil's build system and test suite are
	242	+embedded into Fossil itself. Fossil's build system and test suite are
243	243	largely based on Tcl.⁶ All of this is quite portable.
244	244
245	245	About half of Git's code is POSIX C, and about a third is POSIX shell
246	246	code. This is largely why the so-called "Git for Windows" distributions
247	247	(both [https://git-scm.com/download/win\|first-party] and
		@@ -298,11 +298,11 @@
298	298
299	299	Git promotes the Linux kernel's bazaar development style, in which a
300	300	loosely-associated mass of developers contribute their work through
301	301	[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|a
302	302	hierarchy of lieutenants] who manage and clean up these contributions
303		-for consideration by Linus Torvalds, who has the power to cherrypick
	303	+for consideration by Linus Torvalds, who has the power to cherry-pick
304	304	individual contributions into his version of the Linux kernel. Git
305	305	allows an anonymous developer to rebase and push specific locally-named
306	306	private branches, so that a Git repo clone often isn't really a clone at
307	307	all: it may have an arbitrary number of differences relative to the
308	308	repository it originally cloned from. Git encourages siloed development.
		@@ -320,11 +320,11 @@
320	320	<li><p><b>Personal engagement:</b> SQLite's developers know each
321	321	other by name and work together daily on the project.</p></li>
322	322
323	323	<li><p><b>Trust over hierarchy:</b> SQLite's developers check
324	324	changes into their local repository, and these are immediately and
325		- automatically sync'd up to the central repository; there is no
	325	+ automatically synchronized up to the central repository; there is no
326	326	"[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|dictator
327	327	and lieutenants]" hierarchy as with Linux kernel contributions. D.
328	328	Richard Hipp rarely overrides decisions made by those he has trusted
329	329	with commit access on his repositories. Fossil allows you to give
330	330	[/doc/trunk/www/admin-v-setup.md\|some users] more power over what
		@@ -526,11 +526,11 @@
526	526	<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
527	527
528	528	A "repository" in Git is a pile-of-files in the <tt>.git</tt>
529	529	subdirectory of a single check-out. The working check-out directory and
530	530	the <tt>.git</tt> repository subdirectory are normally in the same
531		-directory within the filesystem.
	531	+directory within the file system.
532	532
533	533	With Fossil, a "repository" is a single SQLite database file that can be
534	534	stored anywhere. There can be multiple active check-outs from the same
535	535	repository, perhaps open on different branches or on different snapshots
536	536	of the same branch. It is common in Fossil to switch branches with a
		@@ -698,11 +698,11 @@
698	698	several parts, so that it is not strictly true that "everything" on
699	699	it is in the self-hosting Fossil project repo. The web forum is
700	700	hosted as [https://fossil-scm.org/forum/\|a separate Fossil repo]
701	701	from the [https://fossil-scm.org/fossil/\|main Fossil self-hosting
702	702	repo] for administration reasons, and the Download page content
703		- isn't normally sync'd with a "<tt>fossil clone</tt>" command unless
	703	+ isn't normally synchronized with a "<tt>fossil clone</tt>" command unless
704	704	you add the "-u" option. (See "[./aboutdownload.wiki\|How the
705	705	Download Page Works]" for details.) There may also be some purely
706	706	static elements of the web site served via D. Richard Hipp's own
707	707	lightweight web server,
708	708	<tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|althttpd]</tt>,
		@@ -718,11 +718,11 @@
718	718	<li><p>This means you can give up waiting for Fossil to be ported to
719	719	the PDP-11, but we remain hopeful that someone may eventually port
720	720	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
721	721
722	722	<li><p>We try to keep use of Javascript to a minimum in the web UI,
723		- and we always try to provide sensible fallbacks for those that run
	723	+ and we always try to provide sensible fall-backs for those that run
724	724	their browsers with Javascript disabled. Some features of the web UI
725	725	simply won't run without Javascript, but the UI behavior does
726	726	degrade gracefully.
727	727
728	728	<li><p>"Why is there all this Tcl in and around Fossil?" you may
729	729

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -8,11 +8,11 @@
8	version control systems] which store a tree of check-in objects to a
9	local repository clone. In both systems, the local clone starts out as a
10	full copy of the remote parent. New content gets added to the local
11	clone and then later optionally pushed up to the remote, and changes to
12	the remote can be pulled down to the local clone at will. Both systems
13	offer diffing, patching, branching, merging, cherrypicking, bisecting,
14	private branches, a stash, etc.
15
16	Fossil has inbound and outbound Git conversion features, so if you start
17	out using one DVCS and later decide you like the other better, you can
18	easily [./inout.wiki \| move your version-controlled file content].¹
	@@ -234,14 +234,14 @@
234	an expressive, declarative language, it has an outsized contribution to
235	Fossil's user-visible functionality.
236
237	Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
238	necessary.⁵ The server-side
239	UI scripting usse a custom minimal
240	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
241	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
242	embedeed into Fossil itself. Fossil's build system and test suite are
243	largely based on Tcl.⁶ All of this is quite portable.
244
245	About half of Git's code is POSIX C, and about a third is POSIX shell
246	code. This is largely why the so-called "Git for Windows" distributions
247	(both [https://git-scm.com/download/win\|first-party] and
	@@ -298,11 +298,11 @@
298
299	Git promotes the Linux kernel's bazaar development style, in which a
300	loosely-associated mass of developers contribute their work through
301	[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|a
302	hierarchy of lieutenants] who manage and clean up these contributions
303	for consideration by Linus Torvalds, who has the power to cherrypick
304	individual contributions into his version of the Linux kernel. Git
305	allows an anonymous developer to rebase and push specific locally-named
306	private branches, so that a Git repo clone often isn't really a clone at
307	all: it may have an arbitrary number of differences relative to the
308	repository it originally cloned from. Git encourages siloed development.
	@@ -320,11 +320,11 @@
320	<li><p><b>Personal engagement:</b> SQLite's developers know each
321	other by name and work together daily on the project.</p></li>
322
323	<li><p><b>Trust over hierarchy:</b> SQLite's developers check
324	changes into their local repository, and these are immediately and
325	automatically sync'd up to the central repository; there is no
326	"[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|dictator
327	and lieutenants]" hierarchy as with Linux kernel contributions. D.
328	Richard Hipp rarely overrides decisions made by those he has trusted
329	with commit access on his repositories. Fossil allows you to give
330	[/doc/trunk/www/admin-v-setup.md\|some users] more power over what
	@@ -526,11 +526,11 @@
526	<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
527
528	A "repository" in Git is a pile-of-files in the <tt>.git</tt>
529	subdirectory of a single check-out. The working check-out directory and
530	the <tt>.git</tt> repository subdirectory are normally in the same
531	directory within the filesystem.
532
533	With Fossil, a "repository" is a single SQLite database file that can be
534	stored anywhere. There can be multiple active check-outs from the same
535	repository, perhaps open on different branches or on different snapshots
536	of the same branch. It is common in Fossil to switch branches with a
	@@ -698,11 +698,11 @@
698	several parts, so that it is not strictly true that "everything" on
699	it is in the self-hosting Fossil project repo. The web forum is
700	hosted as [https://fossil-scm.org/forum/\|a separate Fossil repo]
701	from the [https://fossil-scm.org/fossil/\|main Fossil self-hosting
702	repo] for administration reasons, and the Download page content
703	isn't normally sync'd with a "<tt>fossil clone</tt>" command unless
704	you add the "-u" option. (See "[./aboutdownload.wiki\|How the
705	Download Page Works]" for details.) There may also be some purely
706	static elements of the web site served via D. Richard Hipp's own
707	lightweight web server,
708	<tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|althttpd]</tt>,
	@@ -718,11 +718,11 @@
718	<li><p>This means you can give up waiting for Fossil to be ported to
719	the PDP-11, but we remain hopeful that someone may eventually port
720	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
721
722	<li><p>We try to keep use of Javascript to a minimum in the web UI,
723	and we always try to provide sensible fallbacks for those that run
724	their browsers with Javascript disabled. Some features of the web UI
725	simply won't run without Javascript, but the UI behavior does
726	degrade gracefully.
727
728	<li><p>"Why is there all this Tcl in and around Fossil?" you may
729

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -8,11 +8,11 @@
8	version control systems] which store a tree of check-in objects to a
9	local repository clone. In both systems, the local clone starts out as a
10	full copy of the remote parent. New content gets added to the local
11	clone and then later optionally pushed up to the remote, and changes to
12	the remote can be pulled down to the local clone at will. Both systems
13	offer diffing, patching, branching, merging, cherry-picking, bisecting,
14	private branches, a stash, etc.
15
16	Fossil has inbound and outbound Git conversion features, so if you start
17	out using one DVCS and later decide you like the other better, you can
18	easily [./inout.wiki \| move your version-controlled file content].¹
	@@ -234,14 +234,14 @@
234	an expressive, declarative language, it has an outsized contribution to
235	Fossil's user-visible functionality.
236
237	Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
238	necessary.⁵ The server-side
239	UI scripting uses a custom minimal
240	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
241	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
242	embedded into Fossil itself. Fossil's build system and test suite are
243	largely based on Tcl.⁶ All of this is quite portable.
244
245	About half of Git's code is POSIX C, and about a third is POSIX shell
246	code. This is largely why the so-called "Git for Windows" distributions
247	(both [https://git-scm.com/download/win\|first-party] and
	@@ -298,11 +298,11 @@
298
299	Git promotes the Linux kernel's bazaar development style, in which a
300	loosely-associated mass of developers contribute their work through
301	[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|a
302	hierarchy of lieutenants] who manage and clean up these contributions
303	for consideration by Linus Torvalds, who has the power to cherry-pick
304	individual contributions into his version of the Linux kernel. Git
305	allows an anonymous developer to rebase and push specific locally-named
306	private branches, so that a Git repo clone often isn't really a clone at
307	all: it may have an arbitrary number of differences relative to the
308	repository it originally cloned from. Git encourages siloed development.
	@@ -320,11 +320,11 @@
320	<li><p><b>Personal engagement:</b> SQLite's developers know each
321	other by name and work together daily on the project.</p></li>
322
323	<li><p><b>Trust over hierarchy:</b> SQLite's developers check
324	changes into their local repository, and these are immediately and
325	automatically synchronized up to the central repository; there is no
326	"[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow\|dictator
327	and lieutenants]" hierarchy as with Linux kernel contributions. D.
328	Richard Hipp rarely overrides decisions made by those he has trusted
329	with commit access on his repositories. Fossil allows you to give
330	[/doc/trunk/www/admin-v-setup.md\|some users] more power over what
	@@ -526,11 +526,11 @@
526	<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>
527
528	A "repository" in Git is a pile-of-files in the <tt>.git</tt>
529	subdirectory of a single check-out. The working check-out directory and
530	the <tt>.git</tt> repository subdirectory are normally in the same
531	directory within the file system.
532
533	With Fossil, a "repository" is a single SQLite database file that can be
534	stored anywhere. There can be multiple active check-outs from the same
535	repository, perhaps open on different branches or on different snapshots
536	of the same branch. It is common in Fossil to switch branches with a
	@@ -698,11 +698,11 @@
698	several parts, so that it is not strictly true that "everything" on
699	it is in the self-hosting Fossil project repo. The web forum is
700	hosted as [https://fossil-scm.org/forum/\|a separate Fossil repo]
701	from the [https://fossil-scm.org/fossil/\|main Fossil self-hosting
702	repo] for administration reasons, and the Download page content
703	isn't normally synchronized with a "<tt>fossil clone</tt>" command unless
704	you add the "-u" option. (See "[./aboutdownload.wiki\|How the
705	Download Page Works]" for details.) There may also be some purely
706	static elements of the web site served via D. Richard Hipp's own
707	lightweight web server,
708	<tt>[https://sqlite.org/docsrc/doc/trunk/misc/althttpd.md\|althttpd]</tt>,
	@@ -718,11 +718,11 @@
718	<li><p>This means you can give up waiting for Fossil to be ported to
719	the PDP-11, but we remain hopeful that someone may eventually port
720	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
721
722	<li><p>We try to keep use of Javascript to a minimum in the web UI,
723	and we always try to provide sensible fall-backs for those that run
724	their browsers with Javascript disabled. Some features of the web UI
725	simply won't run without Javascript, but the UI behavior does
726	degrade gracefully.
727
728	<li><p>"Why is there all this Tcl in and around Fossil?" you may
729

M www/fossil_prompt.wiki

+1 -1

		--- www/fossil_prompt.wiki
		+++ www/fossil_prompt.wiki
		@@ -3,11 +3,11 @@
3	3
4	4	Dan Kennedy has contributed a
5	5	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	6	that manipulates the bash prompt to show the status of
7	7	the Fossil repository that the user is currently visiting.
8		-The prompt shows the branch, version, and timestamp for the
	8	+The prompt shows the branch, version, and time stamp for the
9	9	current checkout, and the prompt changes colors from blue to
10	10	red when there are uncommitted changes.
11	11
12	12	To try out this script, simply download it from the link above, then
13	13	type:
14	14

	--- www/fossil_prompt.wiki
	+++ www/fossil_prompt.wiki
	@@ -3,11 +3,11 @@
3
4	Dan Kennedy has contributed a
5	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	that manipulates the bash prompt to show the status of
7	the Fossil repository that the user is currently visiting.
8	The prompt shows the branch, version, and timestamp for the
9	current checkout, and the prompt changes colors from blue to
10	red when there are uncommitted changes.
11
12	To try out this script, simply download it from the link above, then
13	type:
14

	--- www/fossil_prompt.wiki
	+++ www/fossil_prompt.wiki
	@@ -3,11 +3,11 @@
3
4	Dan Kennedy has contributed a
5	[./fossil_prompt.sh?mimetype=text/plain \| bash script]
6	that manipulates the bash prompt to show the status of
7	the Fossil repository that the user is currently visiting.
8	The prompt shows the branch, version, and time stamp for the
9	current checkout, and the prompt changes colors from blue to
10	red when there are uncommitted changes.
11
12	To try out this script, simply download it from the link above, then
13	type:
14

M www/password.wiki

+1 -1

		--- www/password.wiki
		+++ www/password.wiki
		@@ -97,11 +97,11 @@
97	97	write information into the repository database. Hence, login is not
98	98	possible on a Fossil repository with a read-only database file.
99	99
100	100	The user password is sent over the wire as cleartext on the initial
101	101	login attempt. The plan moving forward is to compute the SHA1 hash of
102		-the password on the client using javascript and then send only the hash
	102	+the password on the client using JavaScript and then send only the hash
103	103	over the wire, but that plan has not yet been set in code.
104	104
105	105	<h2>Sync Protocol Authentication</h2>
106	106
107	107	A different authentication mechanism is used when one repository wants
108	108

	--- www/password.wiki
	+++ www/password.wiki
	@@ -97,11 +97,11 @@
97	write information into the repository database. Hence, login is not
98	possible on a Fossil repository with a read-only database file.
99
100	The user password is sent over the wire as cleartext on the initial
101	login attempt. The plan moving forward is to compute the SHA1 hash of
102	the password on the client using javascript and then send only the hash
103	over the wire, but that plan has not yet been set in code.
104
105	<h2>Sync Protocol Authentication</h2>
106
107	A different authentication mechanism is used when one repository wants
108

	--- www/password.wiki
	+++ www/password.wiki
	@@ -97,11 +97,11 @@
97	write information into the repository database. Hence, login is not
98	possible on a Fossil repository with a read-only database file.
99
100	The user password is sent over the wire as cleartext on the initial
101	login attempt. The plan moving forward is to compute the SHA1 hash of
102	the password on the client using JavaScript and then send only the hash
103	over the wire, but that plan has not yet been set in code.
104
105	<h2>Sync Protocol Authentication</h2>
106
107	A different authentication mechanism is used when one repository wants
108

M www/quickstart.wiki

+2 -2

		--- www/quickstart.wiki
		+++ www/quickstart.wiki
		@@ -146,11 +146,11 @@
146	146	<h2>Configuring Your Local Repository</h2>
147	147
148	148	<p>When you create a new repository, either by cloning an existing
149	149	project or create a new project of your own, you usually want to do some
150	150	local configuration. This is easily accomplished using the web-server
151		- that is built into fossil. Start the fossil webserver like this:
	151	+ that is built into fossil. Start the fossil web server like this:
152	152	([/help/ui \| more info])</p>
153	153
154	154	<blockquote>
155	155	<b>fossil ui </b><i> repository-filename</i>
156	156	</blockquote>
		@@ -282,11 +282,11 @@
282	282	</blockquote>
283	283
284	284	<p>The argument to the [/help/merge\|merge] command can be any of the
285	285	version identifier forms that work for [/help/update\|update].
286	286	([./checkin_names.wiki\|more info].)
287		- The merge command has options to cherrypick individual
	287	+ The merge command has options to cherry-pick individual
288	288	changes, or to back out individual changes, if you don't want to
289	289	do a full merge.</p>
290	290
291	291	The merge command puts all changes in your working check-out.
292	292	No changes are made to the repository.
293	293

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -146,11 +146,11 @@
146	<h2>Configuring Your Local Repository</h2>
147
148	<p>When you create a new repository, either by cloning an existing
149	project or create a new project of your own, you usually want to do some
150	local configuration. This is easily accomplished using the web-server
151	that is built into fossil. Start the fossil webserver like this:
152	([/help/ui \| more info])</p>
153
154	<blockquote>
155	<b>fossil ui </b><i> repository-filename</i>
156	</blockquote>
	@@ -282,11 +282,11 @@
282	</blockquote>
283
284	<p>The argument to the [/help/merge\|merge] command can be any of the
285	version identifier forms that work for [/help/update\|update].
286	([./checkin_names.wiki\|more info].)
287	The merge command has options to cherrypick individual
288	changes, or to back out individual changes, if you don't want to
289	do a full merge.</p>
290
291	The merge command puts all changes in your working check-out.
292	No changes are made to the repository.
293

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -146,11 +146,11 @@
146	<h2>Configuring Your Local Repository</h2>
147
148	<p>When you create a new repository, either by cloning an existing
149	project or create a new project of your own, you usually want to do some
150	local configuration. This is easily accomplished using the web-server
151	that is built into fossil. Start the fossil web server like this:
152	([/help/ui \| more info])</p>
153
154	<blockquote>
155	<b>fossil ui </b><i> repository-filename</i>
156	</blockquote>
	@@ -282,11 +282,11 @@
282	</blockquote>
283
284	<p>The argument to the [/help/merge\|merge] command can be any of the
285	version identifier forms that work for [/help/update\|update].
286	([./checkin_names.wiki\|more info].)
287	The merge command has options to cherry-pick individual
288	changes, or to back out individual changes, if you don't want to
289	do a full merge.</p>
290
291	The merge command puts all changes in your working check-out.
292	No changes are made to the repository.
293

M www/server.wiki

+4 -4

		--- www/server.wiki
		+++ www/server.wiki
		@@ -218,11 +218,11 @@
218	218	<li>ALL directories leading to the CGI script must also be readable and the CGI
219	219	script itself must be executable for the user under which it will run (which often differs
220	220	from the one running the web server - consult your site's documentation or administrator).</li>
221	221	<li>The repository file AND the directory containing it must be writable by the same account
222	222	which executes the Fossil binary (again, this might differ from the WWW user). The directory
223		- needs to be writable so that sqlite can write its journal files.</li>
	223	+ needs to be writable so that SQLite can write its journal files.</li>
224	224	<li>Fossil must be able to create temporary files, the default directory
225	225	for which depends on the OS. When the CGI process is operating within
226	226	a chroot, ensure that this directory exists and is readable/writeable
227	227	by the user who executes the Fossil binary.</li>
228	228	</ul>
		@@ -261,11 +261,11 @@
261	261
262	262	The [/help/server\|fossil server] command, described above as a way of
263	263	starting a stand-alone web server, can also be used for SCGI. Simply add
264	264	the --scgi command-line option and the stand-alone server will interpret
265	265	and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can
266		-be used in combination with a webserver (such as [http://nginx.org\|Nginx])
	266	+be used in combination with a web server (such as [http://nginx.org\|Nginx])
267	267	that does not support CGI. A typical Nginx configuration to support SCGI
268	268	with Fossil would look something like this:
269	269
270	270	<blockquote><pre>
271	271	location /demo_project/ {
		@@ -349,11 +349,11 @@
349	349	The webpage cache is activated using the [/help?cmd=cache\|fossil cache init]
350	350	command-line on the server. Add a -R option to specify the specific repository
351	351	for which to enable caching. If running this command as root, be sure to
352	352	"chown" the cache database (which is a separate file in the same directory
353	353	and with the same name as the repository but with the suffix changed to ".cache")
354		-to give it write permission for the userid of the webserver.
	354	+to give it write permission for the userid of the web server.
355	355
356	356	To activate the server load control feature
357	357	visit the Admin → Access setup page in the administrative web
358	358	interface; in the "<b>Server Load Average Limit</b>" box
359	359	enter the load average threshold above which "503 Server
		@@ -373,11 +373,11 @@
373	373
374	374	Note that this load-average limiting feature is only available on operating
375	375	systems that support the "getloadavg()" API. Most modern Unix systems have
376	376	this interface, but Windows does not, so the feature will not work on Windows.
377	377	Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg"
378		-file in the "proc" virtual filesystem. If you are running a Fossil instance
	378	+file in the "proc" virtual file system. If you are running a Fossil instance
379	379	inside a chroot() jail on Linux, you will need to make the "/proc" file
380	380	system available inside that jail in order for this feature to work. On
381	381	the [./selfhost.wiki\|self-hosting Fossil repositories], this was accomplished
382	382	by adding a line to the "/etc/fstab" file that looks like:
383	383
384	384

	--- www/server.wiki
	+++ www/server.wiki
	@@ -218,11 +218,11 @@
218	<li>ALL directories leading to the CGI script must also be readable and the CGI
219	script itself must be executable for the user under which it will run (which often differs
220	from the one running the web server - consult your site's documentation or administrator).</li>
221	<li>The repository file AND the directory containing it must be writable by the same account
222	which executes the Fossil binary (again, this might differ from the WWW user). The directory
223	needs to be writable so that sqlite can write its journal files.</li>
224	<li>Fossil must be able to create temporary files, the default directory
225	for which depends on the OS. When the CGI process is operating within
226	a chroot, ensure that this directory exists and is readable/writeable
227	by the user who executes the Fossil binary.</li>
228	</ul>
	@@ -261,11 +261,11 @@
261
262	The [/help/server\|fossil server] command, described above as a way of
263	starting a stand-alone web server, can also be used for SCGI. Simply add
264	the --scgi command-line option and the stand-alone server will interpret
265	and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can
266	be used in combination with a webserver (such as [http://nginx.org\|Nginx])
267	that does not support CGI. A typical Nginx configuration to support SCGI
268	with Fossil would look something like this:
269
270	<blockquote><pre>
271	location /demo_project/ {
	@@ -349,11 +349,11 @@
349	The webpage cache is activated using the [/help?cmd=cache\|fossil cache init]
350	command-line on the server. Add a -R option to specify the specific repository
351	for which to enable caching. If running this command as root, be sure to
352	"chown" the cache database (which is a separate file in the same directory
353	and with the same name as the repository but with the suffix changed to ".cache")
354	to give it write permission for the userid of the webserver.
355
356	To activate the server load control feature
357	visit the Admin → Access setup page in the administrative web
358	interface; in the "<b>Server Load Average Limit</b>" box
359	enter the load average threshold above which "503 Server
	@@ -373,11 +373,11 @@
373
374	Note that this load-average limiting feature is only available on operating
375	systems that support the "getloadavg()" API. Most modern Unix systems have
376	this interface, but Windows does not, so the feature will not work on Windows.
377	Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg"
378	file in the "proc" virtual filesystem. If you are running a Fossil instance
379	inside a chroot() jail on Linux, you will need to make the "/proc" file
380	system available inside that jail in order for this feature to work. On
381	the [./selfhost.wiki\|self-hosting Fossil repositories], this was accomplished
382	by adding a line to the "/etc/fstab" file that looks like:
383
384

	--- www/server.wiki
	+++ www/server.wiki
	@@ -218,11 +218,11 @@
218	<li>ALL directories leading to the CGI script must also be readable and the CGI
219	script itself must be executable for the user under which it will run (which often differs
220	from the one running the web server - consult your site's documentation or administrator).</li>
221	<li>The repository file AND the directory containing it must be writable by the same account
222	which executes the Fossil binary (again, this might differ from the WWW user). The directory
223	needs to be writable so that SQLite can write its journal files.</li>
224	<li>Fossil must be able to create temporary files, the default directory
225	for which depends on the OS. When the CGI process is operating within
226	a chroot, ensure that this directory exists and is readable/writeable
227	by the user who executes the Fossil binary.</li>
228	</ul>
	@@ -261,11 +261,11 @@
261
262	The [/help/server\|fossil server] command, described above as a way of
263	starting a stand-alone web server, can also be used for SCGI. Simply add
264	the --scgi command-line option and the stand-alone server will interpret
265	and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can
266	be used in combination with a web server (such as [http://nginx.org\|Nginx])
267	that does not support CGI. A typical Nginx configuration to support SCGI
268	with Fossil would look something like this:
269
270	<blockquote><pre>
271	location /demo_project/ {
	@@ -349,11 +349,11 @@
349	The webpage cache is activated using the [/help?cmd=cache\|fossil cache init]
350	command-line on the server. Add a -R option to specify the specific repository
351	for which to enable caching. If running this command as root, be sure to
352	"chown" the cache database (which is a separate file in the same directory
353	and with the same name as the repository but with the suffix changed to ".cache")
354	to give it write permission for the userid of the web server.
355
356	To activate the server load control feature
357	visit the Admin → Access setup page in the administrative web
358	interface; in the "<b>Server Load Average Limit</b>" box
359	enter the load average threshold above which "503 Server
	@@ -373,11 +373,11 @@
373
374	Note that this load-average limiting feature is only available on operating
375	systems that support the "getloadavg()" API. Most modern Unix systems have
376	this interface, but Windows does not, so the feature will not work on Windows.
377	Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg"
378	file in the "proc" virtual file system. If you are running a Fossil instance
379	inside a chroot() jail on Linux, you will need to make the "/proc" file
380	system available inside that jail in order for this feature to work. On
381	the [./selfhost.wiki\|self-hosting Fossil repositories], this was accomplished
382	by adding a line to the "/etc/fstab" file that looks like:
383
384

M www/serverext.wiki

+3 -3

		--- www/serverext.wiki
		+++ www/serverext.wiki
		@@ -88,16 +88,16 @@
88	88	[https://www.sqlite.org/src/ext/checklist/self] and
89	89	recent historical versions are available at
90	90	[https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with
91	91	older legacy at [https://sqlite.org/checklistapp/timeline?n=all]
92	92
93		-There is a cascade of CGIs happening here. The webserver that receives
	93	+There is a cascade of CGIs happening here. The web server that receives
94	94	the initial HTTP request runs Fossil as a CGI based on the
95	95	"https://sqlite.org/src" portion of the URL. The Fossil instance then
96	96	runs the checklist sub-CGI based on the "/ext/checklists" suffix. The
97	97	output of the sub-CGI is read by Fossil and then relayed on to the
98		-main webserver which in turn relays the result back to the original client.
	98	+main web server which in turn relays the result back to the original client.
99	99
100	100	<h3>2.2 Example #2</h3>
101	101
102	102	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
103	103	a CGI that looks like this:
		@@ -211,11 +211,11 @@
211	211	will be readable on standard input.
212	212
213	213	<h2>4.0 CGI Outputs</h2>
214	214
215	215	CGI programs construct a reply by writing to standard output. The first
216		-few lines of output are parameters intended for the webserver that invoked
	216	+few lines of output are parameters intended for the web server that invoked
217	217	the CGI. These are followed by a blank line and then the content.
218	218
219	219	Typical parameter output looks like this:
220	220
221	221	<blockquote><verbatim>
222	222

	--- www/serverext.wiki
	+++ www/serverext.wiki
	@@ -88,16 +88,16 @@
88	[https://www.sqlite.org/src/ext/checklist/self] and
89	recent historical versions are available at
90	[https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with
91	older legacy at [https://sqlite.org/checklistapp/timeline?n=all]
92
93	There is a cascade of CGIs happening here. The webserver that receives
94	the initial HTTP request runs Fossil as a CGI based on the
95	"https://sqlite.org/src" portion of the URL. The Fossil instance then
96	runs the checklist sub-CGI based on the "/ext/checklists" suffix. The
97	output of the sub-CGI is read by Fossil and then relayed on to the
98	main webserver which in turn relays the result back to the original client.
99
100	<h3>2.2 Example #2</h3>
101
102	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
103	a CGI that looks like this:
	@@ -211,11 +211,11 @@
211	will be readable on standard input.
212
213	<h2>4.0 CGI Outputs</h2>
214
215	CGI programs construct a reply by writing to standard output. The first
216	few lines of output are parameters intended for the webserver that invoked
217	the CGI. These are followed by a blank line and then the content.
218
219	Typical parameter output looks like this:
220
221	<blockquote><verbatim>
222

	--- www/serverext.wiki
	+++ www/serverext.wiki
	@@ -88,16 +88,16 @@
88	[https://www.sqlite.org/src/ext/checklist/self] and
89	recent historical versions are available at
90	[https://sqlite.org/docsrc/finfo/misc/checklist.tcl] with
91	older legacy at [https://sqlite.org/checklistapp/timeline?n=all]
92
93	There is a cascade of CGIs happening here. The web server that receives
94	the initial HTTP request runs Fossil as a CGI based on the
95	"https://sqlite.org/src" portion of the URL. The Fossil instance then
96	runs the checklist sub-CGI based on the "/ext/checklists" suffix. The
97	output of the sub-CGI is read by Fossil and then relayed on to the
98	main web server which in turn relays the result back to the original client.
99
100	<h3>2.2 Example #2</h3>
101
102	The [https://fossil-scm.org/home\|Fossil self-hosting repository] is also
103	a CGI that looks like this:
	@@ -211,11 +211,11 @@
211	will be readable on standard input.
212
213	<h2>4.0 CGI Outputs</h2>
214
215	CGI programs construct a reply by writing to standard output. The first
216	few lines of output are parameters intended for the web server that invoked
217	the CGI. These are followed by a blank line and then the content.
218
219	Typical parameter output looks like this:
220
221	<blockquote><verbatim>
222

M www/stats.wiki

+1 -1

		--- www/stats.wiki
		+++ www/stats.wiki
		@@ -125,11 +125,11 @@
125	125	(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB"
126	126	means megabytes and kilobytes, not mebibytes and kibibytes.
127	127
128	128	<h2>Analysis And Supplemental Data</h2>
129	129
130		-Perhaps the two most interesting datapoints in the above table are SQLite
	130	+Perhaps the two most interesting data points in the above table are SQLite
131	131	and SLT. SQLite is a long-running project with long revision chains.
132	132	Some of the files in SQLite have been edited over a thousand times.
133	133	Each of these edits is stored as a delta, and hence the SQLite project
134	134	gets excellent 80:1 compression. SLT, on the other hand, consists of
135	135	many large (megabyte-sized) SQL scripts that have one or maybe two
136	136

	--- www/stats.wiki
	+++ www/stats.wiki
	@@ -125,11 +125,11 @@
125	(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB"
126	means megabytes and kilobytes, not mebibytes and kibibytes.
127
128	<h2>Analysis And Supplemental Data</h2>
129
130	Perhaps the two most interesting datapoints in the above table are SQLite
131	and SLT. SQLite is a long-running project with long revision chains.
132	Some of the files in SQLite have been edited over a thousand times.
133	Each of these edits is stored as a delta, and hence the SQLite project
134	gets excellent 80:1 compression. SLT, on the other hand, consists of
135	many large (megabyte-sized) SQL scripts that have one or maybe two
136

	--- www/stats.wiki
	+++ www/stats.wiki
	@@ -125,11 +125,11 @@
125	(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB"
126	means megabytes and kilobytes, not mebibytes and kibibytes.
127
128	<h2>Analysis And Supplemental Data</h2>
129
130	Perhaps the two most interesting data points in the above table are SQLite
131	and SLT. SQLite is a long-running project with long revision chains.
132	Some of the files in SQLite have been edited over a thousand times.
133	Each of these edits is stored as a delta, and hence the SQLite project
134	gets excellent 80:1 compression. SLT, on the other hand, consists of
135	many large (megabyte-sized) SQL scripts that have one or maybe two
136

M www/tech_overview.wiki

+2 -2

		--- www/tech_overview.wiki
		+++ www/tech_overview.wiki
		@@ -166,11 +166,11 @@
166	166	The enduring file format for Fossil is the unordered
167	167	set of artifacts. The compression techniques are just a detail of
168	168	how the current implementation of Fossil happens to store these artifacts
169	169	efficiently on disk.
170	170
171		-All of the original uncompressed and undeltaed artifacts can be extracted
	171	+All of the original uncompressed and un-delta'd artifacts can be extracted
172	172	from a Fossil repository database using
173	173	the [/help/deconstruct \| fossil deconstruct]
174	174	command. Individual artifacts can be extracted using the
175	175	[/help/artifact \| fossil artifact] command.
176	176	When accessing the repository database using raw SQL and the
		@@ -314,11 +314,11 @@
314	314	For Fossil commands that run from within a working checkout, the
315	315	first thing that happens is that Fossil locates the checkout database.
316	316	Fossil first looks in the current directory. If not found there, it
317	317	looks in the parent directory. If not found there, the parent of the
318	318	parent. And so forth until either the checkout database is found
319		-or the search reaches the root of the filesystem. (In the latter case,
	319	+or the search reaches the root of the file system. (In the latter case,
320	320	Fossil returns an error, of course.) Once the checkout database is
321	321	located, it is used to locate the repository database.
322	322
323	323	Notice that the checkout database contains a pointer to the repository
324	324	database but that the repository database has no record of the checkout
325	325

	--- www/tech_overview.wiki
	+++ www/tech_overview.wiki
	@@ -166,11 +166,11 @@
166	The enduring file format for Fossil is the unordered
167	set of artifacts. The compression techniques are just a detail of
168	how the current implementation of Fossil happens to store these artifacts
169	efficiently on disk.
170
171	All of the original uncompressed and undeltaed artifacts can be extracted
172	from a Fossil repository database using
173	the [/help/deconstruct \| fossil deconstruct]
174	command. Individual artifacts can be extracted using the
175	[/help/artifact \| fossil artifact] command.
176	When accessing the repository database using raw SQL and the
	@@ -314,11 +314,11 @@
314	For Fossil commands that run from within a working checkout, the
315	first thing that happens is that Fossil locates the checkout database.
316	Fossil first looks in the current directory. If not found there, it
317	looks in the parent directory. If not found there, the parent of the
318	parent. And so forth until either the checkout database is found
319	or the search reaches the root of the filesystem. (In the latter case,
320	Fossil returns an error, of course.) Once the checkout database is
321	located, it is used to locate the repository database.
322
323	Notice that the checkout database contains a pointer to the repository
324	database but that the repository database has no record of the checkout
325

	--- www/tech_overview.wiki
	+++ www/tech_overview.wiki
	@@ -166,11 +166,11 @@
166	The enduring file format for Fossil is the unordered
167	set of artifacts. The compression techniques are just a detail of
168	how the current implementation of Fossil happens to store these artifacts
169	efficiently on disk.
170
171	All of the original uncompressed and un-delta'd artifacts can be extracted
172	from a Fossil repository database using
173	the [/help/deconstruct \| fossil deconstruct]
174	command. Individual artifacts can be extracted using the
175	[/help/artifact \| fossil artifact] command.
176	When accessing the repository database using raw SQL and the
	@@ -314,11 +314,11 @@
314	For Fossil commands that run from within a working checkout, the
315	first thing that happens is that Fossil locates the checkout database.
316	Fossil first looks in the current directory. If not found there, it
317	looks in the parent directory. If not found there, the parent of the
318	parent. And so forth until either the checkout database is found
319	or the search reaches the root of the file system. (In the latter case,
320	Fossil returns an error, of course.) Once the checkout database is
321	located, it is used to locate the repository database.
322
323	Notice that the checkout database contains a pointer to the repository
324	database but that the repository database has no record of the checkout
325

M www/tickets.wiki

+7 -7

		--- www/tickets.wiki
		+++ www/tickets.wiki
		@@ -10,28 +10,28 @@
10	10
11	11	Each ticket change artifact contains the following information:
12	12
13	13	<ul>
14	14	<li>The ID of the ticket that was changed
15		-<li>The timestamp for when the change occurred
	15	+<li>The time stamp for when the change occurred
16	16	<li>The user who made the change
17	17	<li>A list of key/value pairs that show what changed in the ticket
18	18	</ul>
19	19
20	20	To determine the current state of a particular ticket, Fossil orders
21	21	the change artifacts for that ticket from oldest to most recent,
22		-then applies each change in timestamp order.
	22	+then applies each change in time stamp order.
23	23
24	24	On each change artifact, there are one or more key/value pairs that
25	25	implement the change. The key corresponds to a field of the ticket
26	26	that is modified. The value may either replace the earlier value for
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 realtime. To facility reporting and display
	32	+cumbersome to access in real time. To facility 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
		@@ -132,12 +132,12 @@
132	132
133	133	Each row in the TICKETCHNG table corresponds to a single ticket change
134	134	artifact. The tkt_id field is the integer primary key of the TICKET
135	135	table entry for the corresponding ticket. The tkt_rid field is the
136	136	integer primary key for the BLOB table entry that contains the low-level
137		-artifact text. The tkt_mtime field is the timestamp on the ticket
138		-change artifact, expressed as a julian day number. If the ticket
	137	+artifact text. The tkt_mtime field is the time stamp on the ticket
	138	+change artifact, expressed as a Julian day number. If the ticket
139	139	change artifact contains a key/value pair where the key is "login",
140	140	then the corresponding value is stored in the login field of the
141	141	TICKETCHNG table. The same it true for "username", "mimetype", and
142	142	"icomment" fields. Any time there is a key/value pair in the ticket
143	143	change artifact and the key corresponds to the name of a field in the
		@@ -154,11 +154,11 @@
154	154	hexadecimal constant. The tkt_mtime and tkt_ctime fields hold the
155	155	times of the most recent and the oldest ticket change artifacts for
156	156	this ticket, respectively.
157	157
158	158	To reconstruct the TICKET table, the ticket change
159		-artifacts are visited in timestamp order. As each ticket change artifact is
	159	+artifacts are visited in time stamp order. As each ticket change artifact is
160	160	visited, its key/value pairs are examined. For any key/value pair in
161	161	which the key is the same as a field in the TICKET table, the value
162	162	of that pair either replaces or is appended to the previous value
163	163	of the corresponding field in the TICKET table. Whether a value is
164	164	replaced or appended is determined by markings in the ticket change
		@@ -194,6 +194,6 @@
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	196	key and appears separately, and with its on 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		-the various comments in timestamp order.
	199	+the various comments in time stamp order.
200	200

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -10,28 +10,28 @@
10
11	Each ticket change artifact contains the following information:
12
13	<ul>
14	<li>The ID of the ticket that was changed
15	<li>The timestamp for when the change occurred
16	<li>The user who made the change
17	<li>A list of key/value pairs that show what changed in the ticket
18	</ul>
19
20	To determine the current state of a particular ticket, Fossil orders
21	the change artifacts for that ticket from oldest to most recent,
22	then applies each change in timestamp order.
23
24	On each change artifact, there are one or more key/value pairs that
25	implement the change. The key corresponds to a field of the ticket
26	that is modified. The value may either replace the earlier value for
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 realtime. 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
	@@ -132,12 +132,12 @@
132
133	Each row in the TICKETCHNG table corresponds to a single ticket change
134	artifact. The tkt_id field is the integer primary key of the TICKET
135	table entry for the corresponding ticket. The tkt_rid field is the
136	integer primary key for the BLOB table entry that contains the low-level
137	artifact text. The tkt_mtime field is the timestamp on the ticket
138	change artifact, expressed as a julian day number. If the ticket
139	change artifact contains a key/value pair where the key is "login",
140	then the corresponding value is stored in the login field of the
141	TICKETCHNG table. The same it true for "username", "mimetype", and
142	"icomment" fields. Any time there is a key/value pair in the ticket
143	change artifact and the key corresponds to the name of a field in the
	@@ -154,11 +154,11 @@
154	hexadecimal constant. The tkt_mtime and tkt_ctime fields hold the
155	times of the most recent and the oldest ticket change artifacts for
156	this ticket, respectively.
157
158	To reconstruct the TICKET table, the ticket change
159	artifacts are visited in timestamp order. As each ticket change artifact is
160	visited, its key/value pairs are examined. For any key/value pair in
161	which the key is the same as a field in the TICKET table, the value
162	of that pair either replaces or is appended to the previous value
163	of the corresponding field in the TICKET table. Whether a value is
164	replaced or appended is determined by markings in the ticket change
	@@ -194,6 +194,6 @@
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 timestamp order.
200

	--- www/tickets.wiki
	+++ www/tickets.wiki
	@@ -10,28 +10,28 @@
10
11	Each ticket change artifact contains the following information:
12
13	<ul>
14	<li>The ID of the ticket that was changed
15	<li>The time stamp for when the change occurred
16	<li>The user who made the change
17	<li>A list of key/value pairs that show what changed in the ticket
18	</ul>
19
20	To determine the current state of a particular ticket, Fossil orders
21	the change artifacts for that ticket from oldest to most recent,
22	then applies each change in time stamp order.
23
24	On each change artifact, there are one or more key/value pairs that
25	implement the change. The key corresponds to a field of the ticket
26	that is modified. The value may either replace the earlier value for
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
	@@ -132,12 +132,12 @@
132
133	Each row in the TICKETCHNG table corresponds to a single ticket change
134	artifact. The tkt_id field is the integer primary key of the TICKET
135	table entry for the corresponding ticket. The tkt_rid field is the
136	integer primary key for the BLOB table entry that contains the low-level
137	artifact text. The tkt_mtime field is the time stamp on the ticket
138	change artifact, expressed as a Julian day number. If the ticket
139	change artifact contains a key/value pair where the key is "login",
140	then the corresponding value is stored in the login field of the
141	TICKETCHNG table. The same it true for "username", "mimetype", and
142	"icomment" fields. Any time there is a key/value pair in the ticket
143	change artifact and the key corresponds to the name of a field in the
	@@ -154,11 +154,11 @@
154	hexadecimal constant. The tkt_mtime and tkt_ctime fields hold the
155	times of the most recent and the oldest ticket change artifacts for
156	this ticket, respectively.
157
158	To reconstruct the TICKET table, the ticket change
159	artifacts are visited in time stamp order. As each ticket change artifact is
160	visited, its key/value pairs are examined. For any key/value pair in
161	which the key is the same as a field in the TICKET table, the value
162	of that pair either replaces or is appended to the previous value
163	of the corresponding field in the TICKET table. Whether a value is
164	replaced or appended is determined by markings in the ticket change
	@@ -194,6 +194,6 @@
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

M www/webui.wiki

+2 -2

		--- www/webui.wiki
		+++ www/webui.wiki
		@@ -52,11 +52,11 @@
52	52	repository, simply type this:
53	53
54	54	<b>fossil ui existing-repository.fossil</b>
55	55
56	56	Substitute the name of your repository, of course.
57		-The "ui" command will start a webserver running (it figures out an
	57	+The "ui" command will start a web server running (it figures out an
58	58	available TCP port to use on its own) and then automatically launches
59	59	your web browser to point at that server. If you run the "ui" command
60	60	from within an open check-out, you can omit the repository name:
61	61
62	62	<b>fossil ui</b>
		@@ -108,11 +108,11 @@
108	108
109	109	You can view summary reports of <b>branches</b> in the
110	110	check-in graph by visiting the "Branches" link on the
111	111	menu bar. From those pages you can follow hyperlinks to get additional
112	112	details. These screens allow you to easily keep track of what is going
113		-on with separate subteams within your project team.
	113	+on with separate sub-teams within your project team.
114	114
115	115	The "Files" link on the menu allows you to browse through the <b>file
116	116	hierarchy</b> of the project and to view complete changes histories on
117	117	individual files, with hyperlinks to the check-ins that made those
118	118	changes, and with diffs and annotated diffs between versions.
119	119

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -52,11 +52,11 @@
52	repository, simply type this:
53
54	<b>fossil ui existing-repository.fossil</b>
55
56	Substitute the name of your repository, of course.
57	The "ui" command will start a webserver running (it figures out an
58	available TCP port to use on its own) and then automatically launches
59	your web browser to point at that server. If you run the "ui" command
60	from within an open check-out, you can omit the repository name:
61
62	<b>fossil ui</b>
	@@ -108,11 +108,11 @@
108
109	You can view summary reports of <b>branches</b> in the
110	check-in graph by visiting the "Branches" link on the
111	menu bar. From those pages you can follow hyperlinks to get additional
112	details. These screens allow you to easily keep track of what is going
113	on with separate subteams within your project team.
114
115	The "Files" link on the menu allows you to browse through the <b>file
116	hierarchy</b> of the project and to view complete changes histories on
117	individual files, with hyperlinks to the check-ins that made those
118	changes, and with diffs and annotated diffs between versions.
119

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -52,11 +52,11 @@
52	repository, simply type this:
53
54	<b>fossil ui existing-repository.fossil</b>
55
56	Substitute the name of your repository, of course.
57	The "ui" command will start a web server running (it figures out an
58	available TCP port to use on its own) and then automatically launches
59	your web browser to point at that server. If you run the "ui" command
60	from within an open check-out, you can omit the repository name:
61
62	<b>fossil ui</b>
	@@ -108,11 +108,11 @@
108
109	You can view summary reports of <b>branches</b> in the
110	check-in graph by visiting the "Branches" link on the
111	menu bar. From those pages you can follow hyperlinks to get additional
112	details. These screens allow you to easily keep track of what is going
113	on with separate sub-teams within your project team.
114
115	The "Files" link on the menu allows you to browse through the <b>file
116	hierarchy</b> of the project and to view complete changes histories on
117	individual files, with hyperlinks to the check-ins that made those
118	changes, and with diffs and annotated diffs between versions.
119

M www/wikitheory.wiki

+1 -1

		--- www/wikitheory.wiki
		+++ www/wikitheory.wiki
		@@ -27,11 +27,11 @@
27	27	Each wiki page has its own revision history which is independent of
28	28	the sequence of check-ins (check-ins). Wiki pages can branch and merge
29	29	just like check-ins, though as of this writing (2008-07-29) there is
30	30	no mechanism in the user interface to support branching and merging.
31	31	The current implementation of the wiki shows the version of the wiki
32		-page that has the most recent timestamp.
	32	+page that has the most recent time stamp.
33	33
34	34	In other words, if two users make unrelated changes to the same wiki
35	35	page on separate repositories and those repositories are synced,
36	36	the wiki page will fork. The web interface will display whichever edit
37	37	was checked in last. The other edit can be found in the history. The
38	38

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -27,11 +27,11 @@
27	Each wiki page has its own revision history which is independent of
28	the sequence of check-ins (check-ins). Wiki pages can branch and merge
29	just like check-ins, though as of this writing (2008-07-29) there is
30	no mechanism in the user interface to support branching and merging.
31	The current implementation of the wiki shows the version of the wiki
32	page that has the most recent timestamp.
33
34	In other words, if two users make unrelated changes to the same wiki
35	page on separate repositories and those repositories are synced,
36	the wiki page will fork. The web interface will display whichever edit
37	was checked in last. The other edit can be found in the history. The
38

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -27,11 +27,11 @@
27	Each wiki page has its own revision history which is independent of
28	the sequence of check-ins (check-ins). Wiki pages can branch and merge
29	just like check-ins, though as of this writing (2008-07-29) there is
30	no mechanism in the user interface to support branching and merging.
31	The current implementation of the wiki shows the version of the wiki
32	page that has the most recent time stamp.
33
34	In other words, if two users make unrelated changes to the same wiki
35	page on separate repositories and those repositories are synced,
36	the wiki page will fork. The web interface will display whichever edit
37	was checked in last. The other edit can be found in the history. The
38

Fossil SCM

Keyboard Shortcuts