Fossil SCM

Replace some usage of <center> tags with align="center" attributes.

jan.nijtmans 2016-06-23 07:43 trunk
Commit fcfaae37dcbf82a1f49fc3972dabc93dea98f03c
Parent 243fc6c2467988f…
7 files changed +3 -4 +10 -10 +1 -3 +23 -23 +1 -1 +9 -9 +18 -19
~ src/user.c ~ www/branching.wiki ~ www/copyright-release.html ~ www/fossil-v-git.wiki ~ www/index.wiki ~ www/sync.wiki ~ www/tech_overview.wiki
M src/user.c
+3 -4
--- src/user.c
+++ src/user.c
@@ -540,15 +540,14 @@
540540
 style_submenu_element("Newer", "Newer entries",
541541
 "%s/access_log?o=%d&n=%d&y=%d", g.zTop, skip>=n ? skip-n : 0,
542542
 n, y);
543543
 }
544544
 rc = db_prepare_ignore_error(&q, "%s", blob_sql_text(&sql));
545
- @ <center>
546545
 fLogEnabled = db_get_boolean("access-log", 0);
547
- @ <div>Access logging is %s(fLogEnabled?"on":"off").
546
+ @ <div align="center">Access logging is %s(fLogEnabled?"on":"off").
548547
 @ (Change this on the <a href="setup_settings">settings</a> page.)</div>
549
- @ <table border="1" cellpadding="5" id='logtable'>
548
+ @ <table border="1" cellpadding="5" id="logtable" align="center">
550549
 @ <thead><tr><th width="33%%">Date</th><th width="34%%">User</th>
551550
 @ <th width="33%%">IP Address</th></tr></thead><tbody>
552551
 while( rc==SQLITE_OK && db_step(&q)==SQLITE_ROW ){
553552
 const char *zName = db_column_text(&q, 0);
554553
 const char *zIP = db_column_text(&q, 1);
@@ -569,11 +568,11 @@
569568
 }
570569
 if( skip>0 || cnt>n ){
571570
 style_submenu_element("All", "All entries",
572571
 "%s/access_log?n=10000000", g.zTop);
573572
 }
574
- @ </tbody></table></center>
573
+ @ </tbody></table>
575574
 db_finalize(&q);
576575
 @ <hr />
577576
 @ <form method="post" action="%s(g.zTop)/access_log">
578577
 @ <label><input type="checkbox" name="delold">
579578
 @ Delete all but the most recent 200 entries</input></label>
580579
--- src/user.c
+++ src/user.c
@@ -540,15 +540,14 @@
540 style_submenu_element("Newer", "Newer entries",
541 "%s/access_log?o=%d&n=%d&y=%d", g.zTop, skip>=n ? skip-n : 0,
542 n, y);
543 }
544 rc = db_prepare_ignore_error(&q, "%s", blob_sql_text(&sql));
545 @ <center>
546 fLogEnabled = db_get_boolean("access-log", 0);
547 @ <div>Access logging is %s(fLogEnabled?"on":"off").
548 @ (Change this on the <a href="setup_settings">settings</a> page.)</div>
549 @ <table border="1" cellpadding="5" id='logtable'>
550 @ <thead><tr><th width="33%%">Date</th><th width="34%%">User</th>
551 @ <th width="33%%">IP Address</th></tr></thead><tbody>
552 while( rc==SQLITE_OK && db_step(&q)==SQLITE_ROW ){
553 const char *zName = db_column_text(&q, 0);
554 const char *zIP = db_column_text(&q, 1);
@@ -569,11 +568,11 @@
569 }
570 if( skip>0 || cnt>n ){
571 style_submenu_element("All", "All entries",
572 "%s/access_log?n=10000000", g.zTop);
573 }
574 @ </tbody></table></center>
575 db_finalize(&q);
576 @ <hr />
577 @ <form method="post" action="%s(g.zTop)/access_log">
578 @ <label><input type="checkbox" name="delold">
579 @ Delete all but the most recent 200 entries</input></label>
580
--- src/user.c
+++ src/user.c
@@ -540,15 +540,14 @@
540 style_submenu_element("Newer", "Newer entries",
541 "%s/access_log?o=%d&n=%d&y=%d", g.zTop, skip>=n ? skip-n : 0,
542 n, y);
543 }
544 rc = db_prepare_ignore_error(&q, "%s", blob_sql_text(&sql));
 
545 fLogEnabled = db_get_boolean("access-log", 0);
546 @ <div align="center">Access logging is %s(fLogEnabled?"on":"off").
547 @ (Change this on the <a href="setup_settings">settings</a> page.)</div>
548 @ <table border="1" cellpadding="5" id="logtable" align="center">
549 @ <thead><tr><th width="33%%">Date</th><th width="34%%">User</th>
550 @ <th width="33%%">IP Address</th></tr></thead><tbody>
551 while( rc==SQLITE_OK && db_step(&q)==SQLITE_ROW ){
552 const char *zName = db_column_text(&q, 0);
553 const char *zIP = db_column_text(&q, 1);
@@ -569,11 +568,11 @@
568 }
569 if( skip>0 || cnt>n ){
570 style_submenu_element("All", "All entries",
571 "%s/access_log?n=10000000", g.zTop);
572 }
573 @ </tbody></table>
574 db_finalize(&q);
575 @ <hr />
576 @ <form method="post" action="%s(g.zTop)/access_log">
577 @ <label><input type="checkbox" name="delold">
578 @ Delete all but the most recent 200 entries</input></label>
579
M www/branching.wiki
+10 -10
--- www/branching.wiki
+++ www/branching.wiki
@@ -2,15 +2,15 @@
22
 <h2>Background</h2>
33
44
 In a simple and perfect world, the development of a project would proceed
55
 linearly, as shown in figure 1.
66
7
-<center><table border=1 cellpadding=10 hspace=10 vspace=10>
7
+<table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
88
 <tr><td align="center">
99
 <img src="branch01.gif" width=280 height=68><br>
1010
 Figure 1
11
-</td></tr></table></center>
11
+</td></tr></table>
1212
1313
 Each circle represents a check-in. For the sake of clarity, the check-ins
1414
 are given small consecutive numbers. In a real system, of course, the
1515
 check-in numbers would be 40-character SHA1 hashes since it is not possible
1616
 to allocate collision-free sequential numbers in a distributed system.
@@ -38,15 +38,15 @@
3838
3939
 Alas, reality often interferes with the simple linear development of a
4040
 project. Suppose two programmers make independent modifications to check-in 2.
4141
 After both changes are committed, the check-in graph looks like figure 2:
4242
43
-<center><table border=1 cellpadding=10 hspace=10 vspace=10>
43
+<table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
4444
 <tr><td align="center">
4545
 <img src="branch02.gif" width=210 height=140><br>
4646
 Figure 2
47
-</td></tr></table></center>
47
+</td></tr></table>
4848
4949
 The graph in figure 2 has two leaves: check-ins 3 and 4. Check-in 2 has
5050
 two children, check-ins 3 and 4. We call this state a <i>fork</i>.
5151
5252
 Fossil tries to prevent forks. Suppose two programmers named Alice and
@@ -77,15 +77,15 @@
7777
 To resolve this situation, Alice can use the fossil <b>merge</b> command
7878
 to merge in Bob's changes in her local copy of check-in 3. Then she
7979
 can commit the results as check-in 5. This results in a DAG as shown
8080
 in figure 3.
8181
82
-<center><table border=1 cellpadding=10 hspace=10 vspace=10>
82
+<table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
8383
 <tr><td align="center">
8484
 <img src="branch03.gif" width=282 height=152><br>
8585
 Figure 3
86
-</td></tr></table></center>
86
+</td></tr></table>
8787
8888
 Check-in 5 is a child of check-in 3 because it was created by editing
8989
 check-in 3. But check-in 5 also inherits the changes from check-in 4 by
9090
 virtue of the merge. So we say that check-in 5 is a <i>merge child</i>
9191
 of check-in 4 and that it is a <i>direct child</i> of check-in 3.
@@ -124,15 +124,15 @@
124124
 When multiple leaves are desirable, we call this <i>branching</i>
125125
 instead of <i>forking</i>.
126126
 Figure 4 shows an example of a project where there are two branches, one
127127
 for development work and another for testing.
128128
129
-<center><table border=1 cellpadding=10 hspace=10 vspace=10>
129
+<table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
130130
 <tr><td align="center">
131131
 <img src="branch04.gif" width=426 height=123><br>
132132
 Figure 4
133
-</td></tr></table></center>
133
+</td></tr></table>
134134
135135
 The hypothetical scenario of figure 4 is this: The project starts and
136136
 progresses to a point where (at check-in 2)
137137
 it is ready to enter testing for its first release.
138138
 In a real project, of course, there might be hundreds or thousands of
@@ -164,15 +164,15 @@
164164
165165
 Tags and properties are used in fossil to help express the intent, and
166166
 thus to distinguish between forks and branches. Figure 5 shows the
167167
 same scenario as figure 4 but with tags and properties added:
168168
169
-<center><table border=1 cellpadding=10 hspace=10 vspace=10>
169
+<table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
170170
 <tr><td align="center">
171171
 <img src="branch05.gif" width=485 height=177><br>
172172
 Figure 5
173
-</td></tr></table></center>
173
+</td></tr></table>
174174
175175
 A <i>tag</i> is a name that is attached to a check-in. A
176176
 <i>property</i> is a name/value pair. Internally, fossil implements
177177
 tags as properties with a NULL value. So, tags and properties really
178178
 are much the same thing, and henceforth we will use the word "tag"
179179
--- www/branching.wiki
+++ www/branching.wiki
@@ -2,15 +2,15 @@
2 <h2>Background</h2>
3
4 In a simple and perfect world, the development of a project would proceed
5 linearly, as shown in figure 1.
6
7 <center><table border=1 cellpadding=10 hspace=10 vspace=10>
8 <tr><td align="center">
9 <img src="branch01.gif" width=280 height=68><br>
10 Figure 1
11 </td></tr></table></center>
12
13 Each circle represents a check-in. For the sake of clarity, the check-ins
14 are given small consecutive numbers. In a real system, of course, the
15 check-in numbers would be 40-character SHA1 hashes since it is not possible
16 to allocate collision-free sequential numbers in a distributed system.
@@ -38,15 +38,15 @@
38
39 Alas, reality often interferes with the simple linear development of a
40 project. Suppose two programmers make independent modifications to check-in 2.
41 After both changes are committed, the check-in graph looks like figure 2:
42
43 <center><table border=1 cellpadding=10 hspace=10 vspace=10>
44 <tr><td align="center">
45 <img src="branch02.gif" width=210 height=140><br>
46 Figure 2
47 </td></tr></table></center>
48
49 The graph in figure 2 has two leaves: check-ins 3 and 4. Check-in 2 has
50 two children, check-ins 3 and 4. We call this state a <i>fork</i>.
51
52 Fossil tries to prevent forks. Suppose two programmers named Alice and
@@ -77,15 +77,15 @@
77 To resolve this situation, Alice can use the fossil <b>merge</b> command
78 to merge in Bob's changes in her local copy of check-in 3. Then she
79 can commit the results as check-in 5. This results in a DAG as shown
80 in figure 3.
81
82 <center><table border=1 cellpadding=10 hspace=10 vspace=10>
83 <tr><td align="center">
84 <img src="branch03.gif" width=282 height=152><br>
85 Figure 3
86 </td></tr></table></center>
87
88 Check-in 5 is a child of check-in 3 because it was created by editing
89 check-in 3. But check-in 5 also inherits the changes from check-in 4 by
90 virtue of the merge. So we say that check-in 5 is a <i>merge child</i>
91 of check-in 4 and that it is a <i>direct child</i> of check-in 3.
@@ -124,15 +124,15 @@
124 When multiple leaves are desirable, we call this <i>branching</i>
125 instead of <i>forking</i>.
126 Figure 4 shows an example of a project where there are two branches, one
127 for development work and another for testing.
128
129 <center><table border=1 cellpadding=10 hspace=10 vspace=10>
130 <tr><td align="center">
131 <img src="branch04.gif" width=426 height=123><br>
132 Figure 4
133 </td></tr></table></center>
134
135 The hypothetical scenario of figure 4 is this: The project starts and
136 progresses to a point where (at check-in 2)
137 it is ready to enter testing for its first release.
138 In a real project, of course, there might be hundreds or thousands of
@@ -164,15 +164,15 @@
164
165 Tags and properties are used in fossil to help express the intent, and
166 thus to distinguish between forks and branches. Figure 5 shows the
167 same scenario as figure 4 but with tags and properties added:
168
169 <center><table border=1 cellpadding=10 hspace=10 vspace=10>
170 <tr><td align="center">
171 <img src="branch05.gif" width=485 height=177><br>
172 Figure 5
173 </td></tr></table></center>
174
175 A <i>tag</i> is a name that is attached to a check-in. A
176 <i>property</i> is a name/value pair. Internally, fossil implements
177 tags as properties with a NULL value. So, tags and properties really
178 are much the same thing, and henceforth we will use the word "tag"
179
--- www/branching.wiki
+++ www/branching.wiki
@@ -2,15 +2,15 @@
2 <h2>Background</h2>
3
4 In a simple and perfect world, the development of a project would proceed
5 linearly, as shown in figure 1.
6
7 <table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
8 <tr><td align="center">
9 <img src="branch01.gif" width=280 height=68><br>
10 Figure 1
11 </td></tr></table>
12
13 Each circle represents a check-in. For the sake of clarity, the check-ins
14 are given small consecutive numbers. In a real system, of course, the
15 check-in numbers would be 40-character SHA1 hashes since it is not possible
16 to allocate collision-free sequential numbers in a distributed system.
@@ -38,15 +38,15 @@
38
39 Alas, reality often interferes with the simple linear development of a
40 project. Suppose two programmers make independent modifications to check-in 2.
41 After both changes are committed, the check-in graph looks like figure 2:
42
43 <table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
44 <tr><td align="center">
45 <img src="branch02.gif" width=210 height=140><br>
46 Figure 2
47 </td></tr></table>
48
49 The graph in figure 2 has two leaves: check-ins 3 and 4. Check-in 2 has
50 two children, check-ins 3 and 4. We call this state a <i>fork</i>.
51
52 Fossil tries to prevent forks. Suppose two programmers named Alice and
@@ -77,15 +77,15 @@
77 To resolve this situation, Alice can use the fossil <b>merge</b> command
78 to merge in Bob's changes in her local copy of check-in 3. Then she
79 can commit the results as check-in 5. This results in a DAG as shown
80 in figure 3.
81
82 <table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
83 <tr><td align="center">
84 <img src="branch03.gif" width=282 height=152><br>
85 Figure 3
86 </td></tr></table>
87
88 Check-in 5 is a child of check-in 3 because it was created by editing
89 check-in 3. But check-in 5 also inherits the changes from check-in 4 by
90 virtue of the merge. So we say that check-in 5 is a <i>merge child</i>
91 of check-in 4 and that it is a <i>direct child</i> of check-in 3.
@@ -124,15 +124,15 @@
124 When multiple leaves are desirable, we call this <i>branching</i>
125 instead of <i>forking</i>.
126 Figure 4 shows an example of a project where there are two branches, one
127 for development work and another for testing.
128
129 <table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
130 <tr><td align="center">
131 <img src="branch04.gif" width=426 height=123><br>
132 Figure 4
133 </td></tr></table>
134
135 The hypothetical scenario of figure 4 is this: The project starts and
136 progresses to a point where (at check-in 2)
137 it is ready to enter testing for its first release.
138 In a real project, of course, there might be hundreds or thousands of
@@ -164,15 +164,15 @@
164
165 Tags and properties are used in fossil to help express the intent, and
166 thus to distinguish between forks and branches. Figure 5 shows the
167 same scenario as figure 4 but with tags and properties added:
168
169 <table border=1 cellpadding=10 hspace=10 vspace=10 align="center">
170 <tr><td align="center">
171 <img src="branch05.gif" width=485 height=177><br>
172 Figure 5
173 </td></tr></table>
174
175 A <i>tag</i> is a name that is attached to a check-in. A
176 <i>property</i> is a name/value pair. Internally, fossil implements
177 tags as properties with a NULL value. So, tags and properties really
178 are much the same thing, and henceforth we will use the word "tag"
179
M www/copyright-release.html
+1 -3
--- www/copyright-release.html
+++ www/copyright-release.html
@@ -74,12 +74,11 @@
7474
7575
 <p>By filling in the following information and signing your name,
7676
 you agree to be bound by all of the terms
7777
 set forth in this agreement. Please print clearly.</p>
7878
79
-<center>
80
-<p><table width="80%" border="1" cellpadding="0" cellspacing="0">
79
+<p><table width="80%" border="1" cellpadding="0" cellspacing="0" align="center">
8180
 <tr><td width="20%" valign="top">Your name &amp email:</td><td width="80%">
8281
8382
 <!-- Replace this line with your name and email --> &nbsp;<p>&nbsp;
8483
8584
 </td></tr>
@@ -95,14 +94,13 @@
9594
9695
 </td></tr>
9796
 <tr><td valign="top">Signature:</td><td>&nbsp;<p>&nbsp;</td></tr>
9897
 <tr><td valign="top">Date:</td><td>&nbsp;<p>&nbsp;</td></tr>
9998
 </table>
100
-</center>
10199
102100
 <p>Send completed forms to:
103101
 <blockquote>
104102
 Hipp, Wyrick &amp; Company, Inc.<br>
105103
 6200 Maple Cove Lane<br>
106104
 Charlotte, NC 28269-1086<br>
107105
 USA
108106
 </p>
109107
--- www/copyright-release.html
+++ www/copyright-release.html
@@ -74,12 +74,11 @@
74
75 <p>By filling in the following information and signing your name,
76 you agree to be bound by all of the terms
77 set forth in this agreement. Please print clearly.</p>
78
79 <center>
80 <p><table width="80%" border="1" cellpadding="0" cellspacing="0">
81 <tr><td width="20%" valign="top">Your name &amp email:</td><td width="80%">
82
83 <!-- Replace this line with your name and email --> &nbsp;<p>&nbsp;
84
85 </td></tr>
@@ -95,14 +94,13 @@
95
96 </td></tr>
97 <tr><td valign="top">Signature:</td><td>&nbsp;<p>&nbsp;</td></tr>
98 <tr><td valign="top">Date:</td><td>&nbsp;<p>&nbsp;</td></tr>
99 </table>
100 </center>
101
102 <p>Send completed forms to:
103 <blockquote>
104 Hipp, Wyrick &amp; Company, Inc.<br>
105 6200 Maple Cove Lane<br>
106 Charlotte, NC 28269-1086<br>
107 USA
108 </p>
109
--- www/copyright-release.html
+++ www/copyright-release.html
@@ -74,12 +74,11 @@
74
75 <p>By filling in the following information and signing your name,
76 you agree to be bound by all of the terms
77 set forth in this agreement. Please print clearly.</p>
78
79 <p><table width="80%" border="1" cellpadding="0" cellspacing="0" align="center">
 
80 <tr><td width="20%" valign="top">Your name &amp email:</td><td width="80%">
81
82 <!-- Replace this line with your name and email --> &nbsp;<p>&nbsp;
83
84 </td></tr>
@@ -95,14 +94,13 @@
94
95 </td></tr>
96 <tr><td valign="top">Signature:</td><td>&nbsp;<p>&nbsp;</td></tr>
97 <tr><td valign="top">Date:</td><td>&nbsp;<p>&nbsp;</td></tr>
98 </table>
 
99
100 <p>Send completed forms to:
101 <blockquote>
102 Hipp, Wyrick &amp; Company, Inc.<br>
103 6200 Maple Cove Lane<br>
104 Charlotte, NC 28269-1086<br>
105 USA
106 </p>
107
M www/fossil-v-git.wiki
+23 -23
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -19,11 +19,11 @@
1919
 wiki, tickets, or tech-notes, so those elements will not transfer when
2020
 exporting from Fossil to Git.</i></small>
2121
2222
 <h2>2.0 Executive Summary:</h2>
2323
24
-<blockquote><center><table border=1 cellpadding=5>
24
+<blockquote><table border=1 cellpadding=5 align=center>
2525
 <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr>
2626
 <tr><td>File versioning only</td>
2727
 <td>Versioning, Tickets, Wiki, and Technotes</td></tr>
2828
 <tr><td>Ad-hoc, pile-of-files key/value database</td>
2929
 <td>Relational SQL database</td></tr>
@@ -34,11 +34,11 @@
3434
 <tr><td>One check-out per repository</td>
3535
 <td>Many check-outs per repository</td></tr>
3636
 <tr><td>Remembers what you should have done</td>
3737
 <td>Remembers what you actually did</td></tr>
3838
 <tr><td>GPL</td><td>BSD</td></tr>
39
-</table></center></blockquote>
39
+</table></blockquote>
4040
4141
 <h2>3.0 Discussion</h2>
4242
4343
 <h3>3.1 Feature Set</h3>
4444
@@ -58,11 +58,11 @@
5858
5959
 For developers who choose to self-host projects (rather than using a
6060
 3rd-party service such as GitHub) Fossil is much easier to set up, since
6161
 the stand-alone Fossil executable together with a 2-line CGI script
6262
 suffice to instantiate a full-featured developer website. To accomplish
63
-the same using Git requires locating, installing, configuring, integrating,
63
+the same using Git requires locating, installing, configuring, integrating,
6464
 and managing a wide assortment of separate tools. Standing up a developer
6565
 website using Fossil can be done in minutes, whereas doing the same using
6666
 Git requires hours or days.
6767
6868
 <h3>3.2 Database</h3>
@@ -69,13 +69,13 @@
6969
7070
 The baseline data structures for Fossil and Git are the same (modulo
7171
 formatting details). Both systems store check-ins as immutable
7272
 objects referencing their immediate ancestors and named by their SHA1 hash.
7373
74
-The difference is that Git stores its objects as individual files
74
+The difference is that Git stores its objects as individual files
7575
 in the ".git" folder or compressed into
76
-bespoke "pack-files", whereas Fossil stores its objects in a
76
+bespoke "pack-files", whereas Fossil stores its objects in a
7777
 relational ([https://www.sqlite.org/|SQLite]) database file. To put it
7878
 another way, Git uses an ad-hoc pile-of-files key/value database whereas
7979
 Fossil uses a proven, general-purpose SQL database. This
8080
 difference is more than an implementation detail. It
8181
 has important consequences.
@@ -87,13 +87,13 @@
8787
 GitHub provide this capability. With Git, if you are looking at some
8888
 historical check-in then you cannot ask
8989
 "what came next" or "what are the children of this check-in".
9090
9191
 Fossil, on the other hand, parses essential information about check-ins
92
-(parents, children, committers, comments, files changed, etc.)
93
-into a relational database that can be easily
94
-queried using concise SQL statements to find both ancestors and
92
+(parents, children, committers, comments, files changed, etc.)
93
+into a relational database that can be easily
94
+queried using concise SQL statements to find both ancestors and
9595
 descendents of a check-in.
9696
9797
 Leaf check-ins in Git that lack a "ref" become "detached", making them
9898
 difficult to locate and subject to garbage collection. This
9999
 "detached head" problem has caused untold grief for countless
@@ -100,11 +100,11 @@
100100
 Git users. With Fossil, all check-ins are easily located using
101101
 a variety of attributes (parents, children, committer, date, full-text
102102
 search of the check-in comment) and so detached heads are simply not possible.
103103
104104
 The ease with which check-ins can be located and queried in Fossil
105
-has resulted in a huge variety of reports and status screens
105
+has resulted in a huge variety of reports and status screens
106106
 ([./webpage-ex.md|examples]) that show project state
107107
 in ways that help developers
108108
 maintain enhanced awareness and comprehension
109109
 and avoid errors.
110110
@@ -112,11 +112,11 @@
112112
113113
 Fossil and Git promote different development styles. Git promotes a
114114
 "bazaar" development style in which numerous anonymous developers make
115115
 small and sometimes haphazard contributions. Fossil
116116
 promotes a "cathedral" development model in which the project is
117
-closely supervised by an highly engaged architect and implemented by
117
+closely supervised by an highly engaged architect and implemented by
118118
 a clique of developers.
119119
120120
 Nota Bene: This is not to say that Git cannot be used for cathedral-style
121121
 development or that Fossil cannot be used for bazaar-style development.
122122
 They can be. But those modes are not their design intent nor the their
@@ -164,27 +164,27 @@
164164
 Git consists of many small tools, each doing one small part of the job,
165165
 which can be recombined (by experts) to perform powerful operations.
166166
 Git has a lot of complexity and many dependencies and requires an "installer"
167167
 script or program to get it running.
168168
169
-Fossil is a single self-contained stand-alone executable with hardly
170
-any dependencies. Fossil can be (and often is) run inside a
169
+Fossil is a single self-contained stand-alone executable with hardly
170
+any dependencies. Fossil can be (and often is) run inside a
171171
 minimally configured chroot jail. To install Fossil,
172172
 one merely puts the executable on $PATH.
173173
174
-The designer of Git says that the unix philosophy is to have lots of
175
-small tools that collaborate to get the job done. The designer of
176
-Fossil says that the unix philosophy is "it just works". Both
177
-individuals have written their DVCSes to reflect their own view
174
+The designer of Git says that the unix philosophy is to have lots of
175
+small tools that collaborate to get the job done. The designer of
176
+Fossil says that the unix philosophy is "it just works". Both
177
+individuals have written their DVCSes to reflect their own view
178178
 of the "unix philosophy".
179179
180180
 <h3>3.6 One vs. Many Check-outs per Repository</h3>
181181
182182
 A "repository" in Git is a pile-of-files in the ".git" subdirectory
183183
 of a single check-out. The check-out and the repository are inseperable.
184184
185
-With Fossil, a "repository" is a single SQLite database file
185
+With Fossil, a "repository" is a single SQLite database file
186186
 that can be stored anywhere. There
187187
 can be multiple active check-outs from the same repository, perhaps
188188
 open on different branches or on different snapshots of the same branch.
189189
 Long-running tests or builds can be running in one check-out while
190190
 changes are being committed in another.
@@ -201,27 +201,27 @@
201201
202202
 Fossil, in contrast, puts more emphasis on recording exactly what happened,
203203
 including all of the messy errors, dead-ends, experimental branches, and
204204
 so forth. One might argue that this
205205
 makes the history of a Fossil project "messy". But another point of view
206
-is that this makes the history "accurate". In actual practice, the
206
+is that this makes the history "accurate". In actual practice, the
207207
 superior reporting tools available in Fossil mean that the added "mess"
208208
 is not a factor.
209209
210210
 One commentator has mused that Git records history according to
211211
 the victors, whereas Fossil records history as it actually happened.
212212
213213
 <h3>3.8 GPL vs. BSD</h3>
214214
215
-Git is covered by the GPL license whereas Fossil is covered by
215
+Git is covered by the GPL license whereas Fossil is covered by
216216
 a two-clause BSD license.
217217
218218
 Consider the difference between GPL and BSD licenses: GPL is designed
219219
 to make writing easier at the expense of making reading harder. BSD is
220220
 designed to make reading easier and the expense of making writing harder.
221221
222
-To a first approximation, the GPL license grants the right to read
222
+To a first approximation, the GPL license grants the right to read
223223
 source code to anyone who promises to give back enhancements. In other
224224
 words, the act of reading GPL source code (a prerequiste for making changes)
225225
 implies acceptance of the license which requires updates to be contributed
226226
 back under the same license. (The details are more complex, but the
227227
 foregoing captures the essence of the idea.) A big advantage of the GPL
@@ -249,11 +249,11 @@
249249
 <h2>4.0 Missing Features</h2>
250250
251251
 Most of the capabilities found in Git are also available in Fossil and
252252
 the other way around. For example, both systems have local check-outs,
253253
 remote repositories, push/pull/sync, bisect capabilities, and a "stash".
254
-Both systems store project history as a directed acyclic graph (DAG)
254
+Both systems store project history as a directed acyclic graph (DAG)
255255
 of immutable check-in objects.
256256
257257
 But there are a few capabilities in one system that are missing from the
258258
 other.
259259
@@ -271,16 +271,16 @@
271271
 Git only provides versioning of source code. Fossil strives to provide
272272
 other related configuration management services as well.
273273
274274
 * <b>Named branches</b>
275275
276
- Branches in Fossil have persistent names that are propagated
276
+ Branches in Fossil have persistent names that are propagated
277277
 to collaborators via [/help?cmd=push|push] and [/help?cmd=pull|pull].
278278
 All developers see the same name on the same branch. Git, in contrast,
279279
 uses only local branch names, so developers working on the
280280
 same project can (and frequently do) use a different name for the
281
- same branch.
281
+ same branch.
282282
283283
 * <b>The [/help?cmd=all|fossil all] command</b>
284284
285285
 Fossil keeps track of all repositories and check-outs and allows
286286
 operations over all of them with a single command. For example, in
287287
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -19,11 +19,11 @@
19 wiki, tickets, or tech-notes, so those elements will not transfer when
20 exporting from Fossil to Git.</i></small>
21
22 <h2>2.0 Executive Summary:</h2>
23
24 <blockquote><center><table border=1 cellpadding=5>
25 <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr>
26 <tr><td>File versioning only</td>
27 <td>Versioning, Tickets, Wiki, and Technotes</td></tr>
28 <tr><td>Ad-hoc, pile-of-files key/value database</td>
29 <td>Relational SQL database</td></tr>
@@ -34,11 +34,11 @@
34 <tr><td>One check-out per repository</td>
35 <td>Many check-outs per repository</td></tr>
36 <tr><td>Remembers what you should have done</td>
37 <td>Remembers what you actually did</td></tr>
38 <tr><td>GPL</td><td>BSD</td></tr>
39 </table></center></blockquote>
40
41 <h2>3.0 Discussion</h2>
42
43 <h3>3.1 Feature Set</h3>
44
@@ -58,11 +58,11 @@
58
59 For developers who choose to self-host projects (rather than using a
60 3rd-party service such as GitHub) Fossil is much easier to set up, since
61 the stand-alone Fossil executable together with a 2-line CGI script
62 suffice to instantiate a full-featured developer website. To accomplish
63 the same using Git requires locating, installing, configuring, integrating,
64 and managing a wide assortment of separate tools. Standing up a developer
65 website using Fossil can be done in minutes, whereas doing the same using
66 Git requires hours or days.
67
68 <h3>3.2 Database</h3>
@@ -69,13 +69,13 @@
69
70 The baseline data structures for Fossil and Git are the same (modulo
71 formatting details). Both systems store check-ins as immutable
72 objects referencing their immediate ancestors and named by their SHA1 hash.
73
74 The difference is that Git stores its objects as individual files
75 in the ".git" folder or compressed into
76 bespoke "pack-files", whereas Fossil stores its objects in a
77 relational ([https://www.sqlite.org/|SQLite]) database file. To put it
78 another way, Git uses an ad-hoc pile-of-files key/value database whereas
79 Fossil uses a proven, general-purpose SQL database. This
80 difference is more than an implementation detail. It
81 has important consequences.
@@ -87,13 +87,13 @@
87 GitHub provide this capability. With Git, if you are looking at some
88 historical check-in then you cannot ask
89 "what came next" or "what are the children of this check-in".
90
91 Fossil, on the other hand, parses essential information about check-ins
92 (parents, children, committers, comments, files changed, etc.)
93 into a relational database that can be easily
94 queried using concise SQL statements to find both ancestors and
95 descendents of a check-in.
96
97 Leaf check-ins in Git that lack a "ref" become "detached", making them
98 difficult to locate and subject to garbage collection. This
99 "detached head" problem has caused untold grief for countless
@@ -100,11 +100,11 @@
100 Git users. With Fossil, all check-ins are easily located using
101 a variety of attributes (parents, children, committer, date, full-text
102 search of the check-in comment) and so detached heads are simply not possible.
103
104 The ease with which check-ins can be located and queried in Fossil
105 has resulted in a huge variety of reports and status screens
106 ([./webpage-ex.md|examples]) that show project state
107 in ways that help developers
108 maintain enhanced awareness and comprehension
109 and avoid errors.
110
@@ -112,11 +112,11 @@
112
113 Fossil and Git promote different development styles. Git promotes a
114 "bazaar" development style in which numerous anonymous developers make
115 small and sometimes haphazard contributions. Fossil
116 promotes a "cathedral" development model in which the project is
117 closely supervised by an highly engaged architect and implemented by
118 a clique of developers.
119
120 Nota Bene: This is not to say that Git cannot be used for cathedral-style
121 development or that Fossil cannot be used for bazaar-style development.
122 They can be. But those modes are not their design intent nor the their
@@ -164,27 +164,27 @@
164 Git consists of many small tools, each doing one small part of the job,
165 which can be recombined (by experts) to perform powerful operations.
166 Git has a lot of complexity and many dependencies and requires an "installer"
167 script or program to get it running.
168
169 Fossil is a single self-contained stand-alone executable with hardly
170 any dependencies. Fossil can be (and often is) run inside a
171 minimally configured chroot jail. To install Fossil,
172 one merely puts the executable on $PATH.
173
174 The designer of Git says that the unix philosophy is to have lots of
175 small tools that collaborate to get the job done. The designer of
176 Fossil says that the unix philosophy is "it just works". Both
177 individuals have written their DVCSes to reflect their own view
178 of the "unix philosophy".
179
180 <h3>3.6 One vs. Many Check-outs per Repository</h3>
181
182 A "repository" in Git is a pile-of-files in the ".git" subdirectory
183 of a single check-out. The check-out and the repository are inseperable.
184
185 With Fossil, a "repository" is a single SQLite database file
186 that can be stored anywhere. There
187 can be multiple active check-outs from the same repository, perhaps
188 open on different branches or on different snapshots of the same branch.
189 Long-running tests or builds can be running in one check-out while
190 changes are being committed in another.
@@ -201,27 +201,27 @@
201
202 Fossil, in contrast, puts more emphasis on recording exactly what happened,
203 including all of the messy errors, dead-ends, experimental branches, and
204 so forth. One might argue that this
205 makes the history of a Fossil project "messy". But another point of view
206 is that this makes the history "accurate". In actual practice, the
207 superior reporting tools available in Fossil mean that the added "mess"
208 is not a factor.
209
210 One commentator has mused that Git records history according to
211 the victors, whereas Fossil records history as it actually happened.
212
213 <h3>3.8 GPL vs. BSD</h3>
214
215 Git is covered by the GPL license whereas Fossil is covered by
216 a two-clause BSD license.
217
218 Consider the difference between GPL and BSD licenses: GPL is designed
219 to make writing easier at the expense of making reading harder. BSD is
220 designed to make reading easier and the expense of making writing harder.
221
222 To a first approximation, the GPL license grants the right to read
223 source code to anyone who promises to give back enhancements. In other
224 words, the act of reading GPL source code (a prerequiste for making changes)
225 implies acceptance of the license which requires updates to be contributed
226 back under the same license. (The details are more complex, but the
227 foregoing captures the essence of the idea.) A big advantage of the GPL
@@ -249,11 +249,11 @@
249 <h2>4.0 Missing Features</h2>
250
251 Most of the capabilities found in Git are also available in Fossil and
252 the other way around. For example, both systems have local check-outs,
253 remote repositories, push/pull/sync, bisect capabilities, and a "stash".
254 Both systems store project history as a directed acyclic graph (DAG)
255 of immutable check-in objects.
256
257 But there are a few capabilities in one system that are missing from the
258 other.
259
@@ -271,16 +271,16 @@
271 Git only provides versioning of source code. Fossil strives to provide
272 other related configuration management services as well.
273
274 * <b>Named branches</b>
275
276 Branches in Fossil have persistent names that are propagated
277 to collaborators via [/help?cmd=push|push] and [/help?cmd=pull|pull].
278 All developers see the same name on the same branch. Git, in contrast,
279 uses only local branch names, so developers working on the
280 same project can (and frequently do) use a different name for the
281 same branch.
282
283 * <b>The [/help?cmd=all|fossil all] command</b>
284
285 Fossil keeps track of all repositories and check-outs and allows
286 operations over all of them with a single command. For example, in
287
--- www/fossil-v-git.wiki
+++ www/fossil-v-git.wiki
@@ -19,11 +19,11 @@
19 wiki, tickets, or tech-notes, so those elements will not transfer when
20 exporting from Fossil to Git.</i></small>
21
22 <h2>2.0 Executive Summary:</h2>
23
24 <blockquote><table border=1 cellpadding=5 align=center>
25 <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr>
26 <tr><td>File versioning only</td>
27 <td>Versioning, Tickets, Wiki, and Technotes</td></tr>
28 <tr><td>Ad-hoc, pile-of-files key/value database</td>
29 <td>Relational SQL database</td></tr>
@@ -34,11 +34,11 @@
34 <tr><td>One check-out per repository</td>
35 <td>Many check-outs per repository</td></tr>
36 <tr><td>Remembers what you should have done</td>
37 <td>Remembers what you actually did</td></tr>
38 <tr><td>GPL</td><td>BSD</td></tr>
39 </table></blockquote>
40
41 <h2>3.0 Discussion</h2>
42
43 <h3>3.1 Feature Set</h3>
44
@@ -58,11 +58,11 @@
58
59 For developers who choose to self-host projects (rather than using a
60 3rd-party service such as GitHub) Fossil is much easier to set up, since
61 the stand-alone Fossil executable together with a 2-line CGI script
62 suffice to instantiate a full-featured developer website. To accomplish
63 the same using Git requires locating, installing, configuring, integrating,
64 and managing a wide assortment of separate tools. Standing up a developer
65 website using Fossil can be done in minutes, whereas doing the same using
66 Git requires hours or days.
67
68 <h3>3.2 Database</h3>
@@ -69,13 +69,13 @@
69
70 The baseline data structures for Fossil and Git are the same (modulo
71 formatting details). Both systems store check-ins as immutable
72 objects referencing their immediate ancestors and named by their SHA1 hash.
73
74 The difference is that Git stores its objects as individual files
75 in the ".git" folder or compressed into
76 bespoke "pack-files", whereas Fossil stores its objects in a
77 relational ([https://www.sqlite.org/|SQLite]) database file. To put it
78 another way, Git uses an ad-hoc pile-of-files key/value database whereas
79 Fossil uses a proven, general-purpose SQL database. This
80 difference is more than an implementation detail. It
81 has important consequences.
@@ -87,13 +87,13 @@
87 GitHub provide this capability. With Git, if you are looking at some
88 historical check-in then you cannot ask
89 "what came next" or "what are the children of this check-in".
90
91 Fossil, on the other hand, parses essential information about check-ins
92 (parents, children, committers, comments, files changed, etc.)
93 into a relational database that can be easily
94 queried using concise SQL statements to find both ancestors and
95 descendents of a check-in.
96
97 Leaf check-ins in Git that lack a "ref" become "detached", making them
98 difficult to locate and subject to garbage collection. This
99 "detached head" problem has caused untold grief for countless
@@ -100,11 +100,11 @@
100 Git users. With Fossil, all check-ins are easily located using
101 a variety of attributes (parents, children, committer, date, full-text
102 search of the check-in comment) and so detached heads are simply not possible.
103
104 The ease with which check-ins can be located and queried in Fossil
105 has resulted in a huge variety of reports and status screens
106 ([./webpage-ex.md|examples]) that show project state
107 in ways that help developers
108 maintain enhanced awareness and comprehension
109 and avoid errors.
110
@@ -112,11 +112,11 @@
112
113 Fossil and Git promote different development styles. Git promotes a
114 "bazaar" development style in which numerous anonymous developers make
115 small and sometimes haphazard contributions. Fossil
116 promotes a "cathedral" development model in which the project is
117 closely supervised by an highly engaged architect and implemented by
118 a clique of developers.
119
120 Nota Bene: This is not to say that Git cannot be used for cathedral-style
121 development or that Fossil cannot be used for bazaar-style development.
122 They can be. But those modes are not their design intent nor the their
@@ -164,27 +164,27 @@
164 Git consists of many small tools, each doing one small part of the job,
165 which can be recombined (by experts) to perform powerful operations.
166 Git has a lot of complexity and many dependencies and requires an "installer"
167 script or program to get it running.
168
169 Fossil is a single self-contained stand-alone executable with hardly
170 any dependencies. Fossil can be (and often is) run inside a
171 minimally configured chroot jail. To install Fossil,
172 one merely puts the executable on $PATH.
173
174 The designer of Git says that the unix philosophy is to have lots of
175 small tools that collaborate to get the job done. The designer of
176 Fossil says that the unix philosophy is "it just works". Both
177 individuals have written their DVCSes to reflect their own view
178 of the "unix philosophy".
179
180 <h3>3.6 One vs. Many Check-outs per Repository</h3>
181
182 A "repository" in Git is a pile-of-files in the ".git" subdirectory
183 of a single check-out. The check-out and the repository are inseperable.
184
185 With Fossil, a "repository" is a single SQLite database file
186 that can be stored anywhere. There
187 can be multiple active check-outs from the same repository, perhaps
188 open on different branches or on different snapshots of the same branch.
189 Long-running tests or builds can be running in one check-out while
190 changes are being committed in another.
@@ -201,27 +201,27 @@
201
202 Fossil, in contrast, puts more emphasis on recording exactly what happened,
203 including all of the messy errors, dead-ends, experimental branches, and
204 so forth. One might argue that this
205 makes the history of a Fossil project "messy". But another point of view
206 is that this makes the history "accurate". In actual practice, the
207 superior reporting tools available in Fossil mean that the added "mess"
208 is not a factor.
209
210 One commentator has mused that Git records history according to
211 the victors, whereas Fossil records history as it actually happened.
212
213 <h3>3.8 GPL vs. BSD</h3>
214
215 Git is covered by the GPL license whereas Fossil is covered by
216 a two-clause BSD license.
217
218 Consider the difference between GPL and BSD licenses: GPL is designed
219 to make writing easier at the expense of making reading harder. BSD is
220 designed to make reading easier and the expense of making writing harder.
221
222 To a first approximation, the GPL license grants the right to read
223 source code to anyone who promises to give back enhancements. In other
224 words, the act of reading GPL source code (a prerequiste for making changes)
225 implies acceptance of the license which requires updates to be contributed
226 back under the same license. (The details are more complex, but the
227 foregoing captures the essence of the idea.) A big advantage of the GPL
@@ -249,11 +249,11 @@
249 <h2>4.0 Missing Features</h2>
250
251 Most of the capabilities found in Git are also available in Fossil and
252 the other way around. For example, both systems have local check-outs,
253 remote repositories, push/pull/sync, bisect capabilities, and a "stash".
254 Both systems store project history as a directed acyclic graph (DAG)
255 of immutable check-in objects.
256
257 But there are a few capabilities in one system that are missing from the
258 other.
259
@@ -271,16 +271,16 @@
271 Git only provides versioning of source code. Fossil strives to provide
272 other related configuration management services as well.
273
274 * <b>Named branches</b>
275
276 Branches in Fossil have persistent names that are propagated
277 to collaborators via [/help?cmd=push|push] and [/help?cmd=pull|pull].
278 All developers see the same name on the same branch. Git, in contrast,
279 uses only local branch names, so developers working on the
280 same project can (and frequently do) use a different name for the
281 same branch.
282
283 * <b>The [/help?cmd=all|fossil all] command</b>
284
285 Fossil keeps track of all repositories and check-outs and allows
286 operations over all of them with a single command. For example, in
287
M www/index.wiki
+1 -1
--- www/index.wiki
+++ www/index.wiki
@@ -18,11 +18,11 @@
1818
 <ul>
1919
 <li> [http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-users | sign-up]
2020
 <li> [http://www.mail-archive.com/[email protected] | archives]
2121
 </ul>
2222
 </ul>
23
-<center><img src="fossil3.gif"></center>
23
+<img src="fossil3.gif" align="center">
2424
 </div>
2525
2626
 <p>Fossil is a simple, high-reliability, distributed software configuration
2727
 management system with these advanced features:
2828
2929
--- www/index.wiki
+++ www/index.wiki
@@ -18,11 +18,11 @@
18 <ul>
19 <li> [http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-users | sign-up]
20 <li> [http://www.mail-archive.com/[email protected] | archives]
21 </ul>
22 </ul>
23 <center><img src="fossil3.gif"></center>
24 </div>
25
26 <p>Fossil is a simple, high-reliability, distributed software configuration
27 management system with these advanced features:
28
29
--- www/index.wiki
+++ www/index.wiki
@@ -18,11 +18,11 @@
18 <ul>
19 <li> [http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-users | sign-up]
20 <li> [http://www.mail-archive.com/[email protected] | archives]
21 </ul>
22 </ul>
23 <img src="fossil3.gif" align="center">
24 </div>
25
26 <p>Fossil is a simple, high-reliability, distributed software configuration
27 management system with these advanced features:
28
29
M www/sync.wiki
+9 -9
--- www/sync.wiki
+++ www/sync.wiki
@@ -15,11 +15,11 @@
1515
 Synchronization is simply the process of sharing artifacts between
1616
 servers so that all servers have copies of all artifacts. Because
1717
 artifacts are unordered, the order in which artifacts are received
1818
 at a server is inconsequential. It is assumed that the SHA1 hashes
1919
 of artifacts are unique - that every artifact has a different SHA1 hash.
20
-To a first approximation, synchronization proceeds by sharing lists
20
+To a first approximation, synchronization proceeds by sharing lists
2121
 SHA1 hashes of available artifacts, then sharing those artifacts that
2222
 are not found on one side or the other of the connection. In practice,
2323
 a repository might contain millions of artifacts. The list of
2424
 SHA1 hashes for this many artifacts can be large. So optimizations are
2525
 employed that usually reduce the number of SHA1 hashes that need to be
@@ -150,11 +150,11 @@
150150
 terminates the login card. The signature is the SHA1 hash of
151151
 the concatenation of the nonce and the users password.</p>
152152
153153
 <p>For each login card, the server looks up the user and verifies
154154
 that the nonce matches the SHA1 hash of the remainder of the
155
-message. It then checks the signature hash to make sure the
155
+message. It then checks the signature hash to make sure the
156156
 signature matches. If everything
157157
 checks out, then the client is granted all privileges of the
158158
 specified user.</p>
159159
160160
 <p>Privileges are cumulative. There can be multiple successful
@@ -162,11 +162,11 @@
162162
 privileges of each individual login.</p>
163163
164164
 <h3>3.3 File and Compressed File Cards</h3>
165165
166166
 <p>Artifacts are transferred using either "file" cards, or "cfile" cards.
167
-(The name "file" card comes from the fact that most artifacts correspond to
167
+(The name "file" card comes from the fact that most artifacts correspond to
168168
 files, and "cfile" is just a compressed file.)
169169
 </p>
170170
171171
 <h4>3.3.1 File Cards</h4>
172172
@@ -230,11 +230,11 @@
230230
 artifact. If the cfile card has four arguments, then the payload is a
231231
 delta and the second argument is the ID of another artifact that is the
232232
 source of the delta and the third argument is the original size of the
233233
 delta artifact.</p>
234234
235
-<p>Unlike file cards, cfile cards are only sent in one direction during a
235
+<p>Unlike file cards, cfile cards are only sent in one direction during a
236236
 clone from server to client for clone protocol version "3" or greater.</p>
237237
238238
 <h3>3.4 Push and Pull Cards</h3>
239239
240240
 <p>Among the first cards in a client-to-server message are
@@ -385,11 +385,11 @@
385385
 </blockquote>
386386
387387
 <p>As of [/timeline?r=trunk&c=2015-03-19+03%3A57%3A46&n=20|2015-03-19], the configuration-name must be one of the
388388
 following values:
389389
390
-<center><table border=0>
390
+<table border=0 align="center">
391391
 <tr><td valign="top">
392392
 <ul>
393393
 <li> css
394394
 <li> header
395395
 <li> footer
@@ -436,11 +436,11 @@
436436
 <li> @reportfmt
437437
 <li> @user
438438
 <li> @concealed
439439
 <li> @shun
440440
 </ul></td></tr>
441
-</table></center>
441
+</table>
442442
443443
 <p>New configuration-names are likely to be added in future releases of
444444
 Fossil. If the server receives a configuration-name that it does not
445445
 understand, the entire reqconfig card is silently ignored. The reqconfig
446446
 card might also be ignored if the user lacks sufficient privilege to
@@ -453,11 +453,11 @@
453453
 The value of the configuration item is returned to the client using a
454454
 "config" card.
455455
456456
 <p>If the configuration-name begins with "@", that refers to a class of
457457
 values instead of a single value. The content of these configuration items
458
-is returned in a "config" card that contains pure SQL text that is
458
+is returned in a "config" card that contains pure SQL text that is
459459
 intended to be evaluated by the client.
460460
461461
 <p>The @user and @concealed configuration items contain sensitive information
462462
 and are ignored for clients without sufficient privilege.
463463
@@ -491,11 +491,11 @@
491491
 </blockquote>
492492
493493
 <p>The error message is English text that is encoded in order to
494494
 be a single token.
495495
 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
496
-newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
496
+newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
497497
 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
498498
 space and newline, no other whitespace characters nor any
499499
 unprintable characters are allowed in
500500
 the error message.</p>
501501
@@ -658,11 +658,11 @@
658658
 <ol>
659659
 <li>The client sends one or more PUSH HTTP requests to the server.
660660
 The request and reply content type is "application/x-fossil".
661661
 <li>HTTP request content is compressed using zlib.
662662
 <li>The content of request and reply consists of cards with one
663
- card per line.
663
+ card per line.
664664
 <li>Card formats are:
665665
 <ul>
666666
 <li> <b>login</b> <i>userid nonce signature</i>
667667
 <li> <b>push</b> <i>servercode projectcode</i>
668668
 <li> <b>pull</b> <i>servercode projectcode</i>
669669
--- www/sync.wiki
+++ www/sync.wiki
@@ -15,11 +15,11 @@
15 Synchronization is simply the process of sharing artifacts between
16 servers so that all servers have copies of all artifacts. Because
17 artifacts are unordered, the order in which artifacts are received
18 at a server is inconsequential. It is assumed that the SHA1 hashes
19 of artifacts are unique - that every artifact has a different SHA1 hash.
20 To a first approximation, synchronization proceeds by sharing lists
21 SHA1 hashes of available artifacts, then sharing those artifacts that
22 are not found on one side or the other of the connection. In practice,
23 a repository might contain millions of artifacts. The list of
24 SHA1 hashes for this many artifacts can be large. So optimizations are
25 employed that usually reduce the number of SHA1 hashes that need to be
@@ -150,11 +150,11 @@
150 terminates the login card. The signature is the SHA1 hash of
151 the concatenation of the nonce and the users password.</p>
152
153 <p>For each login card, the server looks up the user and verifies
154 that the nonce matches the SHA1 hash of the remainder of the
155 message. It then checks the signature hash to make sure the
156 signature matches. If everything
157 checks out, then the client is granted all privileges of the
158 specified user.</p>
159
160 <p>Privileges are cumulative. There can be multiple successful
@@ -162,11 +162,11 @@
162 privileges of each individual login.</p>
163
164 <h3>3.3 File and Compressed File Cards</h3>
165
166 <p>Artifacts are transferred using either "file" cards, or "cfile" cards.
167 (The name "file" card comes from the fact that most artifacts correspond to
168 files, and "cfile" is just a compressed file.)
169 </p>
170
171 <h4>3.3.1 File Cards</h4>
172
@@ -230,11 +230,11 @@
230 artifact. If the cfile card has four arguments, then the payload is a
231 delta and the second argument is the ID of another artifact that is the
232 source of the delta and the third argument is the original size of the
233 delta artifact.</p>
234
235 <p>Unlike file cards, cfile cards are only sent in one direction during a
236 clone from server to client for clone protocol version "3" or greater.</p>
237
238 <h3>3.4 Push and Pull Cards</h3>
239
240 <p>Among the first cards in a client-to-server message are
@@ -385,11 +385,11 @@
385 </blockquote>
386
387 <p>As of [/timeline?r=trunk&c=2015-03-19+03%3A57%3A46&n=20|2015-03-19], the configuration-name must be one of the
388 following values:
389
390 <center><table border=0>
391 <tr><td valign="top">
392 <ul>
393 <li> css
394 <li> header
395 <li> footer
@@ -436,11 +436,11 @@
436 <li> @reportfmt
437 <li> @user
438 <li> @concealed
439 <li> @shun
440 </ul></td></tr>
441 </table></center>
442
443 <p>New configuration-names are likely to be added in future releases of
444 Fossil. If the server receives a configuration-name that it does not
445 understand, the entire reqconfig card is silently ignored. The reqconfig
446 card might also be ignored if the user lacks sufficient privilege to
@@ -453,11 +453,11 @@
453 The value of the configuration item is returned to the client using a
454 "config" card.
455
456 <p>If the configuration-name begins with "@", that refers to a class of
457 values instead of a single value. The content of these configuration items
458 is returned in a "config" card that contains pure SQL text that is
459 intended to be evaluated by the client.
460
461 <p>The @user and @concealed configuration items contain sensitive information
462 and are ignored for clients without sufficient privilege.
463
@@ -491,11 +491,11 @@
491 </blockquote>
492
493 <p>The error message is English text that is encoded in order to
494 be a single token.
495 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
496 newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
497 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
498 space and newline, no other whitespace characters nor any
499 unprintable characters are allowed in
500 the error message.</p>
501
@@ -658,11 +658,11 @@
658 <ol>
659 <li>The client sends one or more PUSH HTTP requests to the server.
660 The request and reply content type is "application/x-fossil".
661 <li>HTTP request content is compressed using zlib.
662 <li>The content of request and reply consists of cards with one
663 card per line.
664 <li>Card formats are:
665 <ul>
666 <li> <b>login</b> <i>userid nonce signature</i>
667 <li> <b>push</b> <i>servercode projectcode</i>
668 <li> <b>pull</b> <i>servercode projectcode</i>
669
--- www/sync.wiki
+++ www/sync.wiki
@@ -15,11 +15,11 @@
15 Synchronization is simply the process of sharing artifacts between
16 servers so that all servers have copies of all artifacts. Because
17 artifacts are unordered, the order in which artifacts are received
18 at a server is inconsequential. It is assumed that the SHA1 hashes
19 of artifacts are unique - that every artifact has a different SHA1 hash.
20 To a first approximation, synchronization proceeds by sharing lists
21 SHA1 hashes of available artifacts, then sharing those artifacts that
22 are not found on one side or the other of the connection. In practice,
23 a repository might contain millions of artifacts. The list of
24 SHA1 hashes for this many artifacts can be large. So optimizations are
25 employed that usually reduce the number of SHA1 hashes that need to be
@@ -150,11 +150,11 @@
150 terminates the login card. The signature is the SHA1 hash of
151 the concatenation of the nonce and the users password.</p>
152
153 <p>For each login card, the server looks up the user and verifies
154 that the nonce matches the SHA1 hash of the remainder of the
155 message. It then checks the signature hash to make sure the
156 signature matches. If everything
157 checks out, then the client is granted all privileges of the
158 specified user.</p>
159
160 <p>Privileges are cumulative. There can be multiple successful
@@ -162,11 +162,11 @@
162 privileges of each individual login.</p>
163
164 <h3>3.3 File and Compressed File Cards</h3>
165
166 <p>Artifacts are transferred using either "file" cards, or "cfile" cards.
167 (The name "file" card comes from the fact that most artifacts correspond to
168 files, and "cfile" is just a compressed file.)
169 </p>
170
171 <h4>3.3.1 File Cards</h4>
172
@@ -230,11 +230,11 @@
230 artifact. If the cfile card has four arguments, then the payload is a
231 delta and the second argument is the ID of another artifact that is the
232 source of the delta and the third argument is the original size of the
233 delta artifact.</p>
234
235 <p>Unlike file cards, cfile cards are only sent in one direction during a
236 clone from server to client for clone protocol version "3" or greater.</p>
237
238 <h3>3.4 Push and Pull Cards</h3>
239
240 <p>Among the first cards in a client-to-server message are
@@ -385,11 +385,11 @@
385 </blockquote>
386
387 <p>As of [/timeline?r=trunk&c=2015-03-19+03%3A57%3A46&n=20|2015-03-19], the configuration-name must be one of the
388 following values:
389
390 <table border=0 align="center">
391 <tr><td valign="top">
392 <ul>
393 <li> css
394 <li> header
395 <li> footer
@@ -436,11 +436,11 @@
436 <li> @reportfmt
437 <li> @user
438 <li> @concealed
439 <li> @shun
440 </ul></td></tr>
441 </table>
442
443 <p>New configuration-names are likely to be added in future releases of
444 Fossil. If the server receives a configuration-name that it does not
445 understand, the entire reqconfig card is silently ignored. The reqconfig
446 card might also be ignored if the user lacks sufficient privilege to
@@ -453,11 +453,11 @@
453 The value of the configuration item is returned to the client using a
454 "config" card.
455
456 <p>If the configuration-name begins with "@", that refers to a class of
457 values instead of a single value. The content of these configuration items
458 is returned in a "config" card that contains pure SQL text that is
459 intended to be evaluated by the client.
460
461 <p>The @user and @concealed configuration items contain sensitive information
462 and are ignored for clients without sufficient privilege.
463
@@ -491,11 +491,11 @@
491 </blockquote>
492
493 <p>The error message is English text that is encoded in order to
494 be a single token.
495 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
496 newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
497 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
498 space and newline, no other whitespace characters nor any
499 unprintable characters are allowed in
500 the error message.</p>
501
@@ -658,11 +658,11 @@
658 <ol>
659 <li>The client sends one or more PUSH HTTP requests to the server.
660 The request and reply content type is "application/x-fossil".
661 <li>HTTP request content is compressed using zlib.
662 <li>The content of request and reply consists of cards with one
663 card per line.
664 <li>Card formats are:
665 <ul>
666 <li> <b>login</b> <i>userid nonce signature</i>
667 <li> <b>push</b> <i>servercode projectcode</i>
668 <li> <b>pull</b> <i>servercode projectcode</i>
669
M www/tech_overview.wiki
+18 -19
--- www/tech_overview.wiki
+++ www/tech_overview.wiki
@@ -5,12 +5,12 @@
55
66
 <h2>1.0 Introduction</h2>
77
88
 At its lowest level, a Fossil repository consists of an unordered set
99
 of immutable "artifacts". You might think of these artifacts as "files",
10
-since in many cases the artifacts are exactly that.
11
-But other "control artifacts"
10
+since in many cases the artifacts are exactly that.
11
+But other "control artifacts"
1212
 are also included in the mix. These control artifacts define the relationships
1313
 between artifacts - which files go together to form a particular
1414
 version of the project, who checked in that version and when, what was
1515
 the check-in comment, what wiki pages are included with the project, what
1616
 are the edit histories of each wiki page, what bug reports or tickets are
@@ -17,21 +17,21 @@
1717
 included, who contributed to the evolution of each ticket, and so forth.
1818
 This low-level file format is called the "global state" of
1919
 the repository, since this is the information that is synced to peer
2020
 repositories using push and pull operations. The low-level file format
2121
 is also called "enduring" since it is intended to last for many years.
22
-The details of the low-level, enduring, global file format
22
+The details of the low-level, enduring, global file format
2323
 are [./fileformat.wiki | described separately].
2424
2525
 This article is about how Fossil is currently implemented. Instead of
2626
 dealing with vague abstractions of "enduring file formats" as the
2727
 [./fileformat.wiki | other document] does, this article provides
28
-some detail on how Fossil actually stores information on disk.
28
+some detail on how Fossil actually stores information on disk.
2929
3030
 <h2>2.0 Three Databases</h2>
3131
32
-Fossil stores state information in
32
+Fossil stores state information in
3333
 [http://www.sqlite.org/ | SQLite] database files.
3434
 SQLite keeps an entire relational database, including multiple tables and
3535
 indices, in a single disk file. The SQLite library allows the database
3636
 files to be efficiently queried and updated using the industry-standard
3737
 SQL language. SQLite updates are atomic, so even in the event of
@@ -46,11 +46,11 @@
4646
 </ol>
4747
4848
 The configuration database is a one-per-user database that holds
4949
 global configuration information used by Fossil. There is one
5050
 repository database per project. The repository database is the
51
-file that people are normally referring to when they say
51
+file that people are normally referring to when they say
5252
 "a Fossil repository". The checkout database is found in the working
5353
 checkout for a project and contains state information that is unique
5454
 to that working checkout.
5555
5656
 Fossil does not always use all three database files. The web interface,
@@ -65,11 +65,11 @@
6565
 SQLite's [http://www.sqlite.org/lang_attach.html | ATTACH] command.
6666
6767
 The chart below provides a quick summary of how each of these
6868
 database files are used by Fossil, with detailed discussion following.
6969
70
-<center><table border="1" width="80%" cellpadding="0">
70
+<table border="1" width="80%" cellpadding="0" align="center">
7171
 <tr>
7272
 <td width="33%" valign="top">
7373
 <h3 align="center">Configuration Database<br>"~/.fossil"</h3>
7474
 <ul>
7575
 <li>Global [/help/setting |settings]
@@ -103,11 +103,10 @@
103103
 <li>Information needed to "[/help/undo|undo]" or "[/help/redo|redo]"
104104
 </ul>
105105
 </td>
106106
 </tr>
107107
 </table>
108
-</center>
109108
110109
 <h3>2.1 The Configuration Database</h3>
111110
112111
 The configuration database holds cross-repository preferences and a list of all
113112
 repositories for a single user.
@@ -135,11 +134,11 @@
135134
 You can override this default location by defining the environment
136135
 variable FOSSIL_HOME pointing to an appropriate (writable) directory.
137136
138137
 <h3>2.2 Repository Databases</h3>
139138
140
-The repository database is the file that is commonly referred to as
139
+The repository database is the file that is commonly referred to as
141140
 "the repository". This is because the repository database contains,
142141
 among other things, the complete revision, ticket, and wiki history for
143142
 a project. It is customary to name the repository database after then
144143
 name of the project, with a ".fossil" suffix. For example, the repository
145144
 database for the self-hosting Fossil repository is called "fossil.fossil"
@@ -146,11 +145,11 @@
146145
 and the repository database for SQLite is called "sqlite.fossil".
147146
148147
 <h4>2.2.1 Global Project State</h4>
149148
150149
 The bulk of the repository database (typically 75 to 85%) consists
151
-of the artifacts that comprise the
150
+of the artifacts that comprise the
152151
 [./fileformat.wiki | enduring, global, shared state] of the project.
153152
 The artifacts are stored as BLOBs, compressed using
154153
 [http://www.zlib.net/ | zlib compression] and, where applicable,
155154
 using [./delta_encoder_algorithm.wiki | delta compression].
156155
 The combination of zlib and delta compression results in a considerable
@@ -160,26 +159,26 @@
160159
 32 MB of space in the repository database, for a compression ratio
161160
 of about 64:1. The average size of a content BLOB in the database
162161
 is around 500 bytes.
163162
164163
 Note that the zlib and delta compression is not an inherent part of the
165
-Fossil file format; it is just an optimization.
164
+Fossil file format; it is just an optimization.
166165
 The enduring file format for Fossil is the unordered
167166
 set of artifacts. The compression techniques are just a detail of
168167
 how the current implementation of Fossil happens to store these artifacts
169168
 efficiently on disk.
170169
171170
 All of the original uncompressed and undeltaed artifacts can be extracted
172
-from a Fossil repository database using
171
+from a Fossil repository database using
173172
 the [/help/deconstruct | fossil deconstruct]
174173
 command. Individual artifacts can be extracted using the
175174
 [/help/artifact | fossil artifact] command.
176175
 When accessing the repository database using raw SQL and the
177176
 [/help/sqlite3 | fossil sql] command, the extension function
178177
 "<tt>content()</tt>" with a single argument which is the SHA1 hash
179178
 of an artifact will return the complete undeleted and uncompressed
180
-content of that artifact.
179
+content of that artifact.
181180
182181
 Going the other way, the [/help/reconstruct | fossil reconstruct]
183182
 command will scan a directory hierarchy and add all files found to
184183
 a new repository database. The [/help/import | fossil import] command
185184
 works by reading the input git-fast-export stream and using it to construct
@@ -225,11 +224,11 @@
225224
 by [/help/sync | fossil sync]. That is because it is entirely reasonable
226225
 that two different websites for the same project might have completely
227226
 different display preferences and user communities. One instance of the
228227
 project might be a fork of the other, for example, which pulls from the
229228
 other but never pushes and extends the project in ways that the keepers of
230
-the other website disapprove of.
229
+the other website disapprove of.
231230
232231
 Display and processing information includes the following:
233232
234233
 * The name and description of the project
235234
 * The CSS file, header, and footer used by all web pages
@@ -242,31 +241,31 @@
242241
 global values defined in the per-user configuration database.
243242
244243
 Though the display and processing preferences do not move between
245244
 repository instances using [/help/sync | fossil sync], this information
246245
 can be shared between repositories using the
247
-[/help/config | fossil config push] and
246
+[/help/config | fossil config push] and
248247
 [/help/config | fossil config pull] commands.
249248
 The display and processing information is also copied into new
250249
 repositories when they are created using
251250
 [/help/clone | fossil clone].
252251
253252
 <h4>2.2.4 User Credentials And Privileges</h4>
254253
255254
 Just because two development teams are collaborating on a project and allow
256
-push and/or pull between their repositories does not mean that they
255
+push and/or pull between their repositories does not mean that they
257256
 trust each other enough to share passwords and access privileges.
258257
 Hence the names and emails and passwords and privileges of users are
259258
 considered private information that is kept locally in each repository.
260259
261260
 Each repository database has a table holding the username, privileges,
262261
 and login credentials for users authorized to interact with that particular
263
-database. In addition, there is a table named "concealed" that maps the
262
+database. In addition, there is a table named "concealed" that maps the
264263
 SHA1 hash of each users email address back into their true email address.
265264
 The concealed table allows just the SHA1 hash of email addresses to
266265
 be stored in tickets, and thus prevents actual email addresses from falling
267
-into the hands of spammers who happen to clone the repository.
266
+into the hands of spammers who happen to clone the repository.
268267
269268
 The content of the user and concealed tables can be pushed and pulled using the
270269
 [/help/config | fossil config push] and
271270
 [/help/config | fossil config pull] commands with the "user" and
272271
 "email" as the AREA argument, but only if you have administrative
@@ -278,11 +277,11 @@
278277
 project - is intended to be an append-only database. In other words,
279278
 new artifacts can be added but artifacts can never be removed. But
280279
 it sometimes happens that inappropriate content is mistakenly or
281280
 maliciously added to a repository. The only way to get rid of
282281
 the undesired content is to [./shunning.wiki | "shun"] it.
283
-The "shun" table in the repository database records the SHA1 hash of
282
+The "shun" table in the repository database records the SHA1 hash of
284283
 all shunned artifacts.
285284
286285
 The shun table can be pushed or pulled using
287286
 the [/help/config | fossil config] command with the "shun" AREA argument.
288287
 The shun table is also copied during a [/help/clone | clone].
289288
--- www/tech_overview.wiki
+++ www/tech_overview.wiki
@@ -5,12 +5,12 @@
5
6 <h2>1.0 Introduction</h2>
7
8 At its lowest level, a Fossil repository consists of an unordered set
9 of immutable "artifacts". You might think of these artifacts as "files",
10 since in many cases the artifacts are exactly that.
11 But other "control artifacts"
12 are also included in the mix. These control artifacts define the relationships
13 between artifacts - which files go together to form a particular
14 version of the project, who checked in that version and when, what was
15 the check-in comment, what wiki pages are included with the project, what
16 are the edit histories of each wiki page, what bug reports or tickets are
@@ -17,21 +17,21 @@
17 included, who contributed to the evolution of each ticket, and so forth.
18 This low-level file format is called the "global state" of
19 the repository, since this is the information that is synced to peer
20 repositories using push and pull operations. The low-level file format
21 is also called "enduring" since it is intended to last for many years.
22 The details of the low-level, enduring, global file format
23 are [./fileformat.wiki | described separately].
24
25 This article is about how Fossil is currently implemented. Instead of
26 dealing with vague abstractions of "enduring file formats" as the
27 [./fileformat.wiki | other document] does, this article provides
28 some detail on how Fossil actually stores information on disk.
29
30 <h2>2.0 Three Databases</h2>
31
32 Fossil stores state information in
33 [http://www.sqlite.org/ | SQLite] database files.
34 SQLite keeps an entire relational database, including multiple tables and
35 indices, in a single disk file. The SQLite library allows the database
36 files to be efficiently queried and updated using the industry-standard
37 SQL language. SQLite updates are atomic, so even in the event of
@@ -46,11 +46,11 @@
46 </ol>
47
48 The configuration database is a one-per-user database that holds
49 global configuration information used by Fossil. There is one
50 repository database per project. The repository database is the
51 file that people are normally referring to when they say
52 "a Fossil repository". The checkout database is found in the working
53 checkout for a project and contains state information that is unique
54 to that working checkout.
55
56 Fossil does not always use all three database files. The web interface,
@@ -65,11 +65,11 @@
65 SQLite's [http://www.sqlite.org/lang_attach.html | ATTACH] command.
66
67 The chart below provides a quick summary of how each of these
68 database files are used by Fossil, with detailed discussion following.
69
70 <center><table border="1" width="80%" cellpadding="0">
71 <tr>
72 <td width="33%" valign="top">
73 <h3 align="center">Configuration Database<br>"~/.fossil"</h3>
74 <ul>
75 <li>Global [/help/setting |settings]
@@ -103,11 +103,10 @@
103 <li>Information needed to "[/help/undo|undo]" or "[/help/redo|redo]"
104 </ul>
105 </td>
106 </tr>
107 </table>
108 </center>
109
110 <h3>2.1 The Configuration Database</h3>
111
112 The configuration database holds cross-repository preferences and a list of all
113 repositories for a single user.
@@ -135,11 +134,11 @@
135 You can override this default location by defining the environment
136 variable FOSSIL_HOME pointing to an appropriate (writable) directory.
137
138 <h3>2.2 Repository Databases</h3>
139
140 The repository database is the file that is commonly referred to as
141 "the repository". This is because the repository database contains,
142 among other things, the complete revision, ticket, and wiki history for
143 a project. It is customary to name the repository database after then
144 name of the project, with a ".fossil" suffix. For example, the repository
145 database for the self-hosting Fossil repository is called "fossil.fossil"
@@ -146,11 +145,11 @@
146 and the repository database for SQLite is called "sqlite.fossil".
147
148 <h4>2.2.1 Global Project State</h4>
149
150 The bulk of the repository database (typically 75 to 85%) consists
151 of the artifacts that comprise the
152 [./fileformat.wiki | enduring, global, shared state] of the project.
153 The artifacts are stored as BLOBs, compressed using
154 [http://www.zlib.net/ | zlib compression] and, where applicable,
155 using [./delta_encoder_algorithm.wiki | delta compression].
156 The combination of zlib and delta compression results in a considerable
@@ -160,26 +159,26 @@
160 32 MB of space in the repository database, for a compression ratio
161 of about 64:1. The average size of a content BLOB in the database
162 is around 500 bytes.
163
164 Note that the zlib and delta compression is not an inherent part of the
165 Fossil file format; it is just an optimization.
166 The enduring file format for Fossil is the unordered
167 set of artifacts. The compression techniques are just a detail of
168 how the current implementation of Fossil happens to store these artifacts
169 efficiently on disk.
170
171 All of the original uncompressed and undeltaed artifacts can be extracted
172 from a Fossil repository database using
173 the [/help/deconstruct | fossil deconstruct]
174 command. Individual artifacts can be extracted using the
175 [/help/artifact | fossil artifact] command.
176 When accessing the repository database using raw SQL and the
177 [/help/sqlite3 | fossil sql] command, the extension function
178 "<tt>content()</tt>" with a single argument which is the SHA1 hash
179 of an artifact will return the complete undeleted and uncompressed
180 content of that artifact.
181
182 Going the other way, the [/help/reconstruct | fossil reconstruct]
183 command will scan a directory hierarchy and add all files found to
184 a new repository database. The [/help/import | fossil import] command
185 works by reading the input git-fast-export stream and using it to construct
@@ -225,11 +224,11 @@
225 by [/help/sync | fossil sync]. That is because it is entirely reasonable
226 that two different websites for the same project might have completely
227 different display preferences and user communities. One instance of the
228 project might be a fork of the other, for example, which pulls from the
229 other but never pushes and extends the project in ways that the keepers of
230 the other website disapprove of.
231
232 Display and processing information includes the following:
233
234 * The name and description of the project
235 * The CSS file, header, and footer used by all web pages
@@ -242,31 +241,31 @@
242 global values defined in the per-user configuration database.
243
244 Though the display and processing preferences do not move between
245 repository instances using [/help/sync | fossil sync], this information
246 can be shared between repositories using the
247 [/help/config | fossil config push] and
248 [/help/config | fossil config pull] commands.
249 The display and processing information is also copied into new
250 repositories when they are created using
251 [/help/clone | fossil clone].
252
253 <h4>2.2.4 User Credentials And Privileges</h4>
254
255 Just because two development teams are collaborating on a project and allow
256 push and/or pull between their repositories does not mean that they
257 trust each other enough to share passwords and access privileges.
258 Hence the names and emails and passwords and privileges of users are
259 considered private information that is kept locally in each repository.
260
261 Each repository database has a table holding the username, privileges,
262 and login credentials for users authorized to interact with that particular
263 database. In addition, there is a table named "concealed" that maps the
264 SHA1 hash of each users email address back into their true email address.
265 The concealed table allows just the SHA1 hash of email addresses to
266 be stored in tickets, and thus prevents actual email addresses from falling
267 into the hands of spammers who happen to clone the repository.
268
269 The content of the user and concealed tables can be pushed and pulled using the
270 [/help/config | fossil config push] and
271 [/help/config | fossil config pull] commands with the "user" and
272 "email" as the AREA argument, but only if you have administrative
@@ -278,11 +277,11 @@
278 project - is intended to be an append-only database. In other words,
279 new artifacts can be added but artifacts can never be removed. But
280 it sometimes happens that inappropriate content is mistakenly or
281 maliciously added to a repository. The only way to get rid of
282 the undesired content is to [./shunning.wiki | "shun"] it.
283 The "shun" table in the repository database records the SHA1 hash of
284 all shunned artifacts.
285
286 The shun table can be pushed or pulled using
287 the [/help/config | fossil config] command with the "shun" AREA argument.
288 The shun table is also copied during a [/help/clone | clone].
289
--- www/tech_overview.wiki
+++ www/tech_overview.wiki
@@ -5,12 +5,12 @@
5
6 <h2>1.0 Introduction</h2>
7
8 At its lowest level, a Fossil repository consists of an unordered set
9 of immutable "artifacts". You might think of these artifacts as "files",
10 since in many cases the artifacts are exactly that.
11 But other "control artifacts"
12 are also included in the mix. These control artifacts define the relationships
13 between artifacts - which files go together to form a particular
14 version of the project, who checked in that version and when, what was
15 the check-in comment, what wiki pages are included with the project, what
16 are the edit histories of each wiki page, what bug reports or tickets are
@@ -17,21 +17,21 @@
17 included, who contributed to the evolution of each ticket, and so forth.
18 This low-level file format is called the "global state" of
19 the repository, since this is the information that is synced to peer
20 repositories using push and pull operations. The low-level file format
21 is also called "enduring" since it is intended to last for many years.
22 The details of the low-level, enduring, global file format
23 are [./fileformat.wiki | described separately].
24
25 This article is about how Fossil is currently implemented. Instead of
26 dealing with vague abstractions of "enduring file formats" as the
27 [./fileformat.wiki | other document] does, this article provides
28 some detail on how Fossil actually stores information on disk.
29
30 <h2>2.0 Three Databases</h2>
31
32 Fossil stores state information in
33 [http://www.sqlite.org/ | SQLite] database files.
34 SQLite keeps an entire relational database, including multiple tables and
35 indices, in a single disk file. The SQLite library allows the database
36 files to be efficiently queried and updated using the industry-standard
37 SQL language. SQLite updates are atomic, so even in the event of
@@ -46,11 +46,11 @@
46 </ol>
47
48 The configuration database is a one-per-user database that holds
49 global configuration information used by Fossil. There is one
50 repository database per project. The repository database is the
51 file that people are normally referring to when they say
52 "a Fossil repository". The checkout database is found in the working
53 checkout for a project and contains state information that is unique
54 to that working checkout.
55
56 Fossil does not always use all three database files. The web interface,
@@ -65,11 +65,11 @@
65 SQLite's [http://www.sqlite.org/lang_attach.html | ATTACH] command.
66
67 The chart below provides a quick summary of how each of these
68 database files are used by Fossil, with detailed discussion following.
69
70 <table border="1" width="80%" cellpadding="0" align="center">
71 <tr>
72 <td width="33%" valign="top">
73 <h3 align="center">Configuration Database<br>"~/.fossil"</h3>
74 <ul>
75 <li>Global [/help/setting |settings]
@@ -103,11 +103,10 @@
103 <li>Information needed to "[/help/undo|undo]" or "[/help/redo|redo]"
104 </ul>
105 </td>
106 </tr>
107 </table>
 
108
109 <h3>2.1 The Configuration Database</h3>
110
111 The configuration database holds cross-repository preferences and a list of all
112 repositories for a single user.
@@ -135,11 +134,11 @@
134 You can override this default location by defining the environment
135 variable FOSSIL_HOME pointing to an appropriate (writable) directory.
136
137 <h3>2.2 Repository Databases</h3>
138
139 The repository database is the file that is commonly referred to as
140 "the repository". This is because the repository database contains,
141 among other things, the complete revision, ticket, and wiki history for
142 a project. It is customary to name the repository database after then
143 name of the project, with a ".fossil" suffix. For example, the repository
144 database for the self-hosting Fossil repository is called "fossil.fossil"
@@ -146,11 +145,11 @@
145 and the repository database for SQLite is called "sqlite.fossil".
146
147 <h4>2.2.1 Global Project State</h4>
148
149 The bulk of the repository database (typically 75 to 85%) consists
150 of the artifacts that comprise the
151 [./fileformat.wiki | enduring, global, shared state] of the project.
152 The artifacts are stored as BLOBs, compressed using
153 [http://www.zlib.net/ | zlib compression] and, where applicable,
154 using [./delta_encoder_algorithm.wiki | delta compression].
155 The combination of zlib and delta compression results in a considerable
@@ -160,26 +159,26 @@
159 32 MB of space in the repository database, for a compression ratio
160 of about 64:1. The average size of a content BLOB in the database
161 is around 500 bytes.
162
163 Note that the zlib and delta compression is not an inherent part of the
164 Fossil file format; it is just an optimization.
165 The enduring file format for Fossil is the unordered
166 set of artifacts. The compression techniques are just a detail of
167 how the current implementation of Fossil happens to store these artifacts
168 efficiently on disk.
169
170 All of the original uncompressed and undeltaed artifacts can be extracted
171 from a Fossil repository database using
172 the [/help/deconstruct | fossil deconstruct]
173 command. Individual artifacts can be extracted using the
174 [/help/artifact | fossil artifact] command.
175 When accessing the repository database using raw SQL and the
176 [/help/sqlite3 | fossil sql] command, the extension function
177 "<tt>content()</tt>" with a single argument which is the SHA1 hash
178 of an artifact will return the complete undeleted and uncompressed
179 content of that artifact.
180
181 Going the other way, the [/help/reconstruct | fossil reconstruct]
182 command will scan a directory hierarchy and add all files found to
183 a new repository database. The [/help/import | fossil import] command
184 works by reading the input git-fast-export stream and using it to construct
@@ -225,11 +224,11 @@
224 by [/help/sync | fossil sync]. That is because it is entirely reasonable
225 that two different websites for the same project might have completely
226 different display preferences and user communities. One instance of the
227 project might be a fork of the other, for example, which pulls from the
228 other but never pushes and extends the project in ways that the keepers of
229 the other website disapprove of.
230
231 Display and processing information includes the following:
232
233 * The name and description of the project
234 * The CSS file, header, and footer used by all web pages
@@ -242,31 +241,31 @@
241 global values defined in the per-user configuration database.
242
243 Though the display and processing preferences do not move between
244 repository instances using [/help/sync | fossil sync], this information
245 can be shared between repositories using the
246 [/help/config | fossil config push] and
247 [/help/config | fossil config pull] commands.
248 The display and processing information is also copied into new
249 repositories when they are created using
250 [/help/clone | fossil clone].
251
252 <h4>2.2.4 User Credentials And Privileges</h4>
253
254 Just because two development teams are collaborating on a project and allow
255 push and/or pull between their repositories does not mean that they
256 trust each other enough to share passwords and access privileges.
257 Hence the names and emails and passwords and privileges of users are
258 considered private information that is kept locally in each repository.
259
260 Each repository database has a table holding the username, privileges,
261 and login credentials for users authorized to interact with that particular
262 database. In addition, there is a table named "concealed" that maps the
263 SHA1 hash of each users email address back into their true email address.
264 The concealed table allows just the SHA1 hash of email addresses to
265 be stored in tickets, and thus prevents actual email addresses from falling
266 into the hands of spammers who happen to clone the repository.
267
268 The content of the user and concealed tables can be pushed and pulled using the
269 [/help/config | fossil config push] and
270 [/help/config | fossil config pull] commands with the "user" and
271 "email" as the AREA argument, but only if you have administrative
@@ -278,11 +277,11 @@
277 project - is intended to be an append-only database. In other words,
278 new artifacts can be added but artifacts can never be removed. But
279 it sometimes happens that inappropriate content is mistakenly or
280 maliciously added to a repository. The only way to get rid of
281 the undesired content is to [./shunning.wiki | "shun"] it.
282 The "shun" table in the repository database records the SHA1 hash of
283 all shunned artifacts.
284
285 The shun table can be pushed or pulled using
286 the [/help/config | fossil config] command with the "shun" AREA argument.
287 The shun table is also copied during a [/help/clone | clone].
288

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button