Fossil SCM

Recast the blockchain.md doc as "Is Fossil a Blockchain?" (answer: mostly no) and updated all references to it to either remove the term, use "repository" instead where that's sufficiently clear, or to say either "Merkle tree" or "hash tree" instead where we need to distinguish the hash tree itself from the rest of the repo DB file's contents. This depends on the prior CAP theorem doc, since part of the argument for Fossil not being a blockchain gets us down into those weeds.

wyoung 2020-10-05 18:15 trunk

Commit 855578b61091c49d24a891b8b2db4f92705842794e3e3292a1b0700efac2a21c

Parent 3ddd56d0b03d83c…

11 files changed +188 -20 +5 -5 +1 -1 +1 -1 +1 -1 +1 -1 +3 -3 +5 -5 +1 -1 +2 -2 +2 -2

~ www/blockchain.md ~ www/caps/admin-v-setup.md ~ www/caps/impl.md ~ www/caps/ref.html ~ www/checkin_names.wiki ~ www/fileedit-page.md ~ www/fossil-v-git.wiki ~ www/mirrorlimitations.md ~ www/mkindex.tcl ~ www/permutedindex.html ~ www/shunning.wiki

M www/blockchain.md

+188 -20

		--- www/blockchain.md
		+++ www/blockchain.md
		@@ -1,32 +1,200 @@
1		-# Fossil As Blockchain
	1	+# Is Fossil A Blockchain?
	2	+
	3	+The Fossil version control system shares a lot of similarities with
	4	+blockchain based technologies, but it also differs from the more common
	5	+sorts of blockchains. This document will discuss the term’s
	6	+applicability, so you can decide whether applying the term to Fossil
	7	+makes sense to you.
	8	+
2	9
3		-Fossil is a version control system built around blockchain.
	10	+## The Dictionary Argument
4	11
5		-Wikipedia defines "blockchain" as
	12	+[Wikipedia defines "blockchain"][bcwp] in part as
6	13
7	14	>
8		- "a growing list of records, called blocks, which are linked using
	15	+ "…a growing list of records, called blocks, which are linked using
9	16	cryptography. Each block contains a cryptographic hash of the previous
10		- block, a timestamp, and transaction data..." [(1)][]
	17	+ block, a timestamp, and transaction data…"
11	18
12	19
13		-By that definition, Fossil is clearly an implementation of blockchain.
	20	+By that partial definition, Fossil is indeed a blockchain.
14	21	The blocks are ["manifests" artifacts](./fileformat.wiki#manifest).
15	22	Each manifest has a SHA1 or SHA3 hash of its parent or parents,
16	23	a timestamp, and other transactional data. The repository grows by
17	24	adding new manifests onto the list.
18	25
19		-Some people have come to associate blockchain with cryptocurrency, however,
20		-and since Fossil has nothing to do with cryptocurrency, the claim that
21		-Fossil is built around blockchain is met with skepticism. The key thing
22		-to note here is that cryptocurrency implementations like BitCoin are
23		-built around blockchain, but they are not synonymous with blockchain.
24		-Blockchain is a much broader concept. Blockchain is a mechanism for
25		-constructing a distributed ledger of transactions.
26		-Yes, you can use a distributed
27		-ledger to implement a cryptocurrency, but you can also use a distributed
28		-ledger to implement a version control system, and probably many other kinds
29		-of applications as well. Blockchain is a much broader idea than
30		-cryptocurrency.
31		-
32		-[(1)]: https://en.wikipedia.org/wiki/Blockchain
	26	+Nevertheless, there are many reasons to regard Fossil as not a
	27	+blockchain.
	28	+
	29	+[bcwp]: https://en.wikipedia.org/wiki/Blockchain
	30	+
	31	+
	32	+
	33	+## Cryptocurrency
	34	+
	35	+Because blockchain technology was first popularized as Bitcoin, many
	36	+people associate the term with cryptocurrency. Since Fossil has nothing
	37	+to do with cryptocurrency, someone using the term “blockchain” to refer
	38	+to Fossil is likely to fail to communicate their ideas clearly.
	39	+
	40	+Cryptocurrency also has unfortunate implications in certain circles, its
	41	+anonymity and lack of regulation leading it to become associated with
	42	+bad actors. Even if we ignore all of the other criticisms in this
	43	+document, our unwillingness to be so associated may be enough of a
	44	+reason for us to avoid using it.
	45	+
	46	+
	47	+
	48	+## Marketing Capture
	49	+
	50	+The fact that blockchain technology has become a hot marketing buzzword
	51	+should affect your choice of whether to use the term “blockchain” to
	52	+refer to Fossil. Your choice may well vary based on the audience:
	53	+
	54	+* Executive Board: At the quarterly all-hands meeting, the big
	55	+ boss — who just read about blockchains in [PHB] Weekly — asks if
	56	+ your development organization “has a blockchain.” With Fossil and a
	57	+ suitably narrow definition of the term “blockchain” in mind, you
	58	+ could answer “Yes,” except that you know they’re then going to go to
	59	+ the shareholders and happily report, “Our development organization
	60	+ has been using blockchain technology for years!” You may decide that
	61	+ this makes you responsible for a public deception, putting the
	62	+ organization at risk of an SEC investigation for making false
	63	+ statements.
	64	+
	65	+ Yet if you answer “No,” knowing you’ll be punished for not being on
	66	+ top of the latest whiz-bang as the technologically gormless PHB sees
	67	+ it, are you advancing the organization’s actual interests? If the
	68	+ organization has no actual need for a proper blockchain tech base,
	69	+ isn’t it better to just say “Yes” and point at Fossil so you can get
	70	+ back to useful work?
	71	+
	72	+* Middle Management: Your project leader asks the same question,
	73	+ so you point them at this document, which tells them the truth:
	74	+ kinda yes, but mostly no.
	75	+
	76	+* Developer Lunch: A peer asks if you’re doing anything with
	77	+ blockchains. Knowing the contents of this document, you decide you
	78	+ can’t justify using that term to refer to Fossil at a deep technical
	79	+ level, so you admit that you are not.
	80	+
	81	+[PHB]: https://en.wikipedia.org/wiki/Pointy-haired_Boss
	82	+
	83	+
	84	+## Distributed Ledgers
	85	+
	86	+Cryptocurrencies are a type of [distributed ledger technology][dlt]. Is
	87	+Fossil a distributed ledger?
	88	+
	89	+A key tenet of DLT is that records be unmodifiable after they’re
	90	+committed to the ledger, which matches quite well with Fossil’s design
	91	+and everyday use cases.
	92	+
	93	+Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean
	94	+Fossil cannot be a distributed ledger?
	95	+
	96	+What if you removed those features from Fossil, creating an append-only
	97	+variant? Is it a DLT then? Arguably still not, because [today’s Fossil
	98	+is an AP-mode system][fapm] in the [CAP theorem][cap] sense, which means
	99	+there can be no guaranteed consensus on the content of the ledger at any
	100	+given time. If you had an AP-mode accounts receivable system, it could
	101	+have different bottom-line totals at different sites, because you’ve
	102	+cast away “C” to get AP-mode operation.
	103	+
	104	+What are the prospects for CA-mode or CP-mode Fossil? [We don’t want
	105	+CA-mode Fossil, but CP-mode could be useful.][fapm] Until the latter
	106	+exists, this author believes Fossil is not a distributed ledger in a
	107	+technologically defensible sense. If you restrict your definition’s
	108	+scope to cover only the most common uses of “blockchain,” which are all
	109	+DLTs, that means Fossil is not a blockchain.
	110	+
	111	+[fapm]: ./cap-theorem.md
	112	+[cap]: https://en.wikipedia.org/wiki/CAP_theorem
	113	+[dlt]: https://en.wikipedia.org/wiki/Distributed_ledger
	114	+[DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control
	115	+[purge]: /help?cmd=purge
	116	+[shun]: ./shunning.wiki
	117	+
	118	+
	119	+## Distributed Partial Consensus
	120	+
	121	+If we can’t get DLT, can we at least get some kind of distributed
	122	+consensus at the level of individual Fossil’s commits?
	123	+
	124	+Many blockchain based technologies have this property: given some
	125	+element of the blockchain, you can make certain proofs that it either is
	126	+a legitimate part of the whole blockchain, or it is not.
	127	+
	128	+Unfortunately, this author doesn’t see a way to do that with Fossil.
	129	+Given only one “block” in Fossil’s putative “blockchain” — a commit, in
	130	+Fossil terminology — all you can prove is whether it is internally
	131	+consistent, not corrupt. That then points you at the parent(s) of that
	132	+commit, which you can repeat the exercise on, back to the root of the
	133	+DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks]
	134	+does.
	135	+
	136	+If cryptocurrencies worked this way, you wouldn’t be able to prove that
	137	+a given cryptocoin was legitimate without repeating the proof-of-work
	138	+calculations for the entire cryptocurrency scheme!
	139	+
	140	+What would it even mean to prove that a given Fossil commit “belongs”
	141	+to the repository you’ve extracted it from? For a software project,
	142	+isn’t that tantamount to automatic code review, where the server would
	143	+be able to reliably accept or reject a commit based solely on its
	144	+content? That sounds nice, but this author believes we’ll need to invent
	145	+[AGI] first.
	146	+
	147	+A better method to provide distributed consensus for Fossil would be to
	148	+rely on the natural intelligence of its users: that is, distributed
	149	+commit signing, so that a commit is accepted into the blockchain only
	150	+once some number of users countersign it. This amounts to a code review
	151	+feature, which Fossil doesn’t currently have.
	152	+
	153	+Solving that problem basically requires solving the [PKI] problem first,
	154	+since you can’t verify the proofs of these signatures if you can’t first
	155	+prove that the provided signatures belong to people you trust. This is a
	156	+notoriously hard problem in its own right.
	157	+
	158	+A future version of Fossil could instead provide consensus [in the CAP
	159	+sense][fapm]. For instance, you could say that if a quorum of servers
	160	+all have a given commit, it “belongs.” Fossil’s strong hashing tech
	161	+would mean that querying whether a given commit is part of the
	162	+“blockchain” would be as simple as going down the list of servers and
	163	+sending it an HTTP GET `/info` query for the artifact ID, returning
	164	+“Yes” once you get enough HTTP 200 status codes back. All of this is
	165	+hypothetical, because Fossil doesn’t do this today.
	166	+
	167	+Even with all of the above solved, you’d still have another problem:
	168	+Fossil currently has no way to do partial cloning of a repository. The
	169	+only way to remotely extract individual “blocks” — commits — from a
	170	+remote repository is to make `/artifact`, `/info`, or `/raw` queries to
	171	+its HTTP interface. For Fossil to be a true blockchain, we’d want a way
	172	+to send around as little as one commit which could be individually
	173	+verified as being “part of the blockchain” using only intra-block
	174	+consistency checks.
	175	+
	176	+[AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence
	177	+[PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure
	178	+[rcks]: https://fossil-scm.org/home/help?cmd=repo-cksum
	179	+
	180	+
	181	+# Conclusion
	182	+
	183	+This author believes it is technologically indefensible to call Fossil a
	184	+“blockchain” in any sense likely to be understood by a majority of those
	185	+you’re communicating with.
	186	+
	187	+Within a certain narrow scope, you can defend this usage, but if you do
	188	+that, you’ve failed any goal that requires clear communication: it
	189	+doesn’t work to use a term in a nonstandard way just because you can
	190	+defend it. The people you’re communicating your ideas to must have the
	191	+same concept of the terms you use.
	192	+
	193	+What term should you use instead? A blockchain is a type of [Merkle
	194	+tree][mt], also called a hash tree, and Fossil is certainly that.
	195	+
	196	+Fossil and “blockchain” are technological peers. They are related
	197	+technologies, but neither is a subset or instance of the other in any
	198	+useful sense.
	199	+
	200	+[mt]: https://en.wikipedia.org/wiki/Merkle_tree
33	201

	--- www/blockchain.md
	+++ www/blockchain.md
	@@ -1,32 +1,200 @@
1	# Fossil As Blockchain







2
3	Fossil is a version control system built around blockchain.
4
5	Wikipedia defines "blockchain" as
6
7	>
8	"a growing list of records, called blocks, which are linked using
9	cryptography. Each block contains a cryptographic hash of the previous
10	block, a timestamp, and transaction data..." [(1)][]
11
12
13	By that definition, Fossil is clearly an implementation of blockchain.
14	The blocks are ["manifests" artifacts](./fileformat.wiki#manifest).
15	Each manifest has a SHA1 or SHA3 hash of its parent or parents,
16	a timestamp, and other transactional data. The repository grows by
17	adding new manifests onto the list.
18
19	Some people have come to associate blockchain with cryptocurrency, however,
20	and since Fossil has nothing to do with cryptocurrency, the claim that
21	Fossil is built around blockchain is met with skepticism. The key thing
22	to note here is that cryptocurrency implementations like BitCoin are
23	built around blockchain, but they are not synonymous with blockchain.
24	Blockchain is a much broader concept. Blockchain is a mechanism for
25	constructing a distributed ledger of transactions.
26	Yes, you can use a distributed
27	ledger to implement a cryptocurrency, but you can also use a distributed
28	ledger to implement a version control system, and probably many other kinds
29	of applications as well. Blockchain is a much broader idea than
30	cryptocurrency.
31
32	[(1)]: https://en.wikipedia.org/wiki/Blockchain

































































































































































33

	--- www/blockchain.md
	+++ www/blockchain.md
	@@ -1,32 +1,200 @@
1	# Is Fossil A Blockchain?
2
3	The Fossil version control system shares a lot of similarities with
4	blockchain based technologies, but it also differs from the more common
5	sorts of blockchains. This document will discuss the term’s
6	applicability, so you can decide whether applying the term to Fossil
7	makes sense to you.
8
9
10	## The Dictionary Argument
11
12	[Wikipedia defines "blockchain"][bcwp] in part as
13
14	>
15	"…a growing list of records, called blocks, which are linked using
16	cryptography. Each block contains a cryptographic hash of the previous
17	block, a timestamp, and transaction data…"
18
19
20	By that partial definition, Fossil is indeed a blockchain.
21	The blocks are ["manifests" artifacts](./fileformat.wiki#manifest).
22	Each manifest has a SHA1 or SHA3 hash of its parent or parents,
23	a timestamp, and other transactional data. The repository grows by
24	adding new manifests onto the list.
25
26	Nevertheless, there are many reasons to regard Fossil as not a
27	blockchain.
28
29	[bcwp]: https://en.wikipedia.org/wiki/Blockchain
30
31
32
33	## Cryptocurrency
34
35	Because blockchain technology was first popularized as Bitcoin, many
36	people associate the term with cryptocurrency. Since Fossil has nothing
37	to do with cryptocurrency, someone using the term “blockchain” to refer
38	to Fossil is likely to fail to communicate their ideas clearly.
39
40	Cryptocurrency also has unfortunate implications in certain circles, its
41	anonymity and lack of regulation leading it to become associated with
42	bad actors. Even if we ignore all of the other criticisms in this
43	document, our unwillingness to be so associated may be enough of a
44	reason for us to avoid using it.
45
46
47
48	## Marketing Capture
49
50	The fact that blockchain technology has become a hot marketing buzzword
51	should affect your choice of whether to use the term “blockchain” to
52	refer to Fossil. Your choice may well vary based on the audience:
53
54	* Executive Board: At the quarterly all-hands meeting, the big
55	boss — who just read about blockchains in [PHB] Weekly — asks if
56	your development organization “has a blockchain.” With Fossil and a
57	suitably narrow definition of the term “blockchain” in mind, you
58	could answer “Yes,” except that you know they’re then going to go to
59	the shareholders and happily report, “Our development organization
60	has been using blockchain technology for years!” You may decide that
61	this makes you responsible for a public deception, putting the
62	organization at risk of an SEC investigation for making false
63	statements.
64
65	Yet if you answer “No,” knowing you’ll be punished for not being on
66	top of the latest whiz-bang as the technologically gormless PHB sees
67	it, are you advancing the organization’s actual interests? If the
68	organization has no actual need for a proper blockchain tech base,
69	isn’t it better to just say “Yes” and point at Fossil so you can get
70	back to useful work?
71
72	* Middle Management: Your project leader asks the same question,
73	so you point them at this document, which tells them the truth:
74	kinda yes, but mostly no.
75
76	* Developer Lunch: A peer asks if you’re doing anything with
77	blockchains. Knowing the contents of this document, you decide you
78	can’t justify using that term to refer to Fossil at a deep technical
79	level, so you admit that you are not.
80
81	[PHB]: https://en.wikipedia.org/wiki/Pointy-haired_Boss
82
83
84	## Distributed Ledgers
85
86	Cryptocurrencies are a type of [distributed ledger technology][dlt]. Is
87	Fossil a distributed ledger?
88
89	A key tenet of DLT is that records be unmodifiable after they’re
90	committed to the ledger, which matches quite well with Fossil’s design
91	and everyday use cases.
92
93	Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean
94	Fossil cannot be a distributed ledger?
95
96	What if you removed those features from Fossil, creating an append-only
97	variant? Is it a DLT then? Arguably still not, because [today’s Fossil
98	is an AP-mode system][fapm] in the [CAP theorem][cap] sense, which means
99	there can be no guaranteed consensus on the content of the ledger at any
100	given time. If you had an AP-mode accounts receivable system, it could
101	have different bottom-line totals at different sites, because you’ve
102	cast away “C” to get AP-mode operation.
103
104	What are the prospects for CA-mode or CP-mode Fossil? [We don’t want
105	CA-mode Fossil, but CP-mode could be useful.][fapm] Until the latter
106	exists, this author believes Fossil is not a distributed ledger in a
107	technologically defensible sense. If you restrict your definition’s
108	scope to cover only the most common uses of “blockchain,” which are all
109	DLTs, that means Fossil is not a blockchain.
110
111	[fapm]: ./cap-theorem.md
112	[cap]: https://en.wikipedia.org/wiki/CAP_theorem
113	[dlt]: https://en.wikipedia.org/wiki/Distributed_ledger
114	[DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control
115	[purge]: /help?cmd=purge
116	[shun]: ./shunning.wiki
117
118
119	## Distributed Partial Consensus
120
121	If we can’t get DLT, can we at least get some kind of distributed
122	consensus at the level of individual Fossil’s commits?
123
124	Many blockchain based technologies have this property: given some
125	element of the blockchain, you can make certain proofs that it either is
126	a legitimate part of the whole blockchain, or it is not.
127
128	Unfortunately, this author doesn’t see a way to do that with Fossil.
129	Given only one “block” in Fossil’s putative “blockchain” — a commit, in
130	Fossil terminology — all you can prove is whether it is internally
131	consistent, not corrupt. That then points you at the parent(s) of that
132	commit, which you can repeat the exercise on, back to the root of the
133	DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks]
134	does.
135
136	If cryptocurrencies worked this way, you wouldn’t be able to prove that
137	a given cryptocoin was legitimate without repeating the proof-of-work
138	calculations for the entire cryptocurrency scheme!
139
140	What would it even mean to prove that a given Fossil commit “belongs”
141	to the repository you’ve extracted it from? For a software project,
142	isn’t that tantamount to automatic code review, where the server would
143	be able to reliably accept or reject a commit based solely on its
144	content? That sounds nice, but this author believes we’ll need to invent
145	[AGI] first.
146
147	A better method to provide distributed consensus for Fossil would be to
148	rely on the natural intelligence of its users: that is, distributed
149	commit signing, so that a commit is accepted into the blockchain only
150	once some number of users countersign it. This amounts to a code review
151	feature, which Fossil doesn’t currently have.
152
153	Solving that problem basically requires solving the [PKI] problem first,
154	since you can’t verify the proofs of these signatures if you can’t first
155	prove that the provided signatures belong to people you trust. This is a
156	notoriously hard problem in its own right.
157
158	A future version of Fossil could instead provide consensus [in the CAP
159	sense][fapm]. For instance, you could say that if a quorum of servers
160	all have a given commit, it “belongs.” Fossil’s strong hashing tech
161	would mean that querying whether a given commit is part of the
162	“blockchain” would be as simple as going down the list of servers and
163	sending it an HTTP GET `/info` query for the artifact ID, returning
164	“Yes” once you get enough HTTP 200 status codes back. All of this is
165	hypothetical, because Fossil doesn’t do this today.
166
167	Even with all of the above solved, you’d still have another problem:
168	Fossil currently has no way to do partial cloning of a repository. The
169	only way to remotely extract individual “blocks” — commits — from a
170	remote repository is to make `/artifact`, `/info`, or `/raw` queries to
171	its HTTP interface. For Fossil to be a true blockchain, we’d want a way
172	to send around as little as one commit which could be individually
173	verified as being “part of the blockchain” using only intra-block
174	consistency checks.
175
176	[AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence
177	[PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure
178	[rcks]: https://fossil-scm.org/home/help?cmd=repo-cksum
179
180
181	# Conclusion
182
183	This author believes it is technologically indefensible to call Fossil a
184	“blockchain” in any sense likely to be understood by a majority of those
185	you’re communicating with.
186
187	Within a certain narrow scope, you can defend this usage, but if you do
188	that, you’ve failed any goal that requires clear communication: it
189	doesn’t work to use a term in a nonstandard way just because you can
190	defend it. The people you’re communicating your ideas to must have the
191	same concept of the terms you use.
192
193	What term should you use instead? A blockchain is a type of [Merkle
194	tree][mt], also called a hash tree, and Fossil is certainly that.
195
196	Fossil and “blockchain” are technological peers. They are related
197	technologies, but neither is a subset or instance of the other in any
198	useful sense.
199
200	[mt]: https://en.wikipedia.org/wiki/Merkle_tree
201

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

+5 -5

		--- www/caps/admin-v-setup.md
		+++ www/caps/admin-v-setup.md
		@@ -46,12 +46,12 @@
46	46	choices.
47	47
48	48	You can also look at the role of Admin from the other direction, up
49	49	through the [user power hierarchy][ucap] rather than down from Setup. An
50	50	Admin user is usually a “super-developer” role, given full control over
51		-the repository’s managed content: versioned artifacts in [the block
52		-chain][bc], [unversioned content][uv], forum posts, wiki articles,
	51	+the repository’s managed content: versioned artifacts in [the hash tree][bc],
	52	+[unversioned content][uv], forum posts, wiki articles,
53	53	tickets, etc.
54	54
55	55	We’ll explore these distinctions in the rest of this document.
56	56
57	57	[bc]: ../blockchain.md
		@@ -158,17 +158,17 @@
158	158	system][shun] is to clean up after a spammer, and that's
159	159	exactly the sort of administrivia we wish to delegate to Admin users.
160	160
161	161	Coupled with the Rebuild button on the same page, an Admin user has
162	162	the power to delete the repository's entire
163		- [blockchain][bc]! This makes this feature a pretty good
	163	+ [hash tree][bc]! This makes this feature a pretty good
164	164	razor in deciding whether to grant someone Admin capability: do you
165	165	trust that user to shun Fossil artifacts responsibly?
166	166
167	167	Realize that shunning is cooperative in Fossil. As long as there are
168	168	surviving repository clones, an Admin-only user who deletes the
169		- whole blockchain has merely caused a nuisance. An Admin-only user
	169	+ whole hash tree has merely caused a nuisance. An Admin-only user
170	170	cannot permanently destroy the repository unless the Setup user has
171	171	been so silly as to have no up-to-date clones.
172	172
173	173	* Moderation: According to the power hierarchy laid out at the top
174	174	of this article, Admins are greater than Moderators, so control over
		@@ -344,11 +344,11 @@
344	344	access on the host system, we almost certainly don't want to
345	345	allow them to change such settings.</p>
346	346
347	347	* SQL: The Admin → SQL feature allows the Setup user to enter raw
348	348	SQL queries against the Fossil repository via Fossil UI. This not
349		- only allows arbitrary ability to modify the repository blockchain
	349	+ only allows arbitrary ability to modify the repository hash tree
350	350	and its backing data tables, it can probably also be used to damage
351	351	the host such as via `PRAGMA temp_store = FILE`.
352	352
353	353	* Tickets: This section allows input of aribtrary TH1 code that
354	354	runs on the server, affecting the way the Fossil ticketing system
355	355

	--- www/caps/admin-v-setup.md
	+++ www/caps/admin-v-setup.md
	@@ -46,12 +46,12 @@
46	choices.
47
48	You can also look at the role of Admin from the other direction, up
49	through the [user power hierarchy][ucap] rather than down from Setup. An
50	Admin user is usually a “super-developer” role, given full control over
51	the repository’s managed content: versioned artifacts in [the block
52	chain][bc], [unversioned content][uv], forum posts, wiki articles,
53	tickets, etc.
54
55	We’ll explore these distinctions in the rest of this document.
56
57	[bc]: ../blockchain.md
	@@ -158,17 +158,17 @@
158	system][shun] is to clean up after a spammer, and that's
159	exactly the sort of administrivia we wish to delegate to Admin users.
160
161	Coupled with the Rebuild button on the same page, an Admin user has
162	the power to delete the repository's entire
163	[blockchain][bc]! This makes this feature a pretty good
164	razor in deciding whether to grant someone Admin capability: do you
165	trust that user to shun Fossil artifacts responsibly?
166
167	Realize that shunning is cooperative in Fossil. As long as there are
168	surviving repository clones, an Admin-only user who deletes the
169	whole blockchain has merely caused a nuisance. An Admin-only user
170	cannot permanently destroy the repository unless the Setup user has
171	been so silly as to have no up-to-date clones.
172
173	* Moderation: According to the power hierarchy laid out at the top
174	of this article, Admins are greater than Moderators, so control over
	@@ -344,11 +344,11 @@
344	access on the host system, we almost certainly don't want to
345	allow them to change such settings.</p>
346
347	* SQL: The Admin → SQL feature allows the Setup user to enter raw
348	SQL queries against the Fossil repository via Fossil UI. This not
349	only allows arbitrary ability to modify the repository blockchain
350	and its backing data tables, it can probably also be used to damage
351	the host such as via `PRAGMA temp_store = FILE`.
352
353	* Tickets: This section allows input of aribtrary TH1 code that
354	runs on the server, affecting the way the Fossil ticketing system
355

	--- www/caps/admin-v-setup.md
	+++ www/caps/admin-v-setup.md
	@@ -46,12 +46,12 @@
46	choices.
47
48	You can also look at the role of Admin from the other direction, up
49	through the [user power hierarchy][ucap] rather than down from Setup. An
50	Admin user is usually a “super-developer” role, given full control over
51	the repository’s managed content: versioned artifacts in [the hash tree][bc],
52	[unversioned content][uv], forum posts, wiki articles,
53	tickets, etc.
54
55	We’ll explore these distinctions in the rest of this document.
56
57	[bc]: ../blockchain.md
	@@ -158,17 +158,17 @@
158	system][shun] is to clean up after a spammer, and that's
159	exactly the sort of administrivia we wish to delegate to Admin users.
160
161	Coupled with the Rebuild button on the same page, an Admin user has
162	the power to delete the repository's entire
163	[hash tree][bc]! This makes this feature a pretty good
164	razor in deciding whether to grant someone Admin capability: do you
165	trust that user to shun Fossil artifacts responsibly?
166
167	Realize that shunning is cooperative in Fossil. As long as there are
168	surviving repository clones, an Admin-only user who deletes the
169	whole hash tree has merely caused a nuisance. An Admin-only user
170	cannot permanently destroy the repository unless the Setup user has
171	been so silly as to have no up-to-date clones.
172
173	* Moderation: According to the power hierarchy laid out at the top
174	of this article, Admins are greater than Moderators, so control over
	@@ -344,11 +344,11 @@
344	access on the host system, we almost certainly don't want to
345	allow them to change such settings.</p>
346
347	* SQL: The Admin → SQL feature allows the Setup user to enter raw
348	SQL queries against the Fossil repository via Fossil UI. This not
349	only allows arbitrary ability to modify the repository hash tree
350	and its backing data tables, it can probably also be used to damage
351	the host such as via `PRAGMA temp_store = FILE`.
352
353	* Tickets: This section allows input of aribtrary TH1 code that
354	runs on the server, affecting the way the Fossil ticketing system
355

M www/caps/impl.md

+1 -1

		--- www/caps/impl.md
		+++ www/caps/impl.md
		@@ -62,11 +62,11 @@
62	62	3. You can purposely overwrite good timestamps with bad ones and push
63	63	those changes up to the remote with no interference, even though
64	64	Fossil tries to make that a Setup-only operation.
65	65
66	66	All of this falls out of two of Fossil’s design choices: sync is
67		-all-or-nothing, and [the Fossil block chain][bc] is immutable. Fossil
	67	+all-or-nothing, and [the Fossil hash tree][bc] is immutable. Fossil
68	68	would have to violate one or both of these principles to filter such
69	69	problems out of incoming syncs.
70	70
71	71	We have considered auto-[shunning][shun] “bad” content on sync, but this
72	72	is [difficult][asd] due to [the design of the sync protocol][dsp]. This
73	73

	--- www/caps/impl.md
	+++ www/caps/impl.md
	@@ -62,11 +62,11 @@
62	3. You can purposely overwrite good timestamps with bad ones and push
63	those changes up to the remote with no interference, even though
64	Fossil tries to make that a Setup-only operation.
65
66	All of this falls out of two of Fossil’s design choices: sync is
67	all-or-nothing, and [the Fossil block chain][bc] is immutable. Fossil
68	would have to violate one or both of these principles to filter such
69	problems out of incoming syncs.
70
71	We have considered auto-[shunning][shun] “bad” content on sync, but this
72	is [difficult][asd] due to [the design of the sync protocol][dsp]. This
73

	--- www/caps/impl.md
	+++ www/caps/impl.md
	@@ -62,11 +62,11 @@
62	3. You can purposely overwrite good timestamps with bad ones and push
63	those changes up to the remote with no interference, even though
64	Fossil tries to make that a Setup-only operation.
65
66	All of this falls out of two of Fossil’s design choices: sync is
67	all-or-nothing, and [the Fossil hash tree][bc] is immutable. Fossil
68	would have to violate one or both of these principles to filter such
69	problems out of incoming syncs.
70
71	We have considered auto-[shunning][shun] “bad” content on sync, but this
72	is [difficult][asd] due to [the design of the sync protocol][dsp]. This
73

M www/caps/ref.html

+1 -1

		--- www/caps/ref.html
		+++ www/caps/ref.html
		@@ -77,11 +77,11 @@
77	77	<th>d</th>
78	78	<th>n/a</th>
79	79	<td>
80	80	Legacy capability letter from Fossil's forebear <a
81	81	href="http://cvstrac.org/">CVSTrac</a>, which has no useful
82		- meaning in Fossil due to its durable blockchain nature. This
	82	+ meaning in Fossil due to the nature of its durable Merkle tree design. This
83	83	letter was assigned by default to Developer in repos created with
84	84	Fossil 2.10 or earlier, but it has no effect in current or past
85	85	versions of Fossil; we recommend that you remove it in case we
86	86	ever reuse this letter for another purpose. See <a
87	87	href="https://fossil-scm.org/forum/forumpost/43c78f4bef">this
88	88

	--- www/caps/ref.html
	+++ www/caps/ref.html
	@@ -77,11 +77,11 @@
77	<th>d</th>
78	<th>n/a</th>
79	<td>
80	Legacy capability letter from Fossil's forebear <a
81	href="http://cvstrac.org/">CVSTrac</a>, which has no useful
82	meaning in Fossil due to its durable blockchain nature. This
83	letter was assigned by default to Developer in repos created with
84	Fossil 2.10 or earlier, but it has no effect in current or past
85	versions of Fossil; we recommend that you remove it in case we
86	ever reuse this letter for another purpose. See <a
87	href="https://fossil-scm.org/forum/forumpost/43c78f4bef">this
88

	--- www/caps/ref.html
	+++ www/caps/ref.html
	@@ -77,11 +77,11 @@
77	<th>d</th>
78	<th>n/a</th>
79	<td>
80	Legacy capability letter from Fossil's forebear <a
81	href="http://cvstrac.org/">CVSTrac</a>, which has no useful
82	meaning in Fossil due to the nature of its durable Merkle tree design. This
83	letter was assigned by default to Developer in repos created with
84	Fossil 2.10 or earlier, but it has no effect in current or past
85	versions of Fossil; we recommend that you remove it in case we
86	ever reuse this letter for another purpose. See <a
87	href="https://fossil-scm.org/forum/forumpost/43c78f4bef">this
88

M www/checkin_names.wiki

+1 -1

		--- www/checkin_names.wiki
		+++ www/checkin_names.wiki
		@@ -288,8 +288,8 @@
288	288	# [#root \| root:BRANCH]
289	289	# [#merge-in \| merge-in:BRANCH]
290	290	# [#tag-ts \| TAG:timestamp]
291	291	# Full artifact hash or hash prefix.
292	292	# Any other type of symbolic name that Fossil extracts from
293		- blockchain artifacts.
	293	+ artifacts.
294	294
295	295	<div style="height:40em" id="this-space-intentionally-left-blank"></div>
296	296

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -288,8 +288,8 @@
288	# [#root \| root:BRANCH]
289	# [#merge-in \| merge-in:BRANCH]
290	# [#tag-ts \| TAG:timestamp]
291	# Full artifact hash or hash prefix.
292	# Any other type of symbolic name that Fossil extracts from
293	blockchain artifacts.
294
295	<div style="height:40em" id="this-space-intentionally-left-blank"></div>
296

	--- www/checkin_names.wiki
	+++ www/checkin_names.wiki
	@@ -288,8 +288,8 @@
288	# [#root \| root:BRANCH]
289	# [#merge-in \| merge-in:BRANCH]
290	# [#tag-ts \| TAG:timestamp]
291	# Full artifact hash or hash prefix.
292	# Any other type of symbolic name that Fossil extracts from
293	artifacts.
294
295	<div style="height:40em" id="this-space-intentionally-left-blank"></div>
296

M www/fileedit-page.md

+1 -1

		--- www/fileedit-page.md
		+++ www/fileedit-page.md
		@@ -56,11 +56,11 @@
56	56	[xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest
57	57
58	58	## `/fileedit` Works by Creating Commits
59	59
60	60	Thus any edits made via that page become a normal part of the
61		-repository's blockchain.
	61	+repository.
62	62
63	63	## `/fileedit` is Intended for use with Embedded Docs
64	64
65	65	... and similar text files, and is most certainly
66	66	not intended for editing code.
67	67

	--- www/fileedit-page.md
	+++ www/fileedit-page.md
	@@ -56,11 +56,11 @@
56	[xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest
57
58	## `/fileedit` Works by Creating Commits
59
60	Thus any edits made via that page become a normal part of the
61	repository's blockchain.
62
63	## `/fileedit` is Intended for use with Embedded Docs
64
65	... and similar text files, and is most certainly
66	not intended for editing code.
67

	--- www/fileedit-page.md
	+++ www/fileedit-page.md
	@@ -56,11 +56,11 @@
56	[xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest
57
58	## `/fileedit` Works by Creating Commits
59
60	Thus any edits made via that page become a normal part of the
61	repository.
62
63	## `/fileedit` is Intended for use with Embedded Docs
64
65	... and similar text files, and is most certainly
66	not intended for editing code.
67

M www/fossil-v-git.wiki

+3 -3

		--- www/fossil-v-git.wiki
		+++ www/fossil-v-git.wiki
		@@ -230,11 +230,11 @@
230	230
231	231	The baseline data structures for Fossil and Git are the same, modulo
232	232	formatting details. Both systems manage a
233	233	[https://en.wikipedia.org/wiki/Directed_acyclic_graph \| directed acyclic
234	234	graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree \| Merkle
235		-tree] / [./blockchain.md \| block chain] structured check-in objects.
	235	+tree] structured check-in objects.
236	236	Check-ins are identified by a cryptographic hash of the check-in
237	237	contents, and each check-in refers to its parent via <i>its</i> hash.
238	238
239	239	The difference is that Git stores its objects as individual files in the
240	240	<tt>.git</tt> folder or compressed into bespoke
		@@ -741,11 +741,11 @@
741	741	repository immediately if successful, even though you haven't tested the
742	742	change yet. It's possible to argue for such a design in a tool like Git
743	743	which doesn't automatically push the change up to its parent, because
744	744	you can still test the change before pushing local changes to the parent
745	745	repo, but in the meantime you've made a durable change to your local Git
746		-repository's blockchain. You must do something drastic like <tt>git
	746	+repository. You must do something drastic like <tt>git
747	747	reset --hard</tt> to revert that rebase if it causes a problem. If you
748	748	push your rebased local repo up to the parent without testing first,
749	749	you've now committed the error on a public branch, effectively a
750	750	violation of
751	751	[https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing
		@@ -759,11 +759,11 @@
759	759
760	760	Fossil cannot sensibly work that way because of its default-enabled
761	761	autosync feature. Instead of jumping straight to the commit step, Fossil
762	762	applies the proposed merge to the local working directory only,
763	763	requiring a separate check-in step before the change is committed to the
764		-repository blockchain. This gives you a chance to test the change first,
	764	+repository. This gives you a chance to test the change first,
765	765	either manually or by running your software's automatic tests. (Ideally,
766	766	both!)
767	767
768	768	Another difference is that because Fossil requires an explicit commit
769	769	for a merge, it makes you give an explicit commit <i>message</i> for
770	770

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -230,11 +230,11 @@
230
231	The baseline data structures for Fossil and Git are the same, modulo
232	formatting details. Both systems manage a
233	[https://en.wikipedia.org/wiki/Directed_acyclic_graph \| directed acyclic
234	graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree \| Merkle
235	tree] / [./blockchain.md \| block chain] structured check-in objects.
236	Check-ins are identified by a cryptographic hash of the check-in
237	contents, and each check-in refers to its parent via <i>its</i> hash.
238
239	The difference is that Git stores its objects as individual files in the
240	<tt>.git</tt> folder or compressed into bespoke
	@@ -741,11 +741,11 @@
741	repository immediately if successful, even though you haven't tested the
742	change yet. It's possible to argue for such a design in a tool like Git
743	which doesn't automatically push the change up to its parent, because
744	you can still test the change before pushing local changes to the parent
745	repo, but in the meantime you've made a durable change to your local Git
746	repository's blockchain. You must do something drastic like <tt>git
747	reset --hard</tt> to revert that rebase if it causes a problem. If you
748	push your rebased local repo up to the parent without testing first,
749	you've now committed the error on a public branch, effectively a
750	violation of
751	[https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing
	@@ -759,11 +759,11 @@
759
760	Fossil cannot sensibly work that way because of its default-enabled
761	autosync feature. Instead of jumping straight to the commit step, Fossil
762	applies the proposed merge to the local working directory only,
763	requiring a separate check-in step before the change is committed to the
764	repository blockchain. This gives you a chance to test the change first,
765	either manually or by running your software's automatic tests. (Ideally,
766	both!)
767
768	Another difference is that because Fossil requires an explicit commit
769	for a merge, it makes you give an explicit commit <i>message</i> for
770

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -230,11 +230,11 @@
230
231	The baseline data structures for Fossil and Git are the same, modulo
232	formatting details. Both systems manage a
233	[https://en.wikipedia.org/wiki/Directed_acyclic_graph \| directed acyclic
234	graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree \| Merkle
235	tree] structured check-in objects.
236	Check-ins are identified by a cryptographic hash of the check-in
237	contents, and each check-in refers to its parent via <i>its</i> hash.
238
239	The difference is that Git stores its objects as individual files in the
240	<tt>.git</tt> folder or compressed into bespoke
	@@ -741,11 +741,11 @@
741	repository immediately if successful, even though you haven't tested the
742	change yet. It's possible to argue for such a design in a tool like Git
743	which doesn't automatically push the change up to its parent, because
744	you can still test the change before pushing local changes to the parent
745	repo, but in the meantime you've made a durable change to your local Git
746	repository. You must do something drastic like <tt>git
747	reset --hard</tt> to revert that rebase if it causes a problem. If you
748	push your rebased local repo up to the parent without testing first,
749	you've now committed the error on a public branch, effectively a
750	violation of
751	[https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing
	@@ -759,11 +759,11 @@
759
760	Fossil cannot sensibly work that way because of its default-enabled
761	autosync feature. Instead of jumping straight to the commit step, Fossil
762	applies the proposed merge to the local working directory only,
763	requiring a separate check-in step before the change is committed to the
764	repository. This gives you a chance to test the change first,
765	either manually or by running your software's automatic tests. (Ideally,
766	both!)
767
768	Another difference is that because Fossil requires an explicit commit
769	for a merge, it makes you give an explicit commit <i>message</i> for
770

M www/mirrorlimitations.md

+5 -5

		--- www/mirrorlimitations.md
		+++ www/mirrorlimitations.md
		@@ -14,14 +14,14 @@
14	14	as Wiki, Tickets, Technotes, and the Forum are not supported in Git,
15	15	so those features are not included in an export.
16	16
17	17	Third-party Git based tooling may add some of these features (e.g.
18	18	GitHub, GitLab) but because their data are not stored in the Git
19		-blockchain, there is no single destination for Fossil to convert its
	19	+repository, there is no single destination for Fossil to convert its
20	20	equivalent data to. For instance, Fossil tickets do not become GitHub
21	21	issues, because that is a proprietary feature of GitHub separate from
22		-Git proper, stored outside the blockchain on the GitHub servers.
	22	+Git proper, stored outside the repository on the GitHub servers.
23	23
24	24	You can also see the problem in its inverse case: you do not get a copy
25	25	of your GitHub issues when cloning the Git repository. You do get the
26	26	Fossil tickets, wiki, forum posts, etc. when cloning a remote Fossil
27	27	repo.
		@@ -29,14 +29,14 @@
29	29	## (2) Cherrypick Merges
30	30
31	31	The Git client supports cherrypick merges but does not record the
32	32	cherrypick parent(s).
33	33
34		-Fossil tracks cherrypick merges in its blockchain and displays
	34	+Fossil tracks cherrypick merges in its repository and displays
35	35	cherrypicks in its timeline. (As an example, the dashed lines
36	36	[here](/timeline?c=0a9f12ce6655b7a5) are cherrypicks.) Because Git does
37		-not have a way to represent this same information in its blockchain, the
	37	+not have a way to represent this same information in its repository, the
38	38	history of Fossil cherrypicks cannot be exported to Git, only their
39	39	direct effects on the managed file data.
40	40
41	41	## (3) Named Branches
42	42
		@@ -73,11 +73,11 @@
73	73
74	74	## (5) Amendments To Check-ins
75	75
76	76	Check-ins are immutable in both Fossil and Git.
77	77	However, Fossil has a mechanism by which tags can be added to
78		-its blockchain to provide after-the-fact corrections to prior check-ins.
	78	+its repository to provide after-the-fact corrections to prior check-ins.
79	79
80	80	For example, tags can be added to check-ins that correct typos in the
81	81	check-in comment. The original check-in is immutable and so the
82	82	original comment is preserved in addition to the correction. But
83	83	software that displays the check-ins knows to look for the comment-change
84	84

	--- www/mirrorlimitations.md
	+++ www/mirrorlimitations.md
	@@ -14,14 +14,14 @@
14	as Wiki, Tickets, Technotes, and the Forum are not supported in Git,
15	so those features are not included in an export.
16
17	Third-party Git based tooling may add some of these features (e.g.
18	GitHub, GitLab) but because their data are not stored in the Git
19	blockchain, there is no single destination for Fossil to convert its
20	equivalent data to. For instance, Fossil tickets do not become GitHub
21	issues, because that is a proprietary feature of GitHub separate from
22	Git proper, stored outside the blockchain on the GitHub servers.
23
24	You can also see the problem in its inverse case: you do not get a copy
25	of your GitHub issues when cloning the Git repository. You do get the
26	Fossil tickets, wiki, forum posts, etc. when cloning a remote Fossil
27	repo.
	@@ -29,14 +29,14 @@
29	## (2) Cherrypick Merges
30
31	The Git client supports cherrypick merges but does not record the
32	cherrypick parent(s).
33
34	Fossil tracks cherrypick merges in its blockchain and displays
35	cherrypicks in its timeline. (As an example, the dashed lines
36	[here](/timeline?c=0a9f12ce6655b7a5) are cherrypicks.) Because Git does
37	not have a way to represent this same information in its blockchain, the
38	history of Fossil cherrypicks cannot be exported to Git, only their
39	direct effects on the managed file data.
40
41	## (3) Named Branches
42
	@@ -73,11 +73,11 @@
73
74	## (5) Amendments To Check-ins
75
76	Check-ins are immutable in both Fossil and Git.
77	However, Fossil has a mechanism by which tags can be added to
78	its blockchain to provide after-the-fact corrections to prior check-ins.
79
80	For example, tags can be added to check-ins that correct typos in the
81	check-in comment. The original check-in is immutable and so the
82	original comment is preserved in addition to the correction. But
83	software that displays the check-ins knows to look for the comment-change
84

	--- www/mirrorlimitations.md
	+++ www/mirrorlimitations.md
	@@ -14,14 +14,14 @@
14	as Wiki, Tickets, Technotes, and the Forum are not supported in Git,
15	so those features are not included in an export.
16
17	Third-party Git based tooling may add some of these features (e.g.
18	GitHub, GitLab) but because their data are not stored in the Git
19	repository, there is no single destination for Fossil to convert its
20	equivalent data to. For instance, Fossil tickets do not become GitHub
21	issues, because that is a proprietary feature of GitHub separate from
22	Git proper, stored outside the repository on the GitHub servers.
23
24	You can also see the problem in its inverse case: you do not get a copy
25	of your GitHub issues when cloning the Git repository. You do get the
26	Fossil tickets, wiki, forum posts, etc. when cloning a remote Fossil
27	repo.
	@@ -29,14 +29,14 @@
29	## (2) Cherrypick Merges
30
31	The Git client supports cherrypick merges but does not record the
32	cherrypick parent(s).
33
34	Fossil tracks cherrypick merges in its repository and displays
35	cherrypicks in its timeline. (As an example, the dashed lines
36	[here](/timeline?c=0a9f12ce6655b7a5) are cherrypicks.) Because Git does
37	not have a way to represent this same information in its repository, the
38	history of Fossil cherrypicks cannot be exported to Git, only their
39	direct effects on the managed file data.
40
41	## (3) Named Branches
42
	@@ -73,11 +73,11 @@
73
74	## (5) Amendments To Check-ins
75
76	Check-ins are immutable in both Fossil and Git.
77	However, Fossil has a mechanism by which tags can be added to
78	its repository to provide after-the-fact corrections to prior check-ins.
79
80	For example, tags can be added to check-ins that correct typos in the
81	check-in comment. The original check-in is immutable and so the
82	original comment is preserved in addition to the correction. But
83	software that displays the check-ins knows to look for the comment-change
84

M www/mkindex.tcl

+1 -1

		--- www/mkindex.tcl
		+++ www/mkindex.tcl
		@@ -14,11 +14,11 @@
14	14	alerts.md {Email Alerts And Notifications}
15	15	antibot.wiki {Defense against Spiders and Bots}
16	16	backoffice.md {The "Backoffice" mechanism of Fossil}
17	17	backup.md {Backing Up a Remote Fossil Repository}
18	18	blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19		- blockchain.md {Fossil As Blockchain}
	19	+ blockchain.md {Is Fossil A Blockchain?}
20	20	branching.wiki {Branching, Forking, Merging, and Tagging}
21	21	bugtheory.wiki {Bug Tracking In Fossil}
22	22	build.wiki {Compiling and Installing Fossil}
23	23	cap-theorem.md {Fossil and the CAP Theorem}
24	24	caps/ {Administering User Capabilities}
25	25

	--- www/mkindex.tcl
	+++ www/mkindex.tcl
	@@ -14,11 +14,11 @@
14	alerts.md {Email Alerts And Notifications}
15	antibot.wiki {Defense against Spiders and Bots}
16	backoffice.md {The "Backoffice" mechanism of Fossil}
17	backup.md {Backing Up a Remote Fossil Repository}
18	blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19	blockchain.md {Fossil As Blockchain}
20	branching.wiki {Branching, Forking, Merging, and Tagging}
21	bugtheory.wiki {Bug Tracking In Fossil}
22	build.wiki {Compiling and Installing Fossil}
23	cap-theorem.md {Fossil and the CAP Theorem}
24	caps/ {Administering User Capabilities}
25

	--- www/mkindex.tcl
	+++ www/mkindex.tcl
	@@ -14,11 +14,11 @@
14	alerts.md {Email Alerts And Notifications}
15	antibot.wiki {Defense against Spiders and Bots}
16	backoffice.md {The "Backoffice" mechanism of Fossil}
17	backup.md {Backing Up a Remote Fossil Repository}
18	blame.wiki {The Annotate/Blame Algorithm Of Fossil}
19	blockchain.md {Is Fossil A Blockchain?}
20	branching.wiki {Branching, Forking, Merging, and Tagging}
21	bugtheory.wiki {Bug Tracking In Fossil}
22	build.wiki {Compiling and Installing Fossil}
23	cap-theorem.md {Fossil and the CAP Theorem}
24	caps/ {Administering User Capabilities}
25

M www/permutedindex.html

+2 -2

		--- www/permutedindex.html
		+++ www/permutedindex.html
		@@ -41,11 +41,11 @@
41	41	<li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li>
42	42	<li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li>
43	43	<li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li>
44	44	<li><a href="caps/admin-v-setup.md">Between Setup and Admin Users — Differences</a></li>
45	45	<li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li>
46		-<li><a href="blockchain.md">Blockchain — Fossil As</a></li>
	46	+<li><a href="blockchain.md">Blockchain? — Is Fossil A</a></li>
47	47	<li><a href="antibot.wiki">Bots — Defense against Spiders and</a></li>
48	48	<li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li>
49	49	<li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
50	50	<li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
51	51	<li><a href="makefile.wiki">Build Process — The Fossil</a></li>
		@@ -126,11 +126,10 @@
126	126	<li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size — Image</a></li>
127	127	<li><a href="../../../md_rules">Formatting Rules — Markdown</a></li>
128	128	<li><a href="../../../wiki_rules">Formatting Rules — Wiki</a></li>
129	129	<li><a href="forum.wiki">Forums — Fossil</a></li>
130	130	<li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li>
131		-<li><a href="blockchain.md"><b>Fossil As Blockchain</b></a></li>
132	131	<li><a href="changes.wiki"><b>Fossil Changelog</b></a></li>
133	132	<li><a href="concepts.wiki"><b>Fossil Core Concepts</b></a></li>
134	133	<li><a href="css-tricks.md"><b>Fossil CSS Tips and Tricks</b></a></li>
135	134	<li><a href="delta_encoder_algorithm.wiki"><b>Fossil Delta Encoding Algorithm</b></a></li>
136	135	<li><a href="delta_format.wiki"><b>Fossil Delta Format</b></a></li>
		@@ -188,10 +187,11 @@
188	187	<li><a href="build.wiki">Installing Fossil — Compiling and</a></li>
189	188	<li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li>
190	189	<li><a href="selfcheck.wiki">Integrity Self Checks — Fossil Repository</a></li>
191	190	<li><a href="webui.wiki">Interface — The Fossil Web</a></li>
192	191	<li><a href="interwiki.md"><b>Interwiki Links</b></a></li>
	192	+<li><a href="blockchain.md"><b>Is Fossil A Blockchain?</b></a></li>
193	193	<li><a href="javascript.md">JavaScript in Fossil — Use of</a></li>
194	194	<li><a href="th1.md">Language — The TH1 Scripting</a></li>
195	195	<li><a href="copyright-release.html">License Agreement — Contributor</a></li>
196	196	<li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li>
197	197	<li><a href="interwiki.md">Links — Interwiki</a></li>
198	198

	--- www/permutedindex.html
	+++ www/permutedindex.html
	@@ -41,11 +41,11 @@
41	<li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li>
42	<li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li>
43	<li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li>
44	<li><a href="caps/admin-v-setup.md">Between Setup and Admin Users — Differences</a></li>
45	<li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li>
46	<li><a href="blockchain.md">Blockchain — Fossil As</a></li>
47	<li><a href="antibot.wiki">Bots — Defense against Spiders and</a></li>
48	<li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li>
49	<li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
50	<li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
51	<li><a href="makefile.wiki">Build Process — The Fossil</a></li>
	@@ -126,11 +126,10 @@
126	<li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size — Image</a></li>
127	<li><a href="../../../md_rules">Formatting Rules — Markdown</a></li>
128	<li><a href="../../../wiki_rules">Formatting Rules — Wiki</a></li>
129	<li><a href="forum.wiki">Forums — Fossil</a></li>
130	<li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li>
131	<li><a href="blockchain.md"><b>Fossil As Blockchain</b></a></li>
132	<li><a href="changes.wiki"><b>Fossil Changelog</b></a></li>
133	<li><a href="concepts.wiki"><b>Fossil Core Concepts</b></a></li>
134	<li><a href="css-tricks.md"><b>Fossil CSS Tips and Tricks</b></a></li>
135	<li><a href="delta_encoder_algorithm.wiki"><b>Fossil Delta Encoding Algorithm</b></a></li>
136	<li><a href="delta_format.wiki"><b>Fossil Delta Format</b></a></li>
	@@ -188,10 +187,11 @@
188	<li><a href="build.wiki">Installing Fossil — Compiling and</a></li>
189	<li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li>
190	<li><a href="selfcheck.wiki">Integrity Self Checks — Fossil Repository</a></li>
191	<li><a href="webui.wiki">Interface — The Fossil Web</a></li>
192	<li><a href="interwiki.md"><b>Interwiki Links</b></a></li>

193	<li><a href="javascript.md">JavaScript in Fossil — Use of</a></li>
194	<li><a href="th1.md">Language — The TH1 Scripting</a></li>
195	<li><a href="copyright-release.html">License Agreement — Contributor</a></li>
196	<li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li>
197	<li><a href="interwiki.md">Links — Interwiki</a></li>
198

	--- www/permutedindex.html
	+++ www/permutedindex.html
	@@ -41,11 +41,11 @@
41	<li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li>
42	<li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li>
43	<li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li>
44	<li><a href="caps/admin-v-setup.md">Between Setup and Admin Users — Differences</a></li>
45	<li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li>
46	<li><a href="blockchain.md">Blockchain? — Is Fossil A</a></li>
47	<li><a href="antibot.wiki">Bots — Defense against Spiders and</a></li>
48	<li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li>
49	<li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li>
50	<li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li>
51	<li><a href="makefile.wiki">Build Process — The Fossil</a></li>
	@@ -126,11 +126,10 @@
126	<li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size — Image</a></li>
127	<li><a href="../../../md_rules">Formatting Rules — Markdown</a></li>
128	<li><a href="../../../wiki_rules">Formatting Rules — Wiki</a></li>
129	<li><a href="forum.wiki">Forums — Fossil</a></li>
130	<li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li>

131	<li><a href="changes.wiki"><b>Fossil Changelog</b></a></li>
132	<li><a href="concepts.wiki"><b>Fossil Core Concepts</b></a></li>
133	<li><a href="css-tricks.md"><b>Fossil CSS Tips and Tricks</b></a></li>
134	<li><a href="delta_encoder_algorithm.wiki"><b>Fossil Delta Encoding Algorithm</b></a></li>
135	<li><a href="delta_format.wiki"><b>Fossil Delta Format</b></a></li>
	@@ -188,10 +187,11 @@
187	<li><a href="build.wiki">Installing Fossil — Compiling and</a></li>
188	<li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li>
189	<li><a href="selfcheck.wiki">Integrity Self Checks — Fossil Repository</a></li>
190	<li><a href="webui.wiki">Interface — The Fossil Web</a></li>
191	<li><a href="interwiki.md"><b>Interwiki Links</b></a></li>
192	<li><a href="blockchain.md"><b>Is Fossil A Blockchain?</b></a></li>
193	<li><a href="javascript.md">JavaScript in Fossil — Use of</a></li>
194	<li><a href="th1.md">Language — The TH1 Scripting</a></li>
195	<li><a href="copyright-release.html">License Agreement — Contributor</a></li>
196	<li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li>
197	<li><a href="interwiki.md">Links — Interwiki</a></li>
198

M www/shunning.wiki

+2 -2

		--- www/shunning.wiki
		+++ www/shunning.wiki
		@@ -32,12 +32,12 @@
32	32	some alternatives that usually suffice, which don't damage the project's
33	33	fossil record:
34	34
35	35	<ul>
36	36	<li><p>When a forum post or wiki article is "deleted," what actually
37		- happens is that a new empty version is added to the Fossil
38		- [./blockchain.md \| block chain]. The web interface interprets this
	37	+ happens is that a new empty version is added to the Fossil repository.
	38	+ The web interface interprets this
39	39	as "deleted," but the prior version remains available if you go
40	40	digging for it.</p></li>
41	41
42	42	<li><p>When you close a ticket, it's marked in a way that causes it
43	43	to not show up in the normal ticket reports. You usually want to
44	44

	--- www/shunning.wiki
	+++ www/shunning.wiki
	@@ -32,12 +32,12 @@
32	some alternatives that usually suffice, which don't damage the project's
33	fossil record:
34
35	<ul>
36	<li><p>When a forum post or wiki article is "deleted," what actually
37	happens is that a new empty version is added to the Fossil
38	[./blockchain.md \| block chain]. The web interface interprets this
39	as "deleted," but the prior version remains available if you go
40	digging for it.</p></li>
41
42	<li><p>When you close a ticket, it's marked in a way that causes it
43	to not show up in the normal ticket reports. You usually want to
44

	--- www/shunning.wiki
	+++ www/shunning.wiki
	@@ -32,12 +32,12 @@
32	some alternatives that usually suffice, which don't damage the project's
33	fossil record:
34
35	<ul>
36	<li><p>When a forum post or wiki article is "deleted," what actually
37	happens is that a new empty version is added to the Fossil repository.
38	The web interface interprets this
39	as "deleted," but the prior version remains available if you go
40	digging for it.</p></li>
41
42	<li><p>When you close a ticket, it's marked in a way that causes it
43	to not show up in the normal ticket reports. You usually want to
44

Fossil SCM

Keyboard Shortcuts