Fossil SCM

More documentation updates to highlight recent changes.

drh 2019-05-11 01:42 trunk

Commit bcea5291cee5f9f4a70d52ec9e6314c16e85c54809baeaa8214e4485acb18b96

Parent 530963e0d1ed3aa…

8 files changed +1 +12 -6 +39 -9 +3 -2 +9 +5 -1 +1 +20 -1

~ src/markdown.md ~ www/checkin_names.wiki ~ www/fossil-v-git.wiki ~ www/index.wiki ~ www/inout.wiki ~ www/selfhost.wiki ~ www/webui.wiki ~ www/wikitheory.wiki

M src/markdown.md

		--- src/markdown.md
		+++ src/markdown.md
		@@ -58,10 +58,11 @@
58	58	>
59	59	* bullet item
60	60	+ bullet item
61	61	- bullet item
62	62	1. numbered item
	63	+ 2) numbered item
63	64
64	65	> A two-level list is created by placing additional whitespace before the
65	66	> \/+/-/1.* of the secondary items.
66	67
67	68	>
68	69

	--- src/markdown.md
	+++ src/markdown.md
	@@ -58,10 +58,11 @@
58	>
59	* bullet item
60	+ bullet item
61	- bullet item
62	1. numbered item

63
64	> A two-level list is created by placing additional whitespace before the
65	> \/+/-/1.* of the secondary items.
66
67	>
68

	--- src/markdown.md
	+++ src/markdown.md
	@@ -58,10 +58,11 @@
58	>
59	* bullet item
60	+ bullet item
61	- bullet item
62	1. numbered item
63	2) numbered item
64
65	> A two-level list is created by placing additional whitespace before the
66	> \/+/-/1.* of the secondary items.
67
68	>
69

M www/checkin_names.wiki

+12 -6

		--- www/checkin_names.wiki
		+++ www/checkin_names.wiki
		@@ -142,21 +142,27 @@
142	142	<h2>Timestamps</h2>
143	143
144	144	A timestamp in one of the formats shown below means the most recent
145	145	check-in that occurs no later than the timestamp given:
146	146
147		- * <i>YYYY-MM-DD</i>
148		- * <i>YYYY-MM-DD HH:MM</i>
149		- * <i>YYYY-MM-DD HH:MM:SS</i>
150		- * <i>YYYY-MM-DD HH:MM:SS.SSS</i>
	147	+ 1. <i>YYYY-MM-DD</i>
	148	+ 2. <i>YYYY-MM-DD HH:MM</i>
	149	+ 3. <i>YYYY-MM-DD HH:MM:SS</i>
	150	+ 4. <i>YYYY-MM-DD HH:MM:SS.SSS</i>
	151	+ 5. <i>YYYYMMDD</i>
	152	+ 6. <i>YYYYMMDDHHMM</i>
	153	+ 7. <i>YYYYMMDDHHMMSS</i>
151	154
152		-The space between the day and the year can optionally be
	155	+In the second through the fourth forms,
	156	+the space between the day and the year can optionally be
153	157	replaced by an uppercase <b>T</b> and the entire timestamp can
154	158	optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
155	159	form with fractional seconds, any number of digits may follow the
156	160	decimal point, though due to precision limits only the first three
157		-digits will be significant.
	161	+digits will be significant. The final three pure-digit forms
	162	+without punctuation are only valid if the number they encode is
	163	+not also the prefix of an artifact hash.
158	164
159	165	In its default configuration, Fossil interprets and displays all dates
160	166	in Universal Coordinated Time (UTC). This tends to work the best for
161	167	distributed projects where participants are scattered around the globe.
162	168	But there is an option on the Admin/Timeline page of the web-interface to
163	169

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -142,21 +142,27 @@
142	<h2>Timestamps</h2>
143
144	A timestamp in one of the formats shown below means the most recent
145	check-in that occurs no later than the timestamp given:
146
147	* <i>YYYY-MM-DD</i>
148	* <i>YYYY-MM-DD HH:MM</i>
149	* <i>YYYY-MM-DD HH:MM:SS</i>
150	* <i>YYYY-MM-DD HH:MM:SS.SSS</i>



151
152	The space between the day and the year can optionally be

153	replaced by an uppercase <b>T</b> and the entire timestamp can
154	optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
155	form with fractional seconds, any number of digits may follow the
156	decimal point, though due to precision limits only the first three
157	digits will be significant.


158
159	In its default configuration, Fossil interprets and displays all dates
160	in Universal Coordinated Time (UTC). This tends to work the best for
161	distributed projects where participants are scattered around the globe.
162	But there is an option on the Admin/Timeline page of the web-interface to
163

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -142,21 +142,27 @@
142	<h2>Timestamps</h2>
143
144	A timestamp in one of the formats shown below means the most recent
145	check-in that occurs no later than the timestamp given:
146
147	1. <i>YYYY-MM-DD</i>
148	2. <i>YYYY-MM-DD HH:MM</i>
149	3. <i>YYYY-MM-DD HH:MM:SS</i>
150	4. <i>YYYY-MM-DD HH:MM:SS.SSS</i>
151	5. <i>YYYYMMDD</i>
152	6. <i>YYYYMMDDHHMM</i>
153	7. <i>YYYYMMDDHHMMSS</i>
154
155	In the second through the fourth forms,
156	the space between the day and the year can optionally be
157	replaced by an uppercase <b>T</b> and the entire timestamp can
158	optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
159	form with fractional seconds, any number of digits may follow the
160	decimal point, though due to precision limits only the first three
161	digits will be significant. The final three pure-digit forms
162	without punctuation are only valid if the number they encode is
163	not also the prefix of an artifact hash.
164
165	In its default configuration, Fossil interprets and displays all dates
166	in Universal Coordinated Time (UTC). This tends to work the best for
167	distributed projects where participants are scattered around the globe.
168	But there is an option on the Admin/Timeline page of the web-interface to
169

M www/fossil-v-git.wiki

+39 -9

		--- www/fossil-v-git.wiki
		+++ www/fossil-v-git.wiki
		@@ -25,16 +25,18 @@
25	25	with further description in the text that follows.
26	26
27	27	<blockquote><table border=1 cellpadding=5 align=center>
28	28	<tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr>
29	29	<tr><td>File versioning only</td>
30		- <td>Versioning, Tickets, Wiki, and Technotes</td></tr>
	30	+ <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr>
31	31	<tr><td>Ad-hoc, pile-of-files key/value database</td>
32	32	<td>Relational SQL database</td></tr>
33	33	<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
34	34	<tr><td>Designed for Linux development</td>
35	35	<td>Designed for SQLite development</td></tr>
	36	+<tr><td>Focus on individual branches</td>
	37	+ <td>Focus on the entire tree of changes</td></tr>
36	38	<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
37	39	<tr><td>One check-out per repository</td>
38	40	<td>Many check-outs per repository</td></tr>
39	41	<tr><td>Remembers what you should have done</td>
40	42	<td>Remembers what you actually did</td></tr>
		@@ -44,12 +46,12 @@
44	46	<h3>2.1 Feature Set</h3>
45	47
46	48	Git provides file versioning services only, whereas Fossil adds
47	49	integrated [./wikitheory.wiki \| wiki],
48	50	[./bugtheory.wiki \| ticketing & bug tracking],
49		-[./embeddeddoc.wiki \| embedded documentation], and
50		-[./event.wiki \| Technical notes].
	51	+[./embeddeddoc.wiki \| embedded documentation],
	52	+[./event.wiki \| Technical notes], and a [./forum.wiki \| forum].
51	53	These additional capabilities are available for Git as 3rd-party and/or
52	54	user-installed add-ons, but with Fossil they are integrated into
53	55	the design. One way to describe Fossil is that it is
54	56	"[https://github.com/ \| github]-in-a-box".
55	57
		@@ -159,11 +161,39 @@
159	161	SQLite uses cathedral-style development. 95% of the code in SQLite
160	162	comes from just three programmers, 64% from just the lead developer.
161	163	And all SQLite developers know each other well and interact daily.
162	164	Fossil is designed for this development model.
163	165
164		-<h3>2.5 Lots of little tools vs. Self-contained system</h3>
	166	+<h3>2.5 Individual Branches vs. The Entire Change History</h3>
	167	+
	168	+Both Fossil and Git store history as a directed acyclic graph (DAG)
	169	+of changes. But Git tends to focus more on individual branches of
	170	+the DAG, whereas Fossil puts more emphasis on the entire DAG.
	171	+
	172	+For example, the default "sync" behavior in Git is to only sync
	173	+a single branch, whereas with Fossil the only sync option it to
	174	+sync the entire DAG. Git commands, and Git web interfaces such as
	175	+GitHub and/or GitLab, tend to show only a single branch at
	176	+a time, whereas Fossil usually shows all parallel branches all at
	177	+once. Git has commands like "rebase" that help keep all relevant
	178	+changes on a single branch, whereas Fossil encourages a style of
	179	+many concurrent branches constantly springing into existance,
	180	+undergoing active development in parallel for a few days or weeks, then
	181	+merging back into the main line and disappearing.
	182	+
	183	+This difference in emphasis arises from the different purposes of
	184	+the two systems. Git focuses on individual branches, because that
	185	+is exactly what you want for a highly-distributed bazaar-style project
	186	+such as Linux. Linus Torvalds does not want to see every check-in
	187	+by every contributor to Linux, as such extreme visibility does not scale
	188	+well. But Fossil was written for the cathedral-style SQLite project
	189	+with just a handful of active committers. Seeing all
	190	+changes on all branches all at once helps keep the whole team
	191	+up-to-date with what everybody else is doing, resulting in a more
	192	+tightly focused and cohesive implementation.
	193	+
	194	+<h3>2.6 Lots of little tools vs. Self-contained system</h3>
165	195
166	196	Git consists of many small tools, each doing one small part of the job,
167	197	which can be recombined (by experts) to perform powerful operations.
168	198	Git has a lot of complexity and many dependencies and requires an "installer"
169	199	script or program to get it running.
		@@ -177,11 +207,11 @@
177	207	small tools that collaborate to get the job done. The designer of
178	208	Fossil says that the unix philosophy is "it just works". Both
179	209	individuals have written their DVCSes to reflect their own view
180	210	of the "unix philosophy".
181	211
182		-<h3>2.6 One vs. Many Check-outs per Repository</h3>
	212	+<h3>2.7 One vs. Many Check-outs per Repository</h3>
183	213
184	214	A "repository" in Git is a pile-of-files in the ".git" subdirectory
185	215	of a single check-out. The check-out and the repository are located
186	216	together in the filesystem.
187	217
		@@ -198,11 +228,11 @@
198	228	"[https://git-scm.com/docs/git-worktree\|worktree]" command that
199	229	allows a single repository to host multiple check-outs. However,
200	230	the interface is sufficiently difficult to use that most people
201	231	find it easier to create a separate clone for each check-out.
202	232
203		-<h3>2.7 What you should have done vs. What you actually did</h3>
	233	+<h3>2.8 What you should have done vs. What you actually did</h3>
204	234
205	235	Git puts a lot of emphasis on maintaining
206	236	a "clean" check-in history. Extraneous and experimental branches by
207	237	individual developers often never make it into the main repository. And
208	238	branches are often rebased before being pushed, to make
		@@ -219,11 +249,11 @@
219	249	is not a factor.
220	250
221	251	One commentator has mused that Git records history according to
222	252	the victors, whereas Fossil records history as it actually happened.
223	253
224		-<h3>2.8 GPL vs. BSD</h3>
	254	+<h3>2.9 GPL vs. BSD</h3>
225	255
226	256	Git is covered by the GPL license whereas Fossil is covered by
227	257	a two-clause BSD license.
228	258
229	259	Consider the difference between GPL and BSD licenses: GPL is designed
		@@ -275,14 +305,14 @@
275	305	Both Git and Fossil can easily find the ancestors of a check-in. But
276	306	only Fossil shows the descendents. (It is possible to find the
277	307	descendents of a check-in in Git using the log, but that is sufficiently
278	308	difficult that nobody ever actually does it.)
279	309
280		- * <b>Wiki, Embedded documentation, Trouble-tickets, and Tech-Notes</b>
	310	+ * <b>Wiki, Embedded documentation, Trouble-tickets, Tech-Notes, and Forum</b>
281	311
282	312	Git only provides versioning of source code. Fossil strives to provide
283		- other related configuration management services as well.
	313	+ other related project management services as well.
284	314
285	315	* <b>Named branches</b>
286	316
287	317	Branches in Fossil have persistent names that are propagated
288	318	to collaborators via [/help?cmd=push\|push] and [/help?cmd=pull\|pull].
289	319

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -25,16 +25,18 @@
25	with further description in the text that follows.
26
27	<blockquote><table border=1 cellpadding=5 align=center>
28	<tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr>
29	<tr><td>File versioning only</td>
30	<td>Versioning, Tickets, Wiki, and Technotes</td></tr>
31	<tr><td>Ad-hoc, pile-of-files key/value database</td>
32	<td>Relational SQL database</td></tr>
33	<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
34	<tr><td>Designed for Linux development</td>
35	<td>Designed for SQLite development</td></tr>


36	<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
37	<tr><td>One check-out per repository</td>
38	<td>Many check-outs per repository</td></tr>
39	<tr><td>Remembers what you should have done</td>
40	<td>Remembers what you actually did</td></tr>
	@@ -44,12 +46,12 @@
44	<h3>2.1 Feature Set</h3>
45
46	Git provides file versioning services only, whereas Fossil adds
47	integrated [./wikitheory.wiki \| wiki],
48	[./bugtheory.wiki \| ticketing & bug tracking],
49	[./embeddeddoc.wiki \| embedded documentation], and
50	[./event.wiki \| Technical notes].
51	These additional capabilities are available for Git as 3rd-party and/or
52	user-installed add-ons, but with Fossil they are integrated into
53	the design. One way to describe Fossil is that it is
54	"[https://github.com/ \| github]-in-a-box".
55
	@@ -159,11 +161,39 @@
159	SQLite uses cathedral-style development. 95% of the code in SQLite
160	comes from just three programmers, 64% from just the lead developer.
161	And all SQLite developers know each other well and interact daily.
162	Fossil is designed for this development model.
163
164	<h3>2.5 Lots of little tools vs. Self-contained system</h3>




























165
166	Git consists of many small tools, each doing one small part of the job,
167	which can be recombined (by experts) to perform powerful operations.
168	Git has a lot of complexity and many dependencies and requires an "installer"
169	script or program to get it running.
	@@ -177,11 +207,11 @@
177	small tools that collaborate to get the job done. The designer of
178	Fossil says that the unix philosophy is "it just works". Both
179	individuals have written their DVCSes to reflect their own view
180	of the "unix philosophy".
181
182	<h3>2.6 One vs. Many Check-outs per Repository</h3>
183
184	A "repository" in Git is a pile-of-files in the ".git" subdirectory
185	of a single check-out. The check-out and the repository are located
186	together in the filesystem.
187
	@@ -198,11 +228,11 @@
198	"[https://git-scm.com/docs/git-worktree\|worktree]" command that
199	allows a single repository to host multiple check-outs. However,
200	the interface is sufficiently difficult to use that most people
201	find it easier to create a separate clone for each check-out.
202
203	<h3>2.7 What you should have done vs. What you actually did</h3>
204
205	Git puts a lot of emphasis on maintaining
206	a "clean" check-in history. Extraneous and experimental branches by
207	individual developers often never make it into the main repository. And
208	branches are often rebased before being pushed, to make
	@@ -219,11 +249,11 @@
219	is not a factor.
220
221	One commentator has mused that Git records history according to
222	the victors, whereas Fossil records history as it actually happened.
223
224	<h3>2.8 GPL vs. BSD</h3>
225
226	Git is covered by the GPL license whereas Fossil is covered by
227	a two-clause BSD license.
228
229	Consider the difference between GPL and BSD licenses: GPL is designed
	@@ -275,14 +305,14 @@
275	Both Git and Fossil can easily find the ancestors of a check-in. But
276	only Fossil shows the descendents. (It is possible to find the
277	descendents of a check-in in Git using the log, but that is sufficiently
278	difficult that nobody ever actually does it.)
279
280	* <b>Wiki, Embedded documentation, Trouble-tickets, and Tech-Notes</b>
281
282	Git only provides versioning of source code. Fossil strives to provide
283	other related configuration management services as well.
284
285	* <b>Named branches</b>
286
287	Branches in Fossil have persistent names that are propagated
288	to collaborators via [/help?cmd=push\|push] and [/help?cmd=pull\|pull].
289

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -25,16 +25,18 @@
25	with further description in the text that follows.
26
27	<blockquote><table border=1 cellpadding=5 align=center>
28	<tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr>
29	<tr><td>File versioning only</td>
30	<td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr>
31	<tr><td>Ad-hoc, pile-of-files key/value database</td>
32	<td>Relational SQL database</td></tr>
33	<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr>
34	<tr><td>Designed for Linux development</td>
35	<td>Designed for SQLite development</td></tr>
36	<tr><td>Focus on individual branches</td>
37	<td>Focus on the entire tree of changes</td></tr>
38	<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr>
39	<tr><td>One check-out per repository</td>
40	<td>Many check-outs per repository</td></tr>
41	<tr><td>Remembers what you should have done</td>
42	<td>Remembers what you actually did</td></tr>
	@@ -44,12 +46,12 @@
46	<h3>2.1 Feature Set</h3>
47
48	Git provides file versioning services only, whereas Fossil adds
49	integrated [./wikitheory.wiki \| wiki],
50	[./bugtheory.wiki \| ticketing & bug tracking],
51	[./embeddeddoc.wiki \| embedded documentation],
52	[./event.wiki \| Technical notes], and a [./forum.wiki \| forum].
53	These additional capabilities are available for Git as 3rd-party and/or
54	user-installed add-ons, but with Fossil they are integrated into
55	the design. One way to describe Fossil is that it is
56	"[https://github.com/ \| github]-in-a-box".
57
	@@ -159,11 +161,39 @@
161	SQLite uses cathedral-style development. 95% of the code in SQLite
162	comes from just three programmers, 64% from just the lead developer.
163	And all SQLite developers know each other well and interact daily.
164	Fossil is designed for this development model.
165
166	<h3>2.5 Individual Branches vs. The Entire Change History</h3>
167
168	Both Fossil and Git store history as a directed acyclic graph (DAG)
169	of changes. But Git tends to focus more on individual branches of
170	the DAG, whereas Fossil puts more emphasis on the entire DAG.
171
172	For example, the default "sync" behavior in Git is to only sync
173	a single branch, whereas with Fossil the only sync option it to
174	sync the entire DAG. Git commands, and Git web interfaces such as
175	GitHub and/or GitLab, tend to show only a single branch at
176	a time, whereas Fossil usually shows all parallel branches all at
177	once. Git has commands like "rebase" that help keep all relevant
178	changes on a single branch, whereas Fossil encourages a style of
179	many concurrent branches constantly springing into existance,
180	undergoing active development in parallel for a few days or weeks, then
181	merging back into the main line and disappearing.
182
183	This difference in emphasis arises from the different purposes of
184	the two systems. Git focuses on individual branches, because that
185	is exactly what you want for a highly-distributed bazaar-style project
186	such as Linux. Linus Torvalds does not want to see every check-in
187	by every contributor to Linux, as such extreme visibility does not scale
188	well. But Fossil was written for the cathedral-style SQLite project
189	with just a handful of active committers. Seeing all
190	changes on all branches all at once helps keep the whole team
191	up-to-date with what everybody else is doing, resulting in a more
192	tightly focused and cohesive implementation.
193
194	<h3>2.6 Lots of little tools vs. Self-contained system</h3>
195
196	Git consists of many small tools, each doing one small part of the job,
197	which can be recombined (by experts) to perform powerful operations.
198	Git has a lot of complexity and many dependencies and requires an "installer"
199	script or program to get it running.
	@@ -177,11 +207,11 @@
207	small tools that collaborate to get the job done. The designer of
208	Fossil says that the unix philosophy is "it just works". Both
209	individuals have written their DVCSes to reflect their own view
210	of the "unix philosophy".
211
212	<h3>2.7 One vs. Many Check-outs per Repository</h3>
213
214	A "repository" in Git is a pile-of-files in the ".git" subdirectory
215	of a single check-out. The check-out and the repository are located
216	together in the filesystem.
217
	@@ -198,11 +228,11 @@
228	"[https://git-scm.com/docs/git-worktree\|worktree]" command that
229	allows a single repository to host multiple check-outs. However,
230	the interface is sufficiently difficult to use that most people
231	find it easier to create a separate clone for each check-out.
232
233	<h3>2.8 What you should have done vs. What you actually did</h3>
234
235	Git puts a lot of emphasis on maintaining
236	a "clean" check-in history. Extraneous and experimental branches by
237	individual developers often never make it into the main repository. And
238	branches are often rebased before being pushed, to make
	@@ -219,11 +249,11 @@
249	is not a factor.
250
251	One commentator has mused that Git records history according to
252	the victors, whereas Fossil records history as it actually happened.
253
254	<h3>2.9 GPL vs. BSD</h3>
255
256	Git is covered by the GPL license whereas Fossil is covered by
257	a two-clause BSD license.
258
259	Consider the difference between GPL and BSD licenses: GPL is designed
	@@ -275,14 +305,14 @@
305	Both Git and Fossil can easily find the ancestors of a check-in. But
306	only Fossil shows the descendents. (It is possible to find the
307	descendents of a check-in in Git using the log, but that is sufficiently
308	difficult that nobody ever actually does it.)
309
310	* <b>Wiki, Embedded documentation, Trouble-tickets, Tech-Notes, and Forum</b>
311
312	Git only provides versioning of source code. Fossil strives to provide
313	other related project management services as well.
314
315	* <b>Named branches</b>
316
317	Branches in Fossil have persistent names that are propagated
318	to collaborators via [/help?cmd=push\|push] and [/help?cmd=pull\|pull].
319

M www/index.wiki

+3 -2

		--- www/index.wiki
		+++ www/index.wiki
		@@ -62,12 +62,13 @@
62	62	[./stats.wiki \| bandwidth efficient] to the point that Fossil can be
63	63	used comfortably over dial-up or over the exceedingly slow Wifi on
64	64	airliners.
65	65
66	66	5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to
67		- set one up, Fossil supports four easy
68		- [./server.wiki \| server configurations].
	67	+ set one up, Fossil supports four easy [./server.wiki \| server configurations].
	68	+ You can also easily set up your server to automatically
	69	+ [./mirrortogithub.md \| mirror content on GitHub].
69	70
70	71	6. <b>Autosync</b> -
71	72	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
72	73	which helps to keep projects moving
73	74	forward by reducing the amount of needless
74	75

	--- www/index.wiki
	+++ www/index.wiki
	@@ -62,12 +62,13 @@
62	[./stats.wiki \| bandwidth efficient] to the point that Fossil can be
63	used comfortably over dial-up or over the exceedingly slow Wifi on
64	airliners.
65
66	5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to
67	set one up, Fossil supports four easy
68	[./server.wiki \| server configurations].

69
70	6. <b>Autosync</b> -
71	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
72	which helps to keep projects moving
73	forward by reducing the amount of needless
74

	--- www/index.wiki
	+++ www/index.wiki
	@@ -62,12 +62,13 @@
62	[./stats.wiki \| bandwidth efficient] to the point that Fossil can be
63	used comfortably over dial-up or over the exceedingly slow Wifi on
64	airliners.
65
66	5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to
67	set one up, Fossil supports four easy [./server.wiki \| server configurations].
68	You can also easily set up your server to automatically
69	[./mirrortogithub.md \| mirror content on GitHub].
70
71	6. <b>Autosync</b> -
72	Fossil supports [./concepts.wiki#workflow \| "autosync" mode]
73	which helps to keep projects moving
74	forward by reducing the amount of needless
75

M www/inout.wiki

		--- www/inout.wiki
		+++ www/inout.wiki
		@@ -48,10 +48,19 @@
48	48	since the git-fast-export file format is currently the only VCS interchange
49	49	format that Fossil will generate. However,
50	50	future versions of Fossil might add the ability to generate other
51	51	VCS interchange formats, and so for compatibility, the use of the --git
52	52	option recommended.
	53	+
	54	+<h2>Mirror A Fossil Repository In Git</h2>
	55	+
	56	+Fossil version 2.9 and later supports a simple mechanism for
	57	+doing a Git or
	58	+[./mirrortogithub.md\|GitHub mirror of a Fossil repository].
	59	+See that separate document for details. Fossil is self-hosting,
	60	+but a [https://github.com/drhsqlite/fossil-mirror\|GitHub mirror of Fossil]
	61	+is available as a proof-of-concept.
53	62
54	63	<h2>Bidirectional Synchronization</h2>
55	64	Fossil also has the ability to synchronize with a Git repository via repeated
56	65	imports and/or exports. To do this, it uses marks files to store a record of
57	66	artifacts which are known by both Git and Fossil to exist at a given point in
58	67

	--- www/inout.wiki
	+++ www/inout.wiki
	@@ -48,10 +48,19 @@
48	since the git-fast-export file format is currently the only VCS interchange
49	format that Fossil will generate. However,
50	future versions of Fossil might add the ability to generate other
51	VCS interchange formats, and so for compatibility, the use of the --git
52	option recommended.









53
54	<h2>Bidirectional Synchronization</h2>
55	Fossil also has the ability to synchronize with a Git repository via repeated
56	imports and/or exports. To do this, it uses marks files to store a record of
57	artifacts which are known by both Git and Fossil to exist at a given point in
58

	--- www/inout.wiki
	+++ www/inout.wiki
	@@ -48,10 +48,19 @@
48	since the git-fast-export file format is currently the only VCS interchange
49	format that Fossil will generate. However,
50	future versions of Fossil might add the ability to generate other
51	VCS interchange formats, and so for compatibility, the use of the --git
52	option recommended.
53
54	<h2>Mirror A Fossil Repository In Git</h2>
55
56	Fossil version 2.9 and later supports a simple mechanism for
57	doing a Git or
58	[./mirrortogithub.md\|GitHub mirror of a Fossil repository].
59	See that separate document for details. Fossil is self-hosting,
60	but a [https://github.com/drhsqlite/fossil-mirror\|GitHub mirror of Fossil]
61	is available as a proof-of-concept.
62
63	<h2>Bidirectional Synchronization</h2>
64	Fossil also has the ability to synchronize with a Git repository via repeated
65	imports and/or exports. To do this, it uses marks files to store a record of
66	artifacts which are known by both Git and Fossil to exist at a given point in
67

M www/selfhost.wiki

+5 -1

		--- www/selfhost.wiki
		+++ www/selfhost.wiki
		@@ -10,10 +10,12 @@
10	10
11	11	The canonical repository is (1). Repositories (2) and (3) automatically
12	12	stay in synchronization with (1) via a
13	13	<a href="http://en.wikipedia.org/wiki/Cron">cron job</a> that invokes
14	14	"fossil sync" at regular intervals.
	15	+Repository (2) also publishes a
	16	+[./mirrortogithub.md\|GitHub mirror of Fossil] as a demonstration.
15	17
16	18	Note that the two secondary repositories are more than just read-only mirrors.
17	19	All three servers support full read/write capabilities.
18	20	Changes (such as new tickets or wiki or check-ins) can be implemented
19	21	on any of the three servers and those changes automatically propagate to the
		@@ -67,6 +69,8 @@
67	69	</pre></blockquote>
68	70
69	71	Server (2) is a
70	72	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
71	73	and set up just like the canonical server (1) with the addition of a
72		-cron job for synchronization as in server (3).
	74	+cron job for synchronization. The same cron job also runs the
	75	+[/help?cmd=git\|fossil git export] command after each sync in order to
	76	+[./mirrortogithub.md\|mirror all changes to GitHub].
73	77

	--- www/selfhost.wiki
	+++ www/selfhost.wiki
	@@ -10,10 +10,12 @@
10
11	The canonical repository is (1). Repositories (2) and (3) automatically
12	stay in synchronization with (1) via a
13	<a href="http://en.wikipedia.org/wiki/Cron">cron job</a> that invokes
14	"fossil sync" at regular intervals.


15
16	Note that the two secondary repositories are more than just read-only mirrors.
17	All three servers support full read/write capabilities.
18	Changes (such as new tickets or wiki or check-ins) can be implemented
19	on any of the three servers and those changes automatically propagate to the
	@@ -67,6 +69,8 @@
67	</pre></blockquote>
68
69	Server (2) is a
70	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
71	and set up just like the canonical server (1) with the addition of a
72	cron job for synchronization as in server (3).


73

	--- www/selfhost.wiki
	+++ www/selfhost.wiki
	@@ -10,10 +10,12 @@
10
11	The canonical repository is (1). Repositories (2) and (3) automatically
12	stay in synchronization with (1) via a
13	<a href="http://en.wikipedia.org/wiki/Cron">cron job</a> that invokes
14	"fossil sync" at regular intervals.
15	Repository (2) also publishes a
16	[./mirrortogithub.md\|GitHub mirror of Fossil] as a demonstration.
17
18	Note that the two secondary repositories are more than just read-only mirrors.
19	All three servers support full read/write capabilities.
20	Changes (such as new tickets or wiki or check-ins) can be implemented
21	on any of the three servers and those changes automatically propagate to the
	@@ -67,6 +69,8 @@
69	</pre></blockquote>
70
71	Server (2) is a
72	<a href="http://www.linode.com/">Linode 4096</a> located in Newark, NJ
73	and set up just like the canonical server (1) with the addition of a
74	cron job for synchronization. The same cron job also runs the
75	[/help?cmd=git\|fossil git export] command after each sync in order to
76	[./mirrortogithub.md\|mirror all changes to GitHub].
77

M www/webui.wiki

		--- www/webui.wiki
		+++ www/webui.wiki
		@@ -6,10 +6,11 @@
6	6
7	7	* [./bugtheory.wiki \| Ticketing and bug tracking]
8	8	* [./wikitheory.wiki \| Wiki]
9	9	* [./embeddeddoc.wiki \| On-line documentation]
10	10	* [./event.wiki \| Technical notes]
	11	+ * [./forum.wiki \| Forum]
11	12	* Timelines
12	13	* Full text search over all of the above
13	14	* Status information
14	15	* Graphs of revision and branching history
15	16	* File and version lists and differences
16	17

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -6,10 +6,11 @@
6
7	* [./bugtheory.wiki \| Ticketing and bug tracking]
8	* [./wikitheory.wiki \| Wiki]
9	* [./embeddeddoc.wiki \| On-line documentation]
10	* [./event.wiki \| Technical notes]

11	* Timelines
12	* Full text search over all of the above
13	* Status information
14	* Graphs of revision and branching history
15	* File and version lists and differences
16

	--- www/webui.wiki
	+++ www/webui.wiki
	@@ -6,10 +6,11 @@
6
7	* [./bugtheory.wiki \| Ticketing and bug tracking]
8	* [./wikitheory.wiki \| Wiki]
9	* [./embeddeddoc.wiki \| On-line documentation]
10	* [./event.wiki \| Technical notes]
11	* [./forum.wiki \| Forum]
12	* Timelines
13	* Full text search over all of the above
14	* Status information
15	* Graphs of revision and branching history
16	* File and version lists and differences
17

M www/wikitheory.wiki

+20 -1

		--- www/wikitheory.wiki
		+++ www/wikitheory.wiki
		@@ -8,10 +8,12 @@
8	8	* Description and comments in [./bugtheory.wiki \| bug reports].
9	9	* Check-in comments.
10	10	* [./embeddeddoc.wiki \| Embedded documentation] files whose
11	11	name ends in ".wiki" or ".md" or ".markdown".
12	12	* [./event.wiki \| Technical notes].
	13	+ * [./forum.wiki \| Forum messages].
	14	+ * Auxiliary notes on check-ins and branches.
13	15
14	16	The [/wiki_rules \| formatting rules for fossil wiki]
15	17	are designed to be simple and intuitive. The idea is that wiki provides
16	18	paragraph breaks, numbered and bulleted lists, and hyperlinking for
17	19	simple documents together with a safe subset of HTML for more complex
		@@ -56,11 +58,28 @@
56	58	use the exact same markup. Some projects may choose to
57	59	use both forms of documentation at the same time. Because the same
58	60	format is used, it is trivial to move a file from wiki to embedded documentation
59	61	or back again as the project evolves.
60	62
61		-<h2>Bug-reports and check-in comments</h2>
	63	+<h2>Bug-reports and check-in comments and Forum messages</h2>
62	64
63	65	The comments on check-ins and the text in the descriptions of bug reports
64	66	both use wiki formatting. Exactly the same set of formatting rules apply.
65	67	There is never a need to learn one formatting language for documentation
66	68	and a different markup for bugs or for check-in comments.
	69	+
	70	+<h2>Auxiliary notes attached to check-ins or branches</h2>
	71	+
	72	+Stand-alone wiki pages with special names "branch/<i>BRANCHNAME</i>"
	73	+or "checkin/<i>HASH</i>" are associated with the corresponding
	74	+branch or check-in. The wiki text appears in an "About" section of
	75	+timelines and info screens. Examples:
	76	+
	77	+ * [/timeline?r=graph-test-branch] shows the text of the
	78	+ [/wiki?name=branch/graph-test-branch\|branch/graph-test-branch]
	79	+ wiki page at the top of the timeline
	80	+ * [/info/19c60b7fc9e2] shows the text of the
	81	+ [/wiki?name=checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6\|checkin/19c60b7fc9e2...]
	82	+ wiki page in the "About" section.
	83	+
	84	+This special wiki pages are very useful for recording historical
	85	+notes.
67	86

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -8,10 +8,12 @@
8	* Description and comments in [./bugtheory.wiki \| bug reports].
9	* Check-in comments.
10	* [./embeddeddoc.wiki \| Embedded documentation] files whose
11	name ends in ".wiki" or ".md" or ".markdown".
12	* [./event.wiki \| Technical notes].


13
14	The [/wiki_rules \| formatting rules for fossil wiki]
15	are designed to be simple and intuitive. The idea is that wiki provides
16	paragraph breaks, numbered and bulleted lists, and hyperlinking for
17	simple documents together with a safe subset of HTML for more complex
	@@ -56,11 +58,28 @@
56	use the exact same markup. Some projects may choose to
57	use both forms of documentation at the same time. Because the same
58	format is used, it is trivial to move a file from wiki to embedded documentation
59	or back again as the project evolves.
60
61	<h2>Bug-reports and check-in comments</h2>
62
63	The comments on check-ins and the text in the descriptions of bug reports
64	both use wiki formatting. Exactly the same set of formatting rules apply.
65	There is never a need to learn one formatting language for documentation
66	and a different markup for bugs or for check-in comments.

















67

	--- www/wikitheory.wiki
	+++ www/wikitheory.wiki
	@@ -8,10 +8,12 @@
8	* Description and comments in [./bugtheory.wiki \| bug reports].
9	* Check-in comments.
10	* [./embeddeddoc.wiki \| Embedded documentation] files whose
11	name ends in ".wiki" or ".md" or ".markdown".
12	* [./event.wiki \| Technical notes].
13	* [./forum.wiki \| Forum messages].
14	* Auxiliary notes on check-ins and branches.
15
16	The [/wiki_rules \| formatting rules for fossil wiki]
17	are designed to be simple and intuitive. The idea is that wiki provides
18	paragraph breaks, numbered and bulleted lists, and hyperlinking for
19	simple documents together with a safe subset of HTML for more complex
	@@ -56,11 +58,28 @@
58	use the exact same markup. Some projects may choose to
59	use both forms of documentation at the same time. Because the same
60	format is used, it is trivial to move a file from wiki to embedded documentation
61	or back again as the project evolves.
62
63	<h2>Bug-reports and check-in comments and Forum messages</h2>
64
65	The comments on check-ins and the text in the descriptions of bug reports
66	both use wiki formatting. Exactly the same set of formatting rules apply.
67	There is never a need to learn one formatting language for documentation
68	and a different markup for bugs or for check-in comments.
69
70	<h2>Auxiliary notes attached to check-ins or branches</h2>
71
72	Stand-alone wiki pages with special names "branch/<i>BRANCHNAME</i>"
73	or "checkin/<i>HASH</i>" are associated with the corresponding
74	branch or check-in. The wiki text appears in an "About" section of
75	timelines and info screens. Examples:
76
77	* [/timeline?r=graph-test-branch] shows the text of the
78	[/wiki?name=branch/graph-test-branch\|branch/graph-test-branch]
79	wiki page at the top of the timeline
80	* [/info/19c60b7fc9e2] shows the text of the
81	[/wiki?name=checkin/19c60b7fc9e2400e56a6f938bbad0e34ca746ca2eabdecac10945539f1f5e8c6\|checkin/19c60b7fc9e2...]
82	wiki page in the "About" section.
83
84	This special wiki pages are very useful for recording historical
85	notes.
86

Fossil SCM

Keyboard Shortcuts