Fossil SCM

Eliminate unnecessary end-of-line spacing in wiki. No textual changes.

jan.nijtmans 2016-11-02 10:16 trunk
Commit f47b7052c660f9566b8f08e83592300efcd80f39
Parent 69f64a8d64722e0…
39 files changed +10 -10 +5 -5 +11 -11 +4 -4 +1 -1 +8 -8 +3 -3 +8 -8 +7 -7 +2 -2 +1 -1 +9 -9 +9 -9 +1 -1 +3 -3 +5 -5 +26 -26 +19 -19 +2 -2 +11 -11 +1 -1 +5 -5 +13 -13 +1 -1 +5 -5 +3 -3 +10 -10 +26 -26 +13 -13 +12 -12 +3 -3 +6 -6 +20 -20 +3 -3 +10 -10 +3 -3 +6 -6 +5 -5 +4 -4
~ www/aboutcgi.wiki ~ www/adding_code.wiki ~ www/antibot.wiki ~ www/blame.wiki ~ www/bugtheory.wiki ~ www/checkin_names.wiki ~ www/childprojects.wiki ~ www/concepts.wiki ~ www/contribute.wiki ~ www/custom_ticket.wiki ~ www/delta_encoder_algorithm.wiki ~ www/delta_format.wiki ~ www/embeddeddoc.wiki ~ www/encryptedrepos.wiki ~ www/event.wiki ~ www/faq.wiki ~ www/fileformat.wiki ~ www/fiveminutes.wiki ~ www/foss-cklist.wiki ~ www/fossil-from-msvc.wiki ~ www/index.wiki ~ www/inout.wiki ~ www/makefile.wiki ~ www/newrepo.wiki ~ www/pop.wiki ~ www/private.wiki ~ www/qandc.wiki ~ www/quickstart.wiki ~ www/quotes.wiki ~ www/reviews.wiki ~ www/selfcheck.wiki ~ www/selfhost.wiki ~ www/server.wiki ~ www/settings.wiki ~ www/shunning.wiki ~ www/stats.wiki ~ www/sync.wiki ~ www/theory1.wiki ~ www/wikitheory.wiki
M www/aboutcgi.wiki
+10 -10
--- www/aboutcgi.wiki
+++ www/aboutcgi.wiki
@@ -66,11 +66,11 @@
6666
 <p>
6767
 In addition to setting various CGI environment variables, if the HTTP
6868
 request contains POST content, then the web server relays the POST content
6969
 to standard input of the CGI script.
7070
 <p>
71
-In summary, the task of the
71
+In summary, the task of the
7272
 CGI script is to read the various CGI environment variables and
7373
 the POST content on standard input (if any), figure out an appropriate
7474
 reply, then write that reply on standard output.
7575
 The web server will read the output from the CGI script, reformat it
7676
 into an appropriate HTTP reply, and relay the result back to the
@@ -89,31 +89,31 @@
8989
 like the following:
9090
 <blockquote><pre>
9191
 #!/usr/bin/fossil
9292
 repository: /home/www/repos/project.fossil
9393
 </pre></blockquote>
94
-The first line of the script is a
94
+The first line of the script is a
9595
 "[https://en.wikipedia.org/wiki/Shebang_%28Unix%29|shebang]"
9696
 that tells the operating system what program to use as the interpreter
9797
 for this script. On unix, when you execute a script that starts with
9898
 a shebang, the operating system runs the program identified by the
99
-shebang with a single argument that is the full pathname of the script
99
+shebang with a single argument that is the full pathname of the script
100100
 itself.
101101
 In our example, the interpreter is Fossil, and the argument might
102102
 be something like "/var/www/cgi-bin/one/two" (depending on how your
103103
 particular web server is configured).
104104
 <p>
105105
 The Fossil program that is run as the script interpreter
106106
 is the same Fossil that runs when
107107
 you type ordinary Fossil commands like "fossil sync" or "fossil commit".
108108
 But in this case, as soon as it launches, the Fossil program
109
-recognizes that the GATEWAY_INTERFACE environment variable is
109
+recognizes that the GATEWAY_INTERFACE environment variable is
110110
 set to "CGI/1.0" and it therefore knows that it is being used as
111111
 CGI rather than as an ordinary command-line tool, and behaves accordingly.
112112
 <p>
113113
 When Fossil recognizes that it is being run as CGI, it opens and reads
114
-the file identified by its sole argument (the file named by
114
+the file identified by its sole argument (the file named by
115115
 <code>argv&#91;1&#93;</code>). In our example, the second line of that file
116116
 tells Fossil the location of the repository it will be serving.
117117
 Fossil then starts looking at the CGI environment variables to figure
118118
 out what web page is being requested, generates that one web page,
119119
 then exits.
@@ -130,11 +130,11 @@
130130
 <ol type='A'>
131131
 <li> [https://www.fossil-scm.org/fossil/info/c14ecc43]
132132
 <li> [https://www.fossil-scm.org/fossil/info?name=c14ecc43]
133133
 </ol>
134134
 In both cases, the CGI script is called "/fossil". For case (A),
135
-the PATH_INFO variable will be "info/c14ecc43" and so the
135
+the PATH_INFO variable will be "info/c14ecc43" and so the
136136
 "[/help?cmd=/info|/info]" webpage will be generated and the suffix of
137137
 PATH_INFO will be converted into the "name" query parameter, which
138138
 identifies the artifact about which information is requested.
139139
 In case (B), the PATH_INFO is just "info", but the same "name"
140140
 query parameter is set explicitly by the URL itself.
@@ -164,11 +164,11 @@
164164
 <blockquote>
165165
 <b>http://example.com/cgis/example2/subdir/three/timeline</b>
166166
 </blockquote>
167167
 Here is what happens:
168168
 <ol>
169
-<li> The input URI on the HTTP request is
169
+<li> The input URI on the HTTP request is
170170
 <b>/cgis/example2/subdir/three/timeline</b>
171171
 <li> The web server searches prefixes of the input URI until it finds
172172
 the "cgis/example2" script. The web server then sets
173173
 PATH_INFO to the "subdir/three/timeline" suffix and invokes the
174174
 "cgis/example2" script.
@@ -175,11 +175,11 @@
175175
 <li> Fossil runs and sees the "directory:" line pointing to
176176
 "/home/www/repos". Fossil then starts pulling terms off the
177177
 front of the PATH_INFO looking for a repository. It first looks
178178
 at "/home/www/resps/subdir.fossil" but there is no such repository.
179179
 So then it looks at "/home/www/repos/subdir/three.fossil" and finds
180
- a repository. The PATH_INFO is shortened by removing
180
+ a repository. The PATH_INFO is shortened by removing
181181
 "subdir/three/" leaving it at just "timeline".
182182
 <li> Fossil looks at the rest of PATH_INFO to see that the webpage
183183
 requested is "timeline".
184184
 </ol>
185185
 </blockquote>
@@ -201,14 +201,14 @@
201201
 and has a value.
202202
 <li><p>
203203
 The "[/help?cmd=ui|fossil ui]" and "[/help?cmd=server|fossil server]" commands
204204
 are implemented using a simple built-in web server that accepts incoming HTTP
205205
 requests, translates each request into a CGI invocation, then creates a
206
-separate child Fossil process to handle each request. In other words, CGI
206
+separate child Fossil process to handle each request. In other words, CGI
207207
 is used internally to implement "fossil ui/server".
208208
 <p>
209209
 SCGI is processed using the same built-in web server, just modified
210210
 to parse SCGI requests instead of HTTP requests. Each SCGI request is
211
-converted into CGI, then Fossil creates a separate child Fossil
211
+converted into CGI, then Fossil creates a separate child Fossil
212212
 process to handle each CGI request.
213213
 </ol>
214214
 </blockquote>
215215
--- www/aboutcgi.wiki
+++ www/aboutcgi.wiki
@@ -66,11 +66,11 @@
66 <p>
67 In addition to setting various CGI environment variables, if the HTTP
68 request contains POST content, then the web server relays the POST content
69 to standard input of the CGI script.
70 <p>
71 In summary, the task of the
72 CGI script is to read the various CGI environment variables and
73 the POST content on standard input (if any), figure out an appropriate
74 reply, then write that reply on standard output.
75 The web server will read the output from the CGI script, reformat it
76 into an appropriate HTTP reply, and relay the result back to the
@@ -89,31 +89,31 @@
89 like the following:
90 <blockquote><pre>
91 #!/usr/bin/fossil
92 repository: /home/www/repos/project.fossil
93 </pre></blockquote>
94 The first line of the script is a
95 "[https://en.wikipedia.org/wiki/Shebang_%28Unix%29|shebang]"
96 that tells the operating system what program to use as the interpreter
97 for this script. On unix, when you execute a script that starts with
98 a shebang, the operating system runs the program identified by the
99 shebang with a single argument that is the full pathname of the script
100 itself.
101 In our example, the interpreter is Fossil, and the argument might
102 be something like "/var/www/cgi-bin/one/two" (depending on how your
103 particular web server is configured).
104 <p>
105 The Fossil program that is run as the script interpreter
106 is the same Fossil that runs when
107 you type ordinary Fossil commands like "fossil sync" or "fossil commit".
108 But in this case, as soon as it launches, the Fossil program
109 recognizes that the GATEWAY_INTERFACE environment variable is
110 set to "CGI/1.0" and it therefore knows that it is being used as
111 CGI rather than as an ordinary command-line tool, and behaves accordingly.
112 <p>
113 When Fossil recognizes that it is being run as CGI, it opens and reads
114 the file identified by its sole argument (the file named by
115 <code>argv&#91;1&#93;</code>). In our example, the second line of that file
116 tells Fossil the location of the repository it will be serving.
117 Fossil then starts looking at the CGI environment variables to figure
118 out what web page is being requested, generates that one web page,
119 then exits.
@@ -130,11 +130,11 @@
130 <ol type='A'>
131 <li> [https://www.fossil-scm.org/fossil/info/c14ecc43]
132 <li> [https://www.fossil-scm.org/fossil/info?name=c14ecc43]
133 </ol>
134 In both cases, the CGI script is called "/fossil". For case (A),
135 the PATH_INFO variable will be "info/c14ecc43" and so the
136 "[/help?cmd=/info|/info]" webpage will be generated and the suffix of
137 PATH_INFO will be converted into the "name" query parameter, which
138 identifies the artifact about which information is requested.
139 In case (B), the PATH_INFO is just "info", but the same "name"
140 query parameter is set explicitly by the URL itself.
@@ -164,11 +164,11 @@
164 <blockquote>
165 <b>http://example.com/cgis/example2/subdir/three/timeline</b>
166 </blockquote>
167 Here is what happens:
168 <ol>
169 <li> The input URI on the HTTP request is
170 <b>/cgis/example2/subdir/three/timeline</b>
171 <li> The web server searches prefixes of the input URI until it finds
172 the "cgis/example2" script. The web server then sets
173 PATH_INFO to the "subdir/three/timeline" suffix and invokes the
174 "cgis/example2" script.
@@ -175,11 +175,11 @@
175 <li> Fossil runs and sees the "directory:" line pointing to
176 "/home/www/repos". Fossil then starts pulling terms off the
177 front of the PATH_INFO looking for a repository. It first looks
178 at "/home/www/resps/subdir.fossil" but there is no such repository.
179 So then it looks at "/home/www/repos/subdir/three.fossil" and finds
180 a repository. The PATH_INFO is shortened by removing
181 "subdir/three/" leaving it at just "timeline".
182 <li> Fossil looks at the rest of PATH_INFO to see that the webpage
183 requested is "timeline".
184 </ol>
185 </blockquote>
@@ -201,14 +201,14 @@
201 and has a value.
202 <li><p>
203 The "[/help?cmd=ui|fossil ui]" and "[/help?cmd=server|fossil server]" commands
204 are implemented using a simple built-in web server that accepts incoming HTTP
205 requests, translates each request into a CGI invocation, then creates a
206 separate child Fossil process to handle each request. In other words, CGI
207 is used internally to implement "fossil ui/server".
208 <p>
209 SCGI is processed using the same built-in web server, just modified
210 to parse SCGI requests instead of HTTP requests. Each SCGI request is
211 converted into CGI, then Fossil creates a separate child Fossil
212 process to handle each CGI request.
213 </ol>
214 </blockquote>
215
--- www/aboutcgi.wiki
+++ www/aboutcgi.wiki
@@ -66,11 +66,11 @@
66 <p>
67 In addition to setting various CGI environment variables, if the HTTP
68 request contains POST content, then the web server relays the POST content
69 to standard input of the CGI script.
70 <p>
71 In summary, the task of the
72 CGI script is to read the various CGI environment variables and
73 the POST content on standard input (if any), figure out an appropriate
74 reply, then write that reply on standard output.
75 The web server will read the output from the CGI script, reformat it
76 into an appropriate HTTP reply, and relay the result back to the
@@ -89,31 +89,31 @@
89 like the following:
90 <blockquote><pre>
91 #!/usr/bin/fossil
92 repository: /home/www/repos/project.fossil
93 </pre></blockquote>
94 The first line of the script is a
95 "[https://en.wikipedia.org/wiki/Shebang_%28Unix%29|shebang]"
96 that tells the operating system what program to use as the interpreter
97 for this script. On unix, when you execute a script that starts with
98 a shebang, the operating system runs the program identified by the
99 shebang with a single argument that is the full pathname of the script
100 itself.
101 In our example, the interpreter is Fossil, and the argument might
102 be something like "/var/www/cgi-bin/one/two" (depending on how your
103 particular web server is configured).
104 <p>
105 The Fossil program that is run as the script interpreter
106 is the same Fossil that runs when
107 you type ordinary Fossil commands like "fossil sync" or "fossil commit".
108 But in this case, as soon as it launches, the Fossil program
109 recognizes that the GATEWAY_INTERFACE environment variable is
110 set to "CGI/1.0" and it therefore knows that it is being used as
111 CGI rather than as an ordinary command-line tool, and behaves accordingly.
112 <p>
113 When Fossil recognizes that it is being run as CGI, it opens and reads
114 the file identified by its sole argument (the file named by
115 <code>argv&#91;1&#93;</code>). In our example, the second line of that file
116 tells Fossil the location of the repository it will be serving.
117 Fossil then starts looking at the CGI environment variables to figure
118 out what web page is being requested, generates that one web page,
119 then exits.
@@ -130,11 +130,11 @@
130 <ol type='A'>
131 <li> [https://www.fossil-scm.org/fossil/info/c14ecc43]
132 <li> [https://www.fossil-scm.org/fossil/info?name=c14ecc43]
133 </ol>
134 In both cases, the CGI script is called "/fossil". For case (A),
135 the PATH_INFO variable will be "info/c14ecc43" and so the
136 "[/help?cmd=/info|/info]" webpage will be generated and the suffix of
137 PATH_INFO will be converted into the "name" query parameter, which
138 identifies the artifact about which information is requested.
139 In case (B), the PATH_INFO is just "info", but the same "name"
140 query parameter is set explicitly by the URL itself.
@@ -164,11 +164,11 @@
164 <blockquote>
165 <b>http://example.com/cgis/example2/subdir/three/timeline</b>
166 </blockquote>
167 Here is what happens:
168 <ol>
169 <li> The input URI on the HTTP request is
170 <b>/cgis/example2/subdir/three/timeline</b>
171 <li> The web server searches prefixes of the input URI until it finds
172 the "cgis/example2" script. The web server then sets
173 PATH_INFO to the "subdir/three/timeline" suffix and invokes the
174 "cgis/example2" script.
@@ -175,11 +175,11 @@
175 <li> Fossil runs and sees the "directory:" line pointing to
176 "/home/www/repos". Fossil then starts pulling terms off the
177 front of the PATH_INFO looking for a repository. It first looks
178 at "/home/www/resps/subdir.fossil" but there is no such repository.
179 So then it looks at "/home/www/repos/subdir/three.fossil" and finds
180 a repository. The PATH_INFO is shortened by removing
181 "subdir/three/" leaving it at just "timeline".
182 <li> Fossil looks at the rest of PATH_INFO to see that the webpage
183 requested is "timeline".
184 </ol>
185 </blockquote>
@@ -201,14 +201,14 @@
201 and has a value.
202 <li><p>
203 The "[/help?cmd=ui|fossil ui]" and "[/help?cmd=server|fossil server]" commands
204 are implemented using a simple built-in web server that accepts incoming HTTP
205 requests, translates each request into a CGI invocation, then creates a
206 separate child Fossil process to handle each request. In other words, CGI
207 is used internally to implement "fossil ui/server".
208 <p>
209 SCGI is processed using the same built-in web server, just modified
210 to parse SCGI requests instead of HTTP requests. Each SCGI request is
211 converted into CGI, then Fossil creates a separate child Fossil
212 process to handle each CGI request.
213 </ol>
214 </blockquote>
215
M www/adding_code.wiki
+5 -5
--- www/adding_code.wiki
+++ www/adding_code.wiki
@@ -22,11 +22,11 @@
2222
2323
 2. The <b>makeheaders</b> preprocessor generates all the ".h" files
2424
 automatically. Fossil programmers write ".c" files only and let the
2525
 makeheaders preprocessor create the ".h" files.
2626
27
- 3. The <b>translate</b> preprocessor converts source code lines that
27
+ 3. The <b>translate</b> preprocessor converts source code lines that
2828
 begin with "@" into string literals, or into print statements that
2929
 generate web page output, depending on context.
3030
3131
 The [./makefile.wiki|Makefile] for Fossil takes care of running these
3232
 preprocessors with all the right arguments and in the right order. So it is
@@ -39,13 +39,13 @@
3939
 <h2>3.0 Adding New Source Code Files</h2>
4040
4141
 New source code files are added in the "src/" subdirectory of the Fossil
4242
 source tree. Suppose one wants to add a new source code file named
4343
 "xyzzy.c". The first step is to add this file to the various makefiles.
44
-Do so by editing the file src/makemake.tcl and adding "xyzzy" (without
44
+Do so by editing the file src/makemake.tcl and adding "xyzzy" (without
4545
 the final ".c") to the list of source modules at the top of that script.
46
-Save the result and then run the makemake.tcl script using a TCL
46
+Save the result and then run the makemake.tcl script using a TCL
4747
 interpreter. The command to run the makemake.tcl script is:
4848
4949
 <b>tclsh makemake.tcl</b>
5050
5151
 The working directory must be src/ when the command above is run.
@@ -60,11 +60,11 @@
6060
6161
 <blockquote><verbatim>
6262
 /*
6363
 ** Copyright boilerplate goes here.
6464
 *****************************************************
65
-** High-level description of what this module goes
65
+** High-level description of what this module goes
6666
 ** here.
6767
 */
6868
 #include "config.h"
6969
 #include "xyzzy.h"
7070
@@ -83,11 +83,11 @@
8383
 exceptions to this rule. Don't worry about those exceptions. The
8484
 files you write will require this #include line.)
8585
8686
 The "#if INTERFACE ... #endif" section is optional and is only needed
8787
 if there are structure definitions or typedefs or macros that need to
88
-be used by other source code files. The makeheaders preprocessor
88
+be used by other source code files. The makeheaders preprocessor
8989
 uses definitions in the INTERFACE section to help it generate header
9090
 files. See [../src/makeheaders.html | makeheaders.html] for additional
9191
 information.
9292
9393
 After creating a template file such as shown above, and after updating
9494
--- www/adding_code.wiki
+++ www/adding_code.wiki
@@ -22,11 +22,11 @@
22
23 2. The <b>makeheaders</b> preprocessor generates all the ".h" files
24 automatically. Fossil programmers write ".c" files only and let the
25 makeheaders preprocessor create the ".h" files.
26
27 3. The <b>translate</b> preprocessor converts source code lines that
28 begin with "@" into string literals, or into print statements that
29 generate web page output, depending on context.
30
31 The [./makefile.wiki|Makefile] for Fossil takes care of running these
32 preprocessors with all the right arguments and in the right order. So it is
@@ -39,13 +39,13 @@
39 <h2>3.0 Adding New Source Code Files</h2>
40
41 New source code files are added in the "src/" subdirectory of the Fossil
42 source tree. Suppose one wants to add a new source code file named
43 "xyzzy.c". The first step is to add this file to the various makefiles.
44 Do so by editing the file src/makemake.tcl and adding "xyzzy" (without
45 the final ".c") to the list of source modules at the top of that script.
46 Save the result and then run the makemake.tcl script using a TCL
47 interpreter. The command to run the makemake.tcl script is:
48
49 <b>tclsh makemake.tcl</b>
50
51 The working directory must be src/ when the command above is run.
@@ -60,11 +60,11 @@
60
61 <blockquote><verbatim>
62 /*
63 ** Copyright boilerplate goes here.
64 *****************************************************
65 ** High-level description of what this module goes
66 ** here.
67 */
68 #include "config.h"
69 #include "xyzzy.h"
70
@@ -83,11 +83,11 @@
83 exceptions to this rule. Don't worry about those exceptions. The
84 files you write will require this #include line.)
85
86 The "#if INTERFACE ... #endif" section is optional and is only needed
87 if there are structure definitions or typedefs or macros that need to
88 be used by other source code files. The makeheaders preprocessor
89 uses definitions in the INTERFACE section to help it generate header
90 files. See [../src/makeheaders.html | makeheaders.html] for additional
91 information.
92
93 After creating a template file such as shown above, and after updating
94
--- www/adding_code.wiki
+++ www/adding_code.wiki
@@ -22,11 +22,11 @@
22
23 2. The <b>makeheaders</b> preprocessor generates all the ".h" files
24 automatically. Fossil programmers write ".c" files only and let the
25 makeheaders preprocessor create the ".h" files.
26
27 3. The <b>translate</b> preprocessor converts source code lines that
28 begin with "@" into string literals, or into print statements that
29 generate web page output, depending on context.
30
31 The [./makefile.wiki|Makefile] for Fossil takes care of running these
32 preprocessors with all the right arguments and in the right order. So it is
@@ -39,13 +39,13 @@
39 <h2>3.0 Adding New Source Code Files</h2>
40
41 New source code files are added in the "src/" subdirectory of the Fossil
42 source tree. Suppose one wants to add a new source code file named
43 "xyzzy.c". The first step is to add this file to the various makefiles.
44 Do so by editing the file src/makemake.tcl and adding "xyzzy" (without
45 the final ".c") to the list of source modules at the top of that script.
46 Save the result and then run the makemake.tcl script using a TCL
47 interpreter. The command to run the makemake.tcl script is:
48
49 <b>tclsh makemake.tcl</b>
50
51 The working directory must be src/ when the command above is run.
@@ -60,11 +60,11 @@
60
61 <blockquote><verbatim>
62 /*
63 ** Copyright boilerplate goes here.
64 *****************************************************
65 ** High-level description of what this module goes
66 ** here.
67 */
68 #include "config.h"
69 #include "xyzzy.h"
70
@@ -83,11 +83,11 @@
83 exceptions to this rule. Don't worry about those exceptions. The
84 files you write will require this #include line.)
85
86 The "#if INTERFACE ... #endif" section is optional and is only needed
87 if there are structure definitions or typedefs or macros that need to
88 be used by other source code files. The makeheaders preprocessor
89 uses definitions in the INTERFACE section to help it generate header
90 files. See [../src/makeheaders.html | makeheaders.html] for additional
91 information.
92
93 After creating a template file such as shown above, and after updating
94
M www/antibot.wiki
+11 -11
--- www/antibot.wiki
+++ www/antibot.wiki
@@ -1,27 +1,27 @@
11
 <title>Defense Against Spiders</title>
22
33
 The website presented by a Fossil server has many hyperlinks.
44
 Even a modest project can have millions of pages in its
5
-tree, and many of those pages (for example diffs and annotations
5
+tree, and many of those pages (for example diffs and annotations
66
 and ZIP archive of older check-ins) can be expensive to compute.
77
 If a spider or bot tries to walk a website implemented by
88
 Fossil, it can present a crippling bandwidth and CPU load.
99
1010
 The website presented by a Fossil server is intended to be used
11
-interactively by humans, not walked by spiders. This article
11
+interactively by humans, not walked by spiders. This article
1212
 describes the techniques used by Fossil to try to welcome human
1313
 users while keeping out spiders.
1414
1515
 <h2>The "hyperlink" user capability</h2>
1616
1717
 Every Fossil web session has a "user". For random passers-by on the internet
1818
 (and for spiders) that user is "nobody". The "anonymous" user is also
1919
 available for humans who do not wish to identify themselves. The difference
2020
 is that "anonymous" requires a login (using a password supplied via
21
-a CAPTCHA) whereas "nobody" does not require a login.
22
-The site administrator can also create logins with
21
+a CAPTCHA) whereas "nobody" does not require a login.
22
+The site administrator can also create logins with
2323
 passwords for specific individuals.
2424
2525
 The "h" or "hyperlink" capability is a permission that can be granted
2626
 to users that enables the display of hyperlinks. Most of the hyperlinks
2727
 generated by Fossil are suppressed if this capability is missing. So
@@ -37,11 +37,11 @@
3737
 page inviting the user to log in as anonymous in order to activate hyperlinks.
3838
3939
 Removing the "h" capability from user "nobody" is an effective means
4040
 of preventing spiders from walking a Fossil-generated website. But
4141
 it can also be annoying to humans, since it requires them to log in.
42
-Hence, Fossil provides other techniques for blocking spiders which
42
+Hence, Fossil provides other techniques for blocking spiders which
4343
 are less cumbersome to humans.
4444
4545
 <h2>Automatic hyperlinks based on UserAgent</h2>
4646
4747
 Fossil has the ability to selectively enable hyperlinks for users
@@ -94,25 +94,25 @@
9494
 web browsers implement javascript, so hyperlinks will appears
9595
 normally for human users.
9696
9797
 <h2>Further defenses</h2>
9898
99
-Recently (as of this writing, in the spring of 2013) the Fossil server
99
+Recently (as of this writing, in the spring of 2013) the Fossil server
100100
 on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101
-by Chinese spiders that use forged UserAgent strings to make them look
101
+by Chinese spiders that use forged UserAgent strings to make them look
102102
 like normal web browsers and which interpret javascript. We do not
103103
 believe these attacks to be nefarious since SQLite is public domain
104104
 and the attackers could obtain all information they ever wanted to
105
-know about SQLite simply by cloning the repository. Instead, we
105
+know about SQLite simply by cloning the repository. Instead, we
106106
 believe these "attacks" are coming from "script kiddies". But regardless
107107
 of whether or not malice is involved, these attacks do present
108108
 an unnecessary load on the server which reduces the responsiveness of
109109
 the SQLite website for well-behaved and socially responsible users.
110110
 For this reason, additional defenses against
111111
 spiders have been put in place.
112112
113
-On the Admin/Access page of Fossil, just below the
113
+On the Admin/Access page of Fossil, just below the
114114
 "<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115115
 setting, there are now two additional subsettings that can be optionally
116116
 enabled to control hyperlinks.
117117
118118
 The first subsetting waits to run the
@@ -137,11 +137,11 @@
137137
 Fossil currently does a very good job of providing easy access to humans
138138
 while keeping out troublesome robots and spiders. However, spiders and
139139
 bots continue to grow more sophisticated, requiring ever more advanced
140140
 defenses. This "arms race" is unlikely to ever end. The developers of
141141
 Fossil will continue to try improve the spider defenses of Fossil so
142
-check back from time to time for the latest releases and updates.
142
+check back from time to time for the latest releases and updates.
143143
144144
 Readers of this page who have suggestions on how to improve the spider
145145
 defenses in Fossil are invited to submit your ideas to the Fossil Users
146
-mailing list:
146
+mailing list:
147147
 [mailto:[email protected] | [email protected]].
148148
--- www/antibot.wiki
+++ www/antibot.wiki
@@ -1,27 +1,27 @@
1 <title>Defense Against Spiders</title>
2
3 The website presented by a Fossil server has many hyperlinks.
4 Even a modest project can have millions of pages in its
5 tree, and many of those pages (for example diffs and annotations
6 and ZIP archive of older check-ins) can be expensive to compute.
7 If a spider or bot tries to walk a website implemented by
8 Fossil, it can present a crippling bandwidth and CPU load.
9
10 The website presented by a Fossil server is intended to be used
11 interactively by humans, not walked by spiders. This article
12 describes the techniques used by Fossil to try to welcome human
13 users while keeping out spiders.
14
15 <h2>The "hyperlink" user capability</h2>
16
17 Every Fossil web session has a "user". For random passers-by on the internet
18 (and for spiders) that user is "nobody". The "anonymous" user is also
19 available for humans who do not wish to identify themselves. The difference
20 is that "anonymous" requires a login (using a password supplied via
21 a CAPTCHA) whereas "nobody" does not require a login.
22 The site administrator can also create logins with
23 passwords for specific individuals.
24
25 The "h" or "hyperlink" capability is a permission that can be granted
26 to users that enables the display of hyperlinks. Most of the hyperlinks
27 generated by Fossil are suppressed if this capability is missing. So
@@ -37,11 +37,11 @@
37 page inviting the user to log in as anonymous in order to activate hyperlinks.
38
39 Removing the "h" capability from user "nobody" is an effective means
40 of preventing spiders from walking a Fossil-generated website. But
41 it can also be annoying to humans, since it requires them to log in.
42 Hence, Fossil provides other techniques for blocking spiders which
43 are less cumbersome to humans.
44
45 <h2>Automatic hyperlinks based on UserAgent</h2>
46
47 Fossil has the ability to selectively enable hyperlinks for users
@@ -94,25 +94,25 @@
94 web browsers implement javascript, so hyperlinks will appears
95 normally for human users.
96
97 <h2>Further defenses</h2>
98
99 Recently (as of this writing, in the spring of 2013) the Fossil server
100 on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101 by Chinese spiders that use forged UserAgent strings to make them look
102 like normal web browsers and which interpret javascript. We do not
103 believe these attacks to be nefarious since SQLite is public domain
104 and the attackers could obtain all information they ever wanted to
105 know about SQLite simply by cloning the repository. Instead, we
106 believe these "attacks" are coming from "script kiddies". But regardless
107 of whether or not malice is involved, these attacks do present
108 an unnecessary load on the server which reduces the responsiveness of
109 the SQLite website for well-behaved and socially responsible users.
110 For this reason, additional defenses against
111 spiders have been put in place.
112
113 On the Admin/Access page of Fossil, just below the
114 "<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115 setting, there are now two additional subsettings that can be optionally
116 enabled to control hyperlinks.
117
118 The first subsetting waits to run the
@@ -137,11 +137,11 @@
137 Fossil currently does a very good job of providing easy access to humans
138 while keeping out troublesome robots and spiders. However, spiders and
139 bots continue to grow more sophisticated, requiring ever more advanced
140 defenses. This "arms race" is unlikely to ever end. The developers of
141 Fossil will continue to try improve the spider defenses of Fossil so
142 check back from time to time for the latest releases and updates.
143
144 Readers of this page who have suggestions on how to improve the spider
145 defenses in Fossil are invited to submit your ideas to the Fossil Users
146 mailing list:
147 [mailto:[email protected] | [email protected]].
148
--- www/antibot.wiki
+++ www/antibot.wiki
@@ -1,27 +1,27 @@
1 <title>Defense Against Spiders</title>
2
3 The website presented by a Fossil server has many hyperlinks.
4 Even a modest project can have millions of pages in its
5 tree, and many of those pages (for example diffs and annotations
6 and ZIP archive of older check-ins) can be expensive to compute.
7 If a spider or bot tries to walk a website implemented by
8 Fossil, it can present a crippling bandwidth and CPU load.
9
10 The website presented by a Fossil server is intended to be used
11 interactively by humans, not walked by spiders. This article
12 describes the techniques used by Fossil to try to welcome human
13 users while keeping out spiders.
14
15 <h2>The "hyperlink" user capability</h2>
16
17 Every Fossil web session has a "user". For random passers-by on the internet
18 (and for spiders) that user is "nobody". The "anonymous" user is also
19 available for humans who do not wish to identify themselves. The difference
20 is that "anonymous" requires a login (using a password supplied via
21 a CAPTCHA) whereas "nobody" does not require a login.
22 The site administrator can also create logins with
23 passwords for specific individuals.
24
25 The "h" or "hyperlink" capability is a permission that can be granted
26 to users that enables the display of hyperlinks. Most of the hyperlinks
27 generated by Fossil are suppressed if this capability is missing. So
@@ -37,11 +37,11 @@
37 page inviting the user to log in as anonymous in order to activate hyperlinks.
38
39 Removing the "h" capability from user "nobody" is an effective means
40 of preventing spiders from walking a Fossil-generated website. But
41 it can also be annoying to humans, since it requires them to log in.
42 Hence, Fossil provides other techniques for blocking spiders which
43 are less cumbersome to humans.
44
45 <h2>Automatic hyperlinks based on UserAgent</h2>
46
47 Fossil has the ability to selectively enable hyperlinks for users
@@ -94,25 +94,25 @@
94 web browsers implement javascript, so hyperlinks will appears
95 normally for human users.
96
97 <h2>Further defenses</h2>
98
99 Recently (as of this writing, in the spring of 2013) the Fossil server
100 on the SQLite website ([http://www.sqlite.org/src/]) has been hit repeatedly
101 by Chinese spiders that use forged UserAgent strings to make them look
102 like normal web browsers and which interpret javascript. We do not
103 believe these attacks to be nefarious since SQLite is public domain
104 and the attackers could obtain all information they ever wanted to
105 know about SQLite simply by cloning the repository. Instead, we
106 believe these "attacks" are coming from "script kiddies". But regardless
107 of whether or not malice is involved, these attacks do present
108 an unnecessary load on the server which reduces the responsiveness of
109 the SQLite website for well-behaved and socially responsible users.
110 For this reason, additional defenses against
111 spiders have been put in place.
112
113 On the Admin/Access page of Fossil, just below the
114 "<b>Enable hyperlinks for "nobody" based on User-Agent and Javascript</b>"
115 setting, there are now two additional subsettings that can be optionally
116 enabled to control hyperlinks.
117
118 The first subsetting waits to run the
@@ -137,11 +137,11 @@
137 Fossil currently does a very good job of providing easy access to humans
138 while keeping out troublesome robots and spiders. However, spiders and
139 bots continue to grow more sophisticated, requiring ever more advanced
140 defenses. This "arms race" is unlikely to ever end. The developers of
141 Fossil will continue to try improve the spider defenses of Fossil so
142 check back from time to time for the latest releases and updates.
143
144 Readers of this page who have suggestions on how to improve the spider
145 defenses in Fossil are invited to submit your ideas to the Fossil Users
146 mailing list:
147 [mailto:[email protected] | [email protected]].
148
M www/blame.wiki
+4 -4
--- www/blame.wiki
+++ www/blame.wiki
@@ -18,16 +18,16 @@
1818
 <li>Locate the check-in that contains the file that is to be
1919
 annotated. Call this check-in C0.
2020
 <li>Find all direct ancestors of C0. A direct ancestor is the closure
2121
 of the primary parent of C0. Merged in branches are not part of
2222
 the direct ancestors of C0.
23
-<li>Prune the list of ancestors of C0 so that it contains only
23
+<li>Prune the list of ancestors of C0 so that it contains only
2424
 check-in in which the file to be annotated was modified.
2525
 <li>Load the complete text of the file to be annotated from check-in C0.
2626
 Call this version of the file F0.
2727
 <li>Parse F0 into lines. Mark each line as "unchanged".
28
-<li>For each ancestor of C0 on the pruned list (call the ancestor CX),
28
+<li>For each ancestor of C0 on the pruned list (call the ancestor CX),
2929
 beginning with the most
3030
 recent ancestor and moving toward the oldest ancestor, do the
3131
 following steps:
3232
 <ol type='a'>
3333
 <li>Load the text for the file to be annotated as it existed in check-in CX.
@@ -44,19 +44,19 @@
4444
 <h2>3.0 Discussion and Notes</h2>
4545
4646
 The time-consuming part of this algorithm is step 6b - computing the
4747
 diff from all historical versions of the file to the version of the file
4848
 under analysis. For a large file that has many historical changes, this
49
-can take several seconds. For this reason, the default
49
+can take several seconds. For this reason, the default
5050
 [/help?cmd=/annotate|/annotate] webpage only shows those lines that where
5151
 changed by the 20 most recent modifications to the file. This allows
5252
 the loop on step 6 to terminate after only 19 diffs instead of the hundreds
5353
 or thousands of diffs that might be required for a frequently modified file.
5454
5555
 As currently implemented (as of 2015-12-12) the annotate algorithm does not
56
-follow files across name changes. File name change information is
56
+follow files across name changes. File name change information is
5757
 available in the database, and so the algorithm could be enhanced to follow
5858
 files across name changes by modifications to step 3.
5959
6060
 Step 2 is interesting in that it is
6161
 [/artifact/6cb824a0417?ln=196-201 | implemented] using a
6262
 [https://www.sqlite.org/lang_with.html#recursivecte|recursive common table expression].
6363
--- www/blame.wiki
+++ www/blame.wiki
@@ -18,16 +18,16 @@
18 <li>Locate the check-in that contains the file that is to be
19 annotated. Call this check-in C0.
20 <li>Find all direct ancestors of C0. A direct ancestor is the closure
21 of the primary parent of C0. Merged in branches are not part of
22 the direct ancestors of C0.
23 <li>Prune the list of ancestors of C0 so that it contains only
24 check-in in which the file to be annotated was modified.
25 <li>Load the complete text of the file to be annotated from check-in C0.
26 Call this version of the file F0.
27 <li>Parse F0 into lines. Mark each line as "unchanged".
28 <li>For each ancestor of C0 on the pruned list (call the ancestor CX),
29 beginning with the most
30 recent ancestor and moving toward the oldest ancestor, do the
31 following steps:
32 <ol type='a'>
33 <li>Load the text for the file to be annotated as it existed in check-in CX.
@@ -44,19 +44,19 @@
44 <h2>3.0 Discussion and Notes</h2>
45
46 The time-consuming part of this algorithm is step 6b - computing the
47 diff from all historical versions of the file to the version of the file
48 under analysis. For a large file that has many historical changes, this
49 can take several seconds. For this reason, the default
50 [/help?cmd=/annotate|/annotate] webpage only shows those lines that where
51 changed by the 20 most recent modifications to the file. This allows
52 the loop on step 6 to terminate after only 19 diffs instead of the hundreds
53 or thousands of diffs that might be required for a frequently modified file.
54
55 As currently implemented (as of 2015-12-12) the annotate algorithm does not
56 follow files across name changes. File name change information is
57 available in the database, and so the algorithm could be enhanced to follow
58 files across name changes by modifications to step 3.
59
60 Step 2 is interesting in that it is
61 [/artifact/6cb824a0417?ln=196-201 | implemented] using a
62 [https://www.sqlite.org/lang_with.html#recursivecte|recursive common table expression].
63
--- www/blame.wiki
+++ www/blame.wiki
@@ -18,16 +18,16 @@
18 <li>Locate the check-in that contains the file that is to be
19 annotated. Call this check-in C0.
20 <li>Find all direct ancestors of C0. A direct ancestor is the closure
21 of the primary parent of C0. Merged in branches are not part of
22 the direct ancestors of C0.
23 <li>Prune the list of ancestors of C0 so that it contains only
24 check-in in which the file to be annotated was modified.
25 <li>Load the complete text of the file to be annotated from check-in C0.
26 Call this version of the file F0.
27 <li>Parse F0 into lines. Mark each line as "unchanged".
28 <li>For each ancestor of C0 on the pruned list (call the ancestor CX),
29 beginning with the most
30 recent ancestor and moving toward the oldest ancestor, do the
31 following steps:
32 <ol type='a'>
33 <li>Load the text for the file to be annotated as it existed in check-in CX.
@@ -44,19 +44,19 @@
44 <h2>3.0 Discussion and Notes</h2>
45
46 The time-consuming part of this algorithm is step 6b - computing the
47 diff from all historical versions of the file to the version of the file
48 under analysis. For a large file that has many historical changes, this
49 can take several seconds. For this reason, the default
50 [/help?cmd=/annotate|/annotate] webpage only shows those lines that where
51 changed by the 20 most recent modifications to the file. This allows
52 the loop on step 6 to terminate after only 19 diffs instead of the hundreds
53 or thousands of diffs that might be required for a frequently modified file.
54
55 As currently implemented (as of 2015-12-12) the annotate algorithm does not
56 follow files across name changes. File name change information is
57 available in the database, and so the algorithm could be enhanced to follow
58 files across name changes by modifications to step 3.
59
60 Step 2 is interesting in that it is
61 [/artifact/6cb824a0417?ln=196-201 | implemented] using a
62 [https://www.sqlite.org/lang_with.html#recursivecte|recursive common table expression].
63
M www/bugtheory.wiki
+1 -1
--- www/bugtheory.wiki
+++ www/bugtheory.wiki
@@ -27,11 +27,11 @@
2727
 Recall that a fossil repository consists of an
2828
 unordered collection of <i>artifacts</i>. (See the
2929
 <a href="fileformat.wiki">file format document</a> for details.)
3030
 Some artifacts have a special format, and among those are
3131
 <a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>.
32
-One or more ticket change artifacts are associated with each
32
+One or more ticket change artifacts are associated with each
3333
 ticket. A ticket is created by a ticket change artifact.
3434
 Each subsequent modification of the ticket is a separate artifact.
3535
3636
 The "push", "pull", and "sync" algorithms share ticket change artifacts
3737
 between repositories in the same way as every other artifact. In fact,
3838
--- www/bugtheory.wiki
+++ www/bugtheory.wiki
@@ -27,11 +27,11 @@
27 Recall that a fossil repository consists of an
28 unordered collection of <i>artifacts</i>. (See the
29 <a href="fileformat.wiki">file format document</a> for details.)
30 Some artifacts have a special format, and among those are
31 <a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>.
32 One or more ticket change artifacts are associated with each
33 ticket. A ticket is created by a ticket change artifact.
34 Each subsequent modification of the ticket is a separate artifact.
35
36 The "push", "pull", and "sync" algorithms share ticket change artifacts
37 between repositories in the same way as every other artifact. In fact,
38
--- www/bugtheory.wiki
+++ www/bugtheory.wiki
@@ -27,11 +27,11 @@
27 Recall that a fossil repository consists of an
28 unordered collection of <i>artifacts</i>. (See the
29 <a href="fileformat.wiki">file format document</a> for details.)
30 Some artifacts have a special format, and among those are
31 <a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>.
32 One or more ticket change artifacts are associated with each
33 ticket. A ticket is created by a ticket change artifact.
34 Each subsequent modification of the ticket is a separate artifact.
35
36 The "push", "pull", and "sync" algorithms share ticket change artifacts
37 between repositories in the same way as every other artifact. In fact,
38
M www/checkin_names.wiki
+8 -8
--- www/checkin_names.wiki
+++ www/checkin_names.wiki
@@ -55,20 +55,20 @@
5555
 </pre></blockquote>
5656
5757
 The full 40-character SHA1 hash is unwieldy to remember and type, though,
5858
 so Fossil also accepts a unique prefix of the hash, using any combination
5959
 of upper and lower case letters, as long as the prefix is at least 4
60
-characters long. Hence the following commands all
60
+characters long. Hence the following commands all
6161
 accomplish the same thing as the above:
6262
6363
 <blockquote><pre>
6464
 fossil info e5a734a19a9
6565
 fossil info E5a734A
6666
 fossil info e5a7
6767
 </blockquote>
6868
69
-Many web-interface screens identify check-ins by 10- or 16-character
69
+Many web-interface screens identify check-ins by 10- or 16-character
7070
 prefix of canonical name.
7171
7272
 <h2>Tags And Branch Names</h2>
7373
7474
 Using a tag or branch name where a check-in name is expected causes
@@ -112,11 +112,11 @@
112112
113113
 <blockquote><tt>
114114
 fossil info tag:deed2
115115
 </tt></blockquote>
116116
117
-The "tag:deed2" name will refer to the most recent check-in
117
+The "tag:deed2" name will refer to the most recent check-in
118118
 tagged with "deed2" not to the
119119
 check-in whose canonical name begins with "deed2".
120120
121121
 <h2>Whole Branches</h2>
122122
@@ -147,11 +147,11 @@
147147
 * <i>YYYY-MM-DD</i>
148148
 * <i>YYYY-MM-DD HH:MM</i>
149149
 * <i>YYYY-MM-DD HH:MM:SS</i>
150150
 * <i>YYYY-MM-DD HH:MM:SS.SSS</i>
151151
152
-The space between the day and the year can optionally be
152
+The space between the day and the year can optionally be
153153
 replaced by an uppercase <b>T</b> and the entire timestamp can
154154
 optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
155155
 form with fractional seconds, any number of digits may follow the
156156
 decimal point, though due to precision limits only the first three
157157
 digits will be significant.
@@ -161,14 +161,14 @@
161161
 distributed projects where participants are scattered around the globe.
162162
 But there is an option on the Admin/Timeline page of the web-interface to
163163
 switch to local time. The "<b>Z</b>" suffix on a timestamp check-in
164164
 name is meaningless if Fossil is in the default mode of using UTC for
165165
 everything, but if Fossil has been switched to local time mode, then the
166
-"<b>Z</b>" suffix means to interpret that particular timestamp using
166
+"<b>Z</b>" suffix means to interpret that particular timestamp using
167167
 UTC instead of local time.
168168
169
-For an example of how timestamps are useful,
169
+For an example of how timestamps are useful,
170170
 consider the homepage for the Fossil website itself:
171171
172172
 <blockquote>
173173
 http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki
174174
 </blockquote>
@@ -191,11 +191,11 @@
191191
 <blockquote>
192192
 fossil update trunk:2010-07-01T14:30
193193
 </blockquote>
194194
195195
 Would cause Fossil to update the working check-out to be the most recent
196
-check-in on the trunk that is not more recent that 14:30 (UTC) on
196
+check-in on the trunk that is not more recent that 14:30 (UTC) on
197197
 July 1, 2010.
198198
199199
 <h2>Root Of A Branch</h2>
200200
201201
 A branch name that begins with the "<tt>root:</tt>" prefix refers to the
@@ -220,11 +220,11 @@
220220
 current check-out. And the "previous" or "prev" tag means the primary
221221
 (non-merge) parent of the current check-out.
222222
223223
 For embedded documentation, the tag "ckout" means the version as present in
224224
 the local source tree on disk, provided that the web server is started using
225
-"fossil ui" or "fossil server" from within the source tree. This tag can be
225
+"fossil ui" or "fossil server" from within the source tree. This tag can be
226226
 used to preview local changes to documentation before committing them. It does
227227
 not apply to CLI commands.
228228
229229
 <h2>Additional Examples</h2>
230230
231231
--- www/checkin_names.wiki
+++ www/checkin_names.wiki
@@ -55,20 +55,20 @@
55 </pre></blockquote>
56
57 The full 40-character SHA1 hash is unwieldy to remember and type, though,
58 so Fossil also accepts a unique prefix of the hash, using any combination
59 of upper and lower case letters, as long as the prefix is at least 4
60 characters long. Hence the following commands all
61 accomplish the same thing as the above:
62
63 <blockquote><pre>
64 fossil info e5a734a19a9
65 fossil info E5a734A
66 fossil info e5a7
67 </blockquote>
68
69 Many web-interface screens identify check-ins by 10- or 16-character
70 prefix of canonical name.
71
72 <h2>Tags And Branch Names</h2>
73
74 Using a tag or branch name where a check-in name is expected causes
@@ -112,11 +112,11 @@
112
113 <blockquote><tt>
114 fossil info tag:deed2
115 </tt></blockquote>
116
117 The "tag:deed2" name will refer to the most recent check-in
118 tagged with "deed2" not to the
119 check-in whose canonical name begins with "deed2".
120
121 <h2>Whole Branches</h2>
122
@@ -147,11 +147,11 @@
147 * <i>YYYY-MM-DD</i>
148 * <i>YYYY-MM-DD HH:MM</i>
149 * <i>YYYY-MM-DD HH:MM:SS</i>
150 * <i>YYYY-MM-DD HH:MM:SS.SSS</i>
151
152 The space between the day and the year can optionally be
153 replaced by an uppercase <b>T</b> and the entire timestamp can
154 optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
155 form with fractional seconds, any number of digits may follow the
156 decimal point, though due to precision limits only the first three
157 digits will be significant.
@@ -161,14 +161,14 @@
161 distributed projects where participants are scattered around the globe.
162 But there is an option on the Admin/Timeline page of the web-interface to
163 switch to local time. The "<b>Z</b>" suffix on a timestamp check-in
164 name is meaningless if Fossil is in the default mode of using UTC for
165 everything, but if Fossil has been switched to local time mode, then the
166 "<b>Z</b>" suffix means to interpret that particular timestamp using
167 UTC instead of local time.
168
169 For an example of how timestamps are useful,
170 consider the homepage for the Fossil website itself:
171
172 <blockquote>
173 http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki
174 </blockquote>
@@ -191,11 +191,11 @@
191 <blockquote>
192 fossil update trunk:2010-07-01T14:30
193 </blockquote>
194
195 Would cause Fossil to update the working check-out to be the most recent
196 check-in on the trunk that is not more recent that 14:30 (UTC) on
197 July 1, 2010.
198
199 <h2>Root Of A Branch</h2>
200
201 A branch name that begins with the "<tt>root:</tt>" prefix refers to the
@@ -220,11 +220,11 @@
220 current check-out. And the "previous" or "prev" tag means the primary
221 (non-merge) parent of the current check-out.
222
223 For embedded documentation, the tag "ckout" means the version as present in
224 the local source tree on disk, provided that the web server is started using
225 "fossil ui" or "fossil server" from within the source tree. This tag can be
226 used to preview local changes to documentation before committing them. It does
227 not apply to CLI commands.
228
229 <h2>Additional Examples</h2>
230
231
--- www/checkin_names.wiki
+++ www/checkin_names.wiki
@@ -55,20 +55,20 @@
55 </pre></blockquote>
56
57 The full 40-character SHA1 hash is unwieldy to remember and type, though,
58 so Fossil also accepts a unique prefix of the hash, using any combination
59 of upper and lower case letters, as long as the prefix is at least 4
60 characters long. Hence the following commands all
61 accomplish the same thing as the above:
62
63 <blockquote><pre>
64 fossil info e5a734a19a9
65 fossil info E5a734A
66 fossil info e5a7
67 </blockquote>
68
69 Many web-interface screens identify check-ins by 10- or 16-character
70 prefix of canonical name.
71
72 <h2>Tags And Branch Names</h2>
73
74 Using a tag or branch name where a check-in name is expected causes
@@ -112,11 +112,11 @@
112
113 <blockquote><tt>
114 fossil info tag:deed2
115 </tt></blockquote>
116
117 The "tag:deed2" name will refer to the most recent check-in
118 tagged with "deed2" not to the
119 check-in whose canonical name begins with "deed2".
120
121 <h2>Whole Branches</h2>
122
@@ -147,11 +147,11 @@
147 * <i>YYYY-MM-DD</i>
148 * <i>YYYY-MM-DD HH:MM</i>
149 * <i>YYYY-MM-DD HH:MM:SS</i>
150 * <i>YYYY-MM-DD HH:MM:SS.SSS</i>
151
152 The space between the day and the year can optionally be
153 replaced by an uppercase <b>T</b> and the entire timestamp can
154 optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth
155 form with fractional seconds, any number of digits may follow the
156 decimal point, though due to precision limits only the first three
157 digits will be significant.
@@ -161,14 +161,14 @@
161 distributed projects where participants are scattered around the globe.
162 But there is an option on the Admin/Timeline page of the web-interface to
163 switch to local time. The "<b>Z</b>" suffix on a timestamp check-in
164 name is meaningless if Fossil is in the default mode of using UTC for
165 everything, but if Fossil has been switched to local time mode, then the
166 "<b>Z</b>" suffix means to interpret that particular timestamp using
167 UTC instead of local time.
168
169 For an example of how timestamps are useful,
170 consider the homepage for the Fossil website itself:
171
172 <blockquote>
173 http://www.fossil-scm.org/fossil/doc/<b>trunk</b>/www/index.wiki
174 </blockquote>
@@ -191,11 +191,11 @@
191 <blockquote>
192 fossil update trunk:2010-07-01T14:30
193 </blockquote>
194
195 Would cause Fossil to update the working check-out to be the most recent
196 check-in on the trunk that is not more recent that 14:30 (UTC) on
197 July 1, 2010.
198
199 <h2>Root Of A Branch</h2>
200
201 A branch name that begins with the "<tt>root:</tt>" prefix refers to the
@@ -220,11 +220,11 @@
220 current check-out. And the "previous" or "prev" tag means the primary
221 (non-merge) parent of the current check-out.
222
223 For embedded documentation, the tag "ckout" means the version as present in
224 the local source tree on disk, provided that the web server is started using
225 "fossil ui" or "fossil server" from within the source tree. This tag can be
226 used to preview local changes to documentation before committing them. It does
227 not apply to CLI commands.
228
229 <h2>Additional Examples</h2>
230
231
M www/childprojects.wiki
+3 -3
--- www/childprojects.wiki
+++ www/childprojects.wiki
@@ -37,21 +37,21 @@
3737
 VALUES('project-code',lower(hex(randomblob(20))));
3838
 INSERT INTO config(name,value)
3939
 VALUES('project-name','CHILD-PROJECT-NAME');
4040
 </verbatim></blockquote>
4141
42
-Modify the CHILD-PROJECT-NAME in the last statement to be the name of
42
+Modify the CHILD-PROJECT-NAME in the last statement to be the name of
4343
 the child project, of course.
4444
4545
 The repository is now a separate project, independent from its parent.
4646
 Clone the new project to the developers as needed.
4747
4848
 The child project and the parent project will not normally be able to sync
4949
 with one another, since they are now separate projects with distinct
5050
 project codes. However, if the
51
-"--from-parent-project" command-line option is provided to the
52
-"[/help?cmd=pull|fossil pull]" command in the child, and the URL of
51
+"--from-parent-project" command-line option is provided to the
52
+"[/help?cmd=pull|fossil pull]" command in the child, and the URL of
5353
 parent repository is also provided on the command-line, then updates to
5454
 the parent project that occurred after the child was created will be added
5555
 to the child repository. Thus, by periodically doing a
5656
 pull --from-parent-project, the child project is able to stay up to date
5757
 with all the latest changes in the parent.
5858
--- www/childprojects.wiki
+++ www/childprojects.wiki
@@ -37,21 +37,21 @@
37 VALUES('project-code',lower(hex(randomblob(20))));
38 INSERT INTO config(name,value)
39 VALUES('project-name','CHILD-PROJECT-NAME');
40 </verbatim></blockquote>
41
42 Modify the CHILD-PROJECT-NAME in the last statement to be the name of
43 the child project, of course.
44
45 The repository is now a separate project, independent from its parent.
46 Clone the new project to the developers as needed.
47
48 The child project and the parent project will not normally be able to sync
49 with one another, since they are now separate projects with distinct
50 project codes. However, if the
51 "--from-parent-project" command-line option is provided to the
52 "[/help?cmd=pull|fossil pull]" command in the child, and the URL of
53 parent repository is also provided on the command-line, then updates to
54 the parent project that occurred after the child was created will be added
55 to the child repository. Thus, by periodically doing a
56 pull --from-parent-project, the child project is able to stay up to date
57 with all the latest changes in the parent.
58
--- www/childprojects.wiki
+++ www/childprojects.wiki
@@ -37,21 +37,21 @@
37 VALUES('project-code',lower(hex(randomblob(20))));
38 INSERT INTO config(name,value)
39 VALUES('project-name','CHILD-PROJECT-NAME');
40 </verbatim></blockquote>
41
42 Modify the CHILD-PROJECT-NAME in the last statement to be the name of
43 the child project, of course.
44
45 The repository is now a separate project, independent from its parent.
46 Clone the new project to the developers as needed.
47
48 The child project and the parent project will not normally be able to sync
49 with one another, since they are now separate projects with distinct
50 project codes. However, if the
51 "--from-parent-project" command-line option is provided to the
52 "[/help?cmd=pull|fossil pull]" command in the child, and the URL of
53 parent repository is also provided on the command-line, then updates to
54 the parent project that occurred after the child was created will be added
55 to the child repository. Thus, by periodically doing a
56 pull --from-parent-project, the child project is able to stay up to date
57 with all the latest changes in the parent.
58
M www/concepts.wiki
+8 -8
--- www/concepts.wiki
+++ www/concepts.wiki
@@ -131,11 +131,11 @@
131131
 <h3>2.2 Manifests</h3>
132132
133133
 Associated with every check-in is a special file called the
134134
 [./fileformat.wiki#manifest| "manifest"]. The manifest is a
135135
 listing of all other files in
136
-that source tree. The manifest contains the (complete) artifact ID
136
+that source tree. The manifest contains the (complete) artifact ID
137137
 of the file and the name of the file as it appears on disk,
138138
 and thus serves as a mapping from artifact ID to disk name. The artifact ID
139139
 of the manifest is the identifier for the entire check-in. When
140140
 you look at a "timeline" of changes in Fossil, the ID associated
141141
 with each check-in or commit is really just the artifact ID of the
@@ -147,11 +147,11 @@
147147
 manifest file to be materialized to disk, if desired. Both Fossil
148148
 itself, and SQLite cause the manifest file to be materialized to disk
149149
 so that the makefiles for these project can read the manifest and
150150
 embed version information in generated binaries.
151151
152
-<p>Fossil automatically generates a manifest whenever you "commit"
152
+<p>Fossil automatically generates a manifest whenever you "commit"
153153
 a new check-in. So this is not something that you, the developer,
154154
 need to worry with. The format of a manifest is intentionally
155155
 designed to be simple to parse, so that if
156156
 you want to read and interpret a manifest, either by hand or
157157
 with a script, that is easy to do. But you will probably never
@@ -200,11 +200,11 @@
200200
 Fossil effectively. You will want to have some kind of text editor
201201
 for entering check-in comments. Fossil will use whatever text editor
202202
 is identified by your VISUAL environment variable. Fossil will also
203203
 use GPG to clearsign your manifests if you happen to have it installed,
204204
 but Fossil will skip that step if GPG missing from your system.
205
-You can optionally set up Fossil to use external "diff" programs,
205
+You can optionally set up Fossil to use external "diff" programs,
206206
 though Fossil has an excellent built-in "diff" algorithm that works
207207
 fine for most people. If you happen to have Tcl/Tk installed on your
208208
 system, Fossil will use it to generate a graphical "diff" display when
209209
 you use the --tk option to the "diff" command, but this too is entirely
210210
 optional.
@@ -211,11 +211,11 @@
211211
212212
213213
 To uninstall Fossil, simply delete the executable.
214214
215215
 To upgrade an older version of Fossil to a newer version, just
216
-replace the old executable with the new one. You might need to
216
+replace the old executable with the new one. You might need to
217217
 run "<b>fossil all rebuild</b>" to restructure your repositories after
218218
 an upgrade. Running "all rebuild" never hurts, so when upgrading it
219219
 is a good policy to run it even if it is not strictly necessary.
220220
221221
 To use Fossil, simply type the name of the executable in your
@@ -266,11 +266,11 @@
266266
267267
 <ol>
268268
 <li>
269269
 Establish a local repository using either the <b>new</b> command
270270
 to start a new project, or the <b>clone</b> command to make a clone
271
-of a repository for an existing project.
271
+of a repository for an existing project.
272272
 </li>
273273
274274
 <li>
275275
 Establish one or more source trees using
276276
 the <b>open</b> command with the name of the repository file as its
@@ -279,11 +279,11 @@
279279
280280
 <li>
281281
 The <b>open</b> command in the previous step populates your local source
282282
 tree with a copy of the latest check-in. Usually this is what you want.
283283
 In the rare cases where it is not, use the <b>update</b> command to
284
-switch to a different check-in.
284
+switch to a different check-in.
285285
 Use the <b>timeline</b> or <b>leaves</b> commands
286286
 to identify alternative check-ins to switch to.
287287
 </li>
288288
289289
 <li>
@@ -302,17 +302,17 @@
302302
 you cloned from or whatever server you most recently synced with.
303303
 </li>
304304
305305
 <li>
306306
 When your coworkers make their own changes, you can merge those changes
307
-into your local local source tree using the <b>update</b> command.
307
+into your local local source tree using the <b>update</b> command.
308308
 In autosync mode, <b>update</b> will first go back to the server you
309309
 cloned from or with which you most recently synced, and pull down all
310310
 recent changes into your local repository. Then it will merge recent
311311
 changes into your local source tree. If you do an <b>update</b> and
312312
 find that it messes something up in your source tree (perhaps a co-worker
313
-checked in incompatible changes) you can use the <b>undo</b> command
313
+checked in incompatible changes) you can use the <b>undo</b> command
314314
 to back out the changes.
315315
 </li>
316316
317317
 <li>
318318
 Repeat all of the above until you have generated great software.
319319
--- www/concepts.wiki
+++ www/concepts.wiki
@@ -131,11 +131,11 @@
131 <h3>2.2 Manifests</h3>
132
133 Associated with every check-in is a special file called the
134 [./fileformat.wiki#manifest| "manifest"]. The manifest is a
135 listing of all other files in
136 that source tree. The manifest contains the (complete) artifact ID
137 of the file and the name of the file as it appears on disk,
138 and thus serves as a mapping from artifact ID to disk name. The artifact ID
139 of the manifest is the identifier for the entire check-in. When
140 you look at a "timeline" of changes in Fossil, the ID associated
141 with each check-in or commit is really just the artifact ID of the
@@ -147,11 +147,11 @@
147 manifest file to be materialized to disk, if desired. Both Fossil
148 itself, and SQLite cause the manifest file to be materialized to disk
149 so that the makefiles for these project can read the manifest and
150 embed version information in generated binaries.
151
152 <p>Fossil automatically generates a manifest whenever you "commit"
153 a new check-in. So this is not something that you, the developer,
154 need to worry with. The format of a manifest is intentionally
155 designed to be simple to parse, so that if
156 you want to read and interpret a manifest, either by hand or
157 with a script, that is easy to do. But you will probably never
@@ -200,11 +200,11 @@
200 Fossil effectively. You will want to have some kind of text editor
201 for entering check-in comments. Fossil will use whatever text editor
202 is identified by your VISUAL environment variable. Fossil will also
203 use GPG to clearsign your manifests if you happen to have it installed,
204 but Fossil will skip that step if GPG missing from your system.
205 You can optionally set up Fossil to use external "diff" programs,
206 though Fossil has an excellent built-in "diff" algorithm that works
207 fine for most people. If you happen to have Tcl/Tk installed on your
208 system, Fossil will use it to generate a graphical "diff" display when
209 you use the --tk option to the "diff" command, but this too is entirely
210 optional.
@@ -211,11 +211,11 @@
211
212
213 To uninstall Fossil, simply delete the executable.
214
215 To upgrade an older version of Fossil to a newer version, just
216 replace the old executable with the new one. You might need to
217 run "<b>fossil all rebuild</b>" to restructure your repositories after
218 an upgrade. Running "all rebuild" never hurts, so when upgrading it
219 is a good policy to run it even if it is not strictly necessary.
220
221 To use Fossil, simply type the name of the executable in your
@@ -266,11 +266,11 @@
266
267 <ol>
268 <li>
269 Establish a local repository using either the <b>new</b> command
270 to start a new project, or the <b>clone</b> command to make a clone
271 of a repository for an existing project.
272 </li>
273
274 <li>
275 Establish one or more source trees using
276 the <b>open</b> command with the name of the repository file as its
@@ -279,11 +279,11 @@
279
280 <li>
281 The <b>open</b> command in the previous step populates your local source
282 tree with a copy of the latest check-in. Usually this is what you want.
283 In the rare cases where it is not, use the <b>update</b> command to
284 switch to a different check-in.
285 Use the <b>timeline</b> or <b>leaves</b> commands
286 to identify alternative check-ins to switch to.
287 </li>
288
289 <li>
@@ -302,17 +302,17 @@
302 you cloned from or whatever server you most recently synced with.
303 </li>
304
305 <li>
306 When your coworkers make their own changes, you can merge those changes
307 into your local local source tree using the <b>update</b> command.
308 In autosync mode, <b>update</b> will first go back to the server you
309 cloned from or with which you most recently synced, and pull down all
310 recent changes into your local repository. Then it will merge recent
311 changes into your local source tree. If you do an <b>update</b> and
312 find that it messes something up in your source tree (perhaps a co-worker
313 checked in incompatible changes) you can use the <b>undo</b> command
314 to back out the changes.
315 </li>
316
317 <li>
318 Repeat all of the above until you have generated great software.
319
--- www/concepts.wiki
+++ www/concepts.wiki
@@ -131,11 +131,11 @@
131 <h3>2.2 Manifests</h3>
132
133 Associated with every check-in is a special file called the
134 [./fileformat.wiki#manifest| "manifest"]. The manifest is a
135 listing of all other files in
136 that source tree. The manifest contains the (complete) artifact ID
137 of the file and the name of the file as it appears on disk,
138 and thus serves as a mapping from artifact ID to disk name. The artifact ID
139 of the manifest is the identifier for the entire check-in. When
140 you look at a "timeline" of changes in Fossil, the ID associated
141 with each check-in or commit is really just the artifact ID of the
@@ -147,11 +147,11 @@
147 manifest file to be materialized to disk, if desired. Both Fossil
148 itself, and SQLite cause the manifest file to be materialized to disk
149 so that the makefiles for these project can read the manifest and
150 embed version information in generated binaries.
151
152 <p>Fossil automatically generates a manifest whenever you "commit"
153 a new check-in. So this is not something that you, the developer,
154 need to worry with. The format of a manifest is intentionally
155 designed to be simple to parse, so that if
156 you want to read and interpret a manifest, either by hand or
157 with a script, that is easy to do. But you will probably never
@@ -200,11 +200,11 @@
200 Fossil effectively. You will want to have some kind of text editor
201 for entering check-in comments. Fossil will use whatever text editor
202 is identified by your VISUAL environment variable. Fossil will also
203 use GPG to clearsign your manifests if you happen to have it installed,
204 but Fossil will skip that step if GPG missing from your system.
205 You can optionally set up Fossil to use external "diff" programs,
206 though Fossil has an excellent built-in "diff" algorithm that works
207 fine for most people. If you happen to have Tcl/Tk installed on your
208 system, Fossil will use it to generate a graphical "diff" display when
209 you use the --tk option to the "diff" command, but this too is entirely
210 optional.
@@ -211,11 +211,11 @@
211
212
213 To uninstall Fossil, simply delete the executable.
214
215 To upgrade an older version of Fossil to a newer version, just
216 replace the old executable with the new one. You might need to
217 run "<b>fossil all rebuild</b>" to restructure your repositories after
218 an upgrade. Running "all rebuild" never hurts, so when upgrading it
219 is a good policy to run it even if it is not strictly necessary.
220
221 To use Fossil, simply type the name of the executable in your
@@ -266,11 +266,11 @@
266
267 <ol>
268 <li>
269 Establish a local repository using either the <b>new</b> command
270 to start a new project, or the <b>clone</b> command to make a clone
271 of a repository for an existing project.
272 </li>
273
274 <li>
275 Establish one or more source trees using
276 the <b>open</b> command with the name of the repository file as its
@@ -279,11 +279,11 @@
279
280 <li>
281 The <b>open</b> command in the previous step populates your local source
282 tree with a copy of the latest check-in. Usually this is what you want.
283 In the rare cases where it is not, use the <b>update</b> command to
284 switch to a different check-in.
285 Use the <b>timeline</b> or <b>leaves</b> commands
286 to identify alternative check-ins to switch to.
287 </li>
288
289 <li>
@@ -302,17 +302,17 @@
302 you cloned from or whatever server you most recently synced with.
303 </li>
304
305 <li>
306 When your coworkers make their own changes, you can merge those changes
307 into your local local source tree using the <b>update</b> command.
308 In autosync mode, <b>update</b> will first go back to the server you
309 cloned from or with which you most recently synced, and pull down all
310 recent changes into your local repository. Then it will merge recent
311 changes into your local source tree. If you do an <b>update</b> and
312 find that it messes something up in your source tree (perhaps a co-worker
313 checked in incompatible changes) you can use the <b>undo</b> command
314 to back out the changes.
315 </li>
316
317 <li>
318 Repeat all of the above until you have generated great software.
319
M www/contribute.wiki
+7 -7
--- www/contribute.wiki
+++ www/contribute.wiki
@@ -10,11 +10,11 @@
1010
 [./copyright-release.pdf | Contributor Agreement (PDF)]
1111
 (or [./copyright-release.html | as HTML]) on file for you. We require
1212
 this in order to maintain clear title to the Fossil code and prevent
1313
 the introduction of code with incompatible licenses or other entanglements
1414
 that might cause legal problems for Fossil users. Many larger companies
15
-and other lawyer-rich organizations require this as a precondition to using
15
+and other lawyer-rich organizations require this as a precondition to using
1616
 Fossil.
1717
1818
 If you do not wish to submit a Contributor Agreement, we would still
1919
 welcome your suggestions and example code, but we will not use your code
2020
 directly - we will be forced to re-implement your changes from scratch which
@@ -21,14 +21,14 @@
2121
 might take longer.
2222
2323
 <h2>2.0 Submitting Patches</h2>
2424
2525
 Suggested changes or bug fixes can be submitted by creating a patch
26
-against the current source tree. Email patches to
27
-<a href="mailto:[email protected]">[email protected]</a>. Be sure to
26
+against the current source tree. Email patches to
27
+<a href="mailto:[email protected]">[email protected]</a>. Be sure to
2828
 describe in detail what the patch does and which version of Fossil
29
-it is written against.
29
+it is written against.
3030
3131
 A contributor agreement is not strictly necessary to submit a patch.
3232
 However, without a contributor agreement on file, your patch will be
3333
 used for reference only - it will not be applied to the code. This
3434
 may delay acceptance of your patch.
@@ -53,23 +53,23 @@
5353
 Fossil Architect (Richard Hipp) will merge changes onto the trunk.</p>
5454
5555
 Contributors are required to following the
5656
 [./checkin.wiki | pre-checkin checklist] prior to every check-in to
5757
 the Fossil self-hosting repository. This checklist is short and succinct
58
-and should only require a few seconds to follow. Contributors
58
+and should only require a few seconds to follow. Contributors
5959
 should print out a copy of the pre-checkin checklist and keep
6060
 it on a notecard beside their workstations, for quick reference.
6161
6262
 Contributors should review the
6363
 [./style.wiki | Coding Style Guidelines] and mimic the coding style
6464
 used through the rest of the Fossil source code. Your code should
6565
 blend in. A third-party reader should be unable to distinguish your
66
-code from any other code in the source corpus.
66
+code from any other code in the source corpus.
6767
6868
 <h2>4.0 Testing</h2>
6969
70
-Fossil has the beginnings of a
70
+Fossil has the beginnings of a
7171
 [../test/release-checklist.wiki | release checklist] but this is an
7272
 area that needs further work. (Your contributions here are welcomed!)
7373
 Contributors with check-in privileges are expected to run the release
7474
 checklist on any major changes they contribute, and if appropriate expand
7575
 the checklist and/or the automated test scripts to cover their additions.
7676
--- www/contribute.wiki
+++ www/contribute.wiki
@@ -10,11 +10,11 @@
10 [./copyright-release.pdf | Contributor Agreement (PDF)]
11 (or [./copyright-release.html | as HTML]) on file for you. We require
12 this in order to maintain clear title to the Fossil code and prevent
13 the introduction of code with incompatible licenses or other entanglements
14 that might cause legal problems for Fossil users. Many larger companies
15 and other lawyer-rich organizations require this as a precondition to using
16 Fossil.
17
18 If you do not wish to submit a Contributor Agreement, we would still
19 welcome your suggestions and example code, but we will not use your code
20 directly - we will be forced to re-implement your changes from scratch which
@@ -21,14 +21,14 @@
21 might take longer.
22
23 <h2>2.0 Submitting Patches</h2>
24
25 Suggested changes or bug fixes can be submitted by creating a patch
26 against the current source tree. Email patches to
27 <a href="mailto:[email protected]">[email protected]</a>. Be sure to
28 describe in detail what the patch does and which version of Fossil
29 it is written against.
30
31 A contributor agreement is not strictly necessary to submit a patch.
32 However, without a contributor agreement on file, your patch will be
33 used for reference only - it will not be applied to the code. This
34 may delay acceptance of your patch.
@@ -53,23 +53,23 @@
53 Fossil Architect (Richard Hipp) will merge changes onto the trunk.</p>
54
55 Contributors are required to following the
56 [./checkin.wiki | pre-checkin checklist] prior to every check-in to
57 the Fossil self-hosting repository. This checklist is short and succinct
58 and should only require a few seconds to follow. Contributors
59 should print out a copy of the pre-checkin checklist and keep
60 it on a notecard beside their workstations, for quick reference.
61
62 Contributors should review the
63 [./style.wiki | Coding Style Guidelines] and mimic the coding style
64 used through the rest of the Fossil source code. Your code should
65 blend in. A third-party reader should be unable to distinguish your
66 code from any other code in the source corpus.
67
68 <h2>4.0 Testing</h2>
69
70 Fossil has the beginnings of a
71 [../test/release-checklist.wiki | release checklist] but this is an
72 area that needs further work. (Your contributions here are welcomed!)
73 Contributors with check-in privileges are expected to run the release
74 checklist on any major changes they contribute, and if appropriate expand
75 the checklist and/or the automated test scripts to cover their additions.
76
--- www/contribute.wiki
+++ www/contribute.wiki
@@ -10,11 +10,11 @@
10 [./copyright-release.pdf | Contributor Agreement (PDF)]
11 (or [./copyright-release.html | as HTML]) on file for you. We require
12 this in order to maintain clear title to the Fossil code and prevent
13 the introduction of code with incompatible licenses or other entanglements
14 that might cause legal problems for Fossil users. Many larger companies
15 and other lawyer-rich organizations require this as a precondition to using
16 Fossil.
17
18 If you do not wish to submit a Contributor Agreement, we would still
19 welcome your suggestions and example code, but we will not use your code
20 directly - we will be forced to re-implement your changes from scratch which
@@ -21,14 +21,14 @@
21 might take longer.
22
23 <h2>2.0 Submitting Patches</h2>
24
25 Suggested changes or bug fixes can be submitted by creating a patch
26 against the current source tree. Email patches to
27 <a href="mailto:[email protected]">[email protected]</a>. Be sure to
28 describe in detail what the patch does and which version of Fossil
29 it is written against.
30
31 A contributor agreement is not strictly necessary to submit a patch.
32 However, without a contributor agreement on file, your patch will be
33 used for reference only - it will not be applied to the code. This
34 may delay acceptance of your patch.
@@ -53,23 +53,23 @@
53 Fossil Architect (Richard Hipp) will merge changes onto the trunk.</p>
54
55 Contributors are required to following the
56 [./checkin.wiki | pre-checkin checklist] prior to every check-in to
57 the Fossil self-hosting repository. This checklist is short and succinct
58 and should only require a few seconds to follow. Contributors
59 should print out a copy of the pre-checkin checklist and keep
60 it on a notecard beside their workstations, for quick reference.
61
62 Contributors should review the
63 [./style.wiki | Coding Style Guidelines] and mimic the coding style
64 used through the rest of the Fossil source code. Your code should
65 blend in. A third-party reader should be unable to distinguish your
66 code from any other code in the source corpus.
67
68 <h2>4.0 Testing</h2>
69
70 Fossil has the beginnings of a
71 [../test/release-checklist.wiki | release checklist] but this is an
72 area that needs further work. (Your contributions here are welcomed!)
73 Contributors with check-in privileges are expected to run the release
74 checklist on any major changes they contribute, and if appropriate expand
75 the checklist and/or the automated test scripts to cover their additions.
76
M www/custom_ticket.wiki
+2 -2
--- www/custom_ticket.wiki
+++ www/custom_ticket.wiki
@@ -65,11 +65,11 @@
6565
 &lt;/tr>
6666
 &lt;th1>enable_output 1&lt;/th1>
6767
 </pre>
6868
 This bit of code will get rid of the "email" field entry for logged-in users.
6969
 Since we know the user's information, we don't have to ask for it. NOTE: it
70
-might be good to automatically scoop up the user's email and put it here.
70
+might be good to automatically scoop up the user's email and put it here.
7171
 </p>
7272
 </blockquote>
7373
7474
 <h2>Modify the 'view ticket' page</h2><blockquote>
7575
 <p>
@@ -83,11 +83,11 @@
8383
 &lt;td align="right">Opened by:&lt;/td>&lt;td bgcolor="#d0d0d0">
8484
 $&lt;opened_by>
8585
 &lt;/td>
8686
 </pre>
8787
 This will add a row which displays these two fields, in the event the user has
88
-"edit" capability.
88
+"edit" capability.
8989
 </p>
9090
 </blockquote>
9191
9292
 <h2>Modify the 'edit ticket' page</h2><blockquote>
9393
 <p>
9494
--- www/custom_ticket.wiki
+++ www/custom_ticket.wiki
@@ -65,11 +65,11 @@
65 &lt;/tr>
66 &lt;th1>enable_output 1&lt;/th1>
67 </pre>
68 This bit of code will get rid of the "email" field entry for logged-in users.
69 Since we know the user's information, we don't have to ask for it. NOTE: it
70 might be good to automatically scoop up the user's email and put it here.
71 </p>
72 </blockquote>
73
74 <h2>Modify the 'view ticket' page</h2><blockquote>
75 <p>
@@ -83,11 +83,11 @@
83 &lt;td align="right">Opened by:&lt;/td>&lt;td bgcolor="#d0d0d0">
84 $&lt;opened_by>
85 &lt;/td>
86 </pre>
87 This will add a row which displays these two fields, in the event the user has
88 "edit" capability.
89 </p>
90 </blockquote>
91
92 <h2>Modify the 'edit ticket' page</h2><blockquote>
93 <p>
94
--- www/custom_ticket.wiki
+++ www/custom_ticket.wiki
@@ -65,11 +65,11 @@
65 &lt;/tr>
66 &lt;th1>enable_output 1&lt;/th1>
67 </pre>
68 This bit of code will get rid of the "email" field entry for logged-in users.
69 Since we know the user's information, we don't have to ask for it. NOTE: it
70 might be good to automatically scoop up the user's email and put it here.
71 </p>
72 </blockquote>
73
74 <h2>Modify the 'view ticket' page</h2><blockquote>
75 <p>
@@ -83,11 +83,11 @@
83 &lt;td align="right">Opened by:&lt;/td>&lt;td bgcolor="#d0d0d0">
84 $&lt;opened_by>
85 &lt;/td>
86 </pre>
87 This will add a row which displays these two fields, in the event the user has
88 "edit" capability.
89 </p>
90 </blockquote>
91
92 <h2>Modify the 'edit ticket' page</h2><blockquote>
93 <p>
94
M www/delta_encoder_algorithm.wiki
+1 -1
--- www/delta_encoder_algorithm.wiki
+++ www/delta_encoder_algorithm.wiki
@@ -153,11 +153,11 @@
153153
 byte forward. The "base" is left unchanged in that case.</p>
154154
155155
 <p>The processing loop stops at one of two conditions:
156156
 <ol>
157157
 <li>The encoder decided to move the window forward, but the end of the
158
-window reached the end of the "target".
158
+window reached the end of the "target".
159159
 </li>
160160
 <li>After the emission of instructions the new "base" location is
161161
 within NHASH bytes of end of the "target", i.e. there are no more than
162162
 at most NHASH bytes left.
163163
 </li>
164164
--- www/delta_encoder_algorithm.wiki
+++ www/delta_encoder_algorithm.wiki
@@ -153,11 +153,11 @@
153 byte forward. The "base" is left unchanged in that case.</p>
154
155 <p>The processing loop stops at one of two conditions:
156 <ol>
157 <li>The encoder decided to move the window forward, but the end of the
158 window reached the end of the "target".
159 </li>
160 <li>After the emission of instructions the new "base" location is
161 within NHASH bytes of end of the "target", i.e. there are no more than
162 at most NHASH bytes left.
163 </li>
164
--- www/delta_encoder_algorithm.wiki
+++ www/delta_encoder_algorithm.wiki
@@ -153,11 +153,11 @@
153 byte forward. The "base" is left unchanged in that case.</p>
154
155 <p>The processing loop stops at one of two conditions:
156 <ol>
157 <li>The encoder decided to move the window forward, but the end of the
158 window reached the end of the "target".
159 </li>
160 <li>After the emission of instructions the new "base" location is
161 within NHASH bytes of end of the "target", i.e. there are no more than
162 at most NHASH bytes left.
163 </li>
164
M www/delta_format.wiki
+9 -9
--- www/delta_format.wiki
+++ www/delta_format.wiki
@@ -161,49 +161,49 @@
161161
 </table>
162162
163163
 <p>The unified diff behind the above delta is</p>
164164
165165
 <table border=1><tr><td><pre>
166
-bluepeak:(761) ~/Projects/Tcl/Fossil/Devel/devel > diff -u ../DELTA/old ../DELTA/new
166
+bluepeak:(761) ~/Projects/Tcl/Fossil/Devel/devel > diff -u ../DELTA/old ../DELTA/new
167167
 --- ../DELTA/old 2007-08-23 21:14:40.000000000 -0700
168168
 +++ ../DELTA/new 2007-08-23 21:14:33.000000000 -0700
169169
 @@ -5,7 +5,7 @@
170
-
170
+
171171
 * If the server does not have write permission on the database
172
- file, or on the directory containing the database file (and
172
+ file, or on the directory containing the database file (and
173173
 - it is thus unable to update database because it cannot create
174174
 + it is thus unable to update the database because it cannot create
175175
 a rollback journal) then it currently fails silently on a push.
176176
 It needs to return a helpful error.
177
-
177
+
178178
 @@ -27,8 +27,8 @@
179179
 * Additional information displayed for the "vinfo" page:
180
-
180
+
181181
 + All leaves of this version that are not included in the
182182
 - descendant list. With date, user, comment, and hyperlink.
183183
 - Leaves in the descendant table should be marked as such.
184184
 + descendant list. With date, user, comment, and hyperlink.
185185
 + Leaves in the descendant table should be marked as such.
186186
 See the compute_leaves() function to see how to find all
187187
 leaves.
188188
 + Add file diff links to the file change list.
189189
 @@ -37,7 +37,7 @@
190
-
190
+
191191
 * The /xfer handler (for push, pull, and clone) does not do
192192
 delta compression. This results in excess bandwidth usage.
193193
 - There are some code in xfer.c that are sketches of ideas on
194194
 + There are some pieces in xfer.c that are sketches of ideas on
195195
 how to do delta compression, but nothing has been implemented.
196
-
196
+
197197
 * Enhancements to the diff and tkdiff commands in the cli.
198198
 @@ -45,7 +45,7 @@
199199
 single file. Allow diffs against any two arbitrary versions,
200
- not just diffs against the current check-out. Allow
200
+ not just diffs against the current check-out. Allow
201201
 configuration options to replace tkdiff with some other
202202
 - visual differ of the users choice.
203203
 + visual differ of the users choice. Example: eskil.
204
-
204
+
205205
 * Ticketing interface (expand this bullet)
206206
207207
 </pre></td></tr></table>
208208
209209
210210
--- www/delta_format.wiki
+++ www/delta_format.wiki
@@ -161,49 +161,49 @@
161 </table>
162
163 <p>The unified diff behind the above delta is</p>
164
165 <table border=1><tr><td><pre>
166 bluepeak:(761) ~/Projects/Tcl/Fossil/Devel/devel > diff -u ../DELTA/old ../DELTA/new
167 --- ../DELTA/old 2007-08-23 21:14:40.000000000 -0700
168 +++ ../DELTA/new 2007-08-23 21:14:33.000000000 -0700
169 @@ -5,7 +5,7 @@
170
171 * If the server does not have write permission on the database
172 file, or on the directory containing the database file (and
173 - it is thus unable to update database because it cannot create
174 + it is thus unable to update the database because it cannot create
175 a rollback journal) then it currently fails silently on a push.
176 It needs to return a helpful error.
177
178 @@ -27,8 +27,8 @@
179 * Additional information displayed for the "vinfo" page:
180
181 + All leaves of this version that are not included in the
182 - descendant list. With date, user, comment, and hyperlink.
183 - Leaves in the descendant table should be marked as such.
184 + descendant list. With date, user, comment, and hyperlink.
185 + Leaves in the descendant table should be marked as such.
186 See the compute_leaves() function to see how to find all
187 leaves.
188 + Add file diff links to the file change list.
189 @@ -37,7 +37,7 @@
190
191 * The /xfer handler (for push, pull, and clone) does not do
192 delta compression. This results in excess bandwidth usage.
193 - There are some code in xfer.c that are sketches of ideas on
194 + There are some pieces in xfer.c that are sketches of ideas on
195 how to do delta compression, but nothing has been implemented.
196
197 * Enhancements to the diff and tkdiff commands in the cli.
198 @@ -45,7 +45,7 @@
199 single file. Allow diffs against any two arbitrary versions,
200 not just diffs against the current check-out. Allow
201 configuration options to replace tkdiff with some other
202 - visual differ of the users choice.
203 + visual differ of the users choice. Example: eskil.
204
205 * Ticketing interface (expand this bullet)
206
207 </pre></td></tr></table>
208
209
210
--- www/delta_format.wiki
+++ www/delta_format.wiki
@@ -161,49 +161,49 @@
161 </table>
162
163 <p>The unified diff behind the above delta is</p>
164
165 <table border=1><tr><td><pre>
166 bluepeak:(761) ~/Projects/Tcl/Fossil/Devel/devel > diff -u ../DELTA/old ../DELTA/new
167 --- ../DELTA/old 2007-08-23 21:14:40.000000000 -0700
168 +++ ../DELTA/new 2007-08-23 21:14:33.000000000 -0700
169 @@ -5,7 +5,7 @@
170
171 * If the server does not have write permission on the database
172 file, or on the directory containing the database file (and
173 - it is thus unable to update database because it cannot create
174 + it is thus unable to update the database because it cannot create
175 a rollback journal) then it currently fails silently on a push.
176 It needs to return a helpful error.
177
178 @@ -27,8 +27,8 @@
179 * Additional information displayed for the "vinfo" page:
180
181 + All leaves of this version that are not included in the
182 - descendant list. With date, user, comment, and hyperlink.
183 - Leaves in the descendant table should be marked as such.
184 + descendant list. With date, user, comment, and hyperlink.
185 + Leaves in the descendant table should be marked as such.
186 See the compute_leaves() function to see how to find all
187 leaves.
188 + Add file diff links to the file change list.
189 @@ -37,7 +37,7 @@
190
191 * The /xfer handler (for push, pull, and clone) does not do
192 delta compression. This results in excess bandwidth usage.
193 - There are some code in xfer.c that are sketches of ideas on
194 + There are some pieces in xfer.c that are sketches of ideas on
195 how to do delta compression, but nothing has been implemented.
196
197 * Enhancements to the diff and tkdiff commands in the cli.
198 @@ -45,7 +45,7 @@
199 single file. Allow diffs against any two arbitrary versions,
200 not just diffs against the current check-out. Allow
201 configuration options to replace tkdiff with some other
202 - visual differ of the users choice.
203 + visual differ of the users choice. Example: eskil.
204
205 * Ticketing interface (expand this bullet)
206
207 </pre></td></tr></table>
208
209
210
M www/embeddeddoc.wiki
+9 -9
--- www/embeddeddoc.wiki
+++ www/embeddeddoc.wiki
@@ -42,13 +42,13 @@
4242
 <b>http://www.hwaci.com/cgi-bin/fossil</b>.
4343
 If you launch the web server using the "<b>fossil server</b>" command line,
4444
 then the <i>&lt;baseurl&gt;</i> is usually
4545
 <b>http://localhost:8080/</b>.
4646
47
-The <i>&lt;version&gt;</i> is any unique prefix of the check-in ID for
47
+The <i>&lt;version&gt;</i> is any unique prefix of the check-in ID for
4848
 the check-in containing the documentation you want to access.
49
-Or <i>&lt;version&gt;</i> can be the name of a
49
+Or <i>&lt;version&gt;</i> can be the name of a
5050
 [./branching.wiki | branch] in order to show
5151
 the documentation for the latest version of that branch.
5252
 Or <i>&lt;version&gt;</i> can be one of the keywords "<b>tip</b>" or
5353
 "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recent
5454
 check-in. This is useful if you want to see the very latest
@@ -62,30 +62,30 @@
6262
6363
 Finally, the <i>&lt;filename&gt;</i> element of the URL is the
6464
 pathname of the documentation file relative to the root of the source
6565
 tree.
6666
67
-The mimetype (and thus the rendering) of documentation files is
68
-determined by the file suffix. Fossil currently understands
67
+The mimetype (and thus the rendering) of documentation files is
68
+determined by the file suffix. Fossil currently understands
6969
 [/mimetype_list|many different file suffixes],
7070
 including all the popular ones such as ".css", ".gif", ".htm",
7171
 ".html", ".jpg", ".jpeg", ".png", and ".txt".
7272
73
-Documentation files whose names end in ".wiki" use the
73
+Documentation files whose names end in ".wiki" use the
7474
 [/wiki_rules | fossil wiki markup] -
7575
 a safe subset of HTML together with some wiki rules for paragraph
76
-breaks, lists, and hyperlinks.
76
+breaks, lists, and hyperlinks.
7777
 Documentation files ending in ".md" or ".markdown" use the
7878
 [/md_rules | Markdown markup langauge].
7979
 Documentation files ending in ".txt" are plain text.
8080
 Wiki, markdown, and plain text documentation files
8181
 are rendered with the standard fossil header and footer added.
8282
 Most other mimetypes are delivered directly to the requesting
8383
 web browser without interpretation, additions, or changes.
8484
8585
 Files with the mimetype "text/html" (the .html or .htm suffix) are
86
-usually rendered directly to the browser without interpretation.
86
+usually rendered directly to the browser without interpretation.
8787
 However, if the file begins with a &lt;div&gt; element like this:
8888
8989
 <b>&lt;div class='fossil-doc' data-title='<i>Title Text</i>'&gt;</b>
9090
9191
 Then the standard Fossil header and footer are added to the document
@@ -117,11 +117,11 @@
117117
 <blockquote><pre>
118118
 #!/usr/bin/fossil
119119
 repository: /fossil/fossil.fossil
120120
 </pre></blockquote>
121121
122
-This is one of four ways to set up a
122
+This is one of four ways to set up a
123123
 <a href="./server.wiki">fossil web server</a>.
124124
125125
 The "<b>/trunk/</b>" part of the URL tells fossil to use
126126
 the documentation files from the most recent trunk check-in.
127127
 If you wanted to see an historical version of this document,
@@ -138,11 +138,11 @@
138138
 <li> <i>YYYY-MM-DD</i>
139139
 <li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM</i>
140140
 <li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM:SS</i>
141141
 </ul>
142142
143
-When the symbolic name is a date and time, fossil shows the version
143
+When the symbolic name is a date and time, fossil shows the version
144144
 of the document that was most recently checked in as of the date
145145
 and time specified. So, for example, to see what the fossil website
146146
 looked like at the beginning of 2010, enter:
147147
148148
 <blockquote>
149149
--- www/embeddeddoc.wiki
+++ www/embeddeddoc.wiki
@@ -42,13 +42,13 @@
42 <b>http://www.hwaci.com/cgi-bin/fossil</b>.
43 If you launch the web server using the "<b>fossil server</b>" command line,
44 then the <i>&lt;baseurl&gt;</i> is usually
45 <b>http://localhost:8080/</b>.
46
47 The <i>&lt;version&gt;</i> is any unique prefix of the check-in ID for
48 the check-in containing the documentation you want to access.
49 Or <i>&lt;version&gt;</i> can be the name of a
50 [./branching.wiki | branch] in order to show
51 the documentation for the latest version of that branch.
52 Or <i>&lt;version&gt;</i> can be one of the keywords "<b>tip</b>" or
53 "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recent
54 check-in. This is useful if you want to see the very latest
@@ -62,30 +62,30 @@
62
63 Finally, the <i>&lt;filename&gt;</i> element of the URL is the
64 pathname of the documentation file relative to the root of the source
65 tree.
66
67 The mimetype (and thus the rendering) of documentation files is
68 determined by the file suffix. Fossil currently understands
69 [/mimetype_list|many different file suffixes],
70 including all the popular ones such as ".css", ".gif", ".htm",
71 ".html", ".jpg", ".jpeg", ".png", and ".txt".
72
73 Documentation files whose names end in ".wiki" use the
74 [/wiki_rules | fossil wiki markup] -
75 a safe subset of HTML together with some wiki rules for paragraph
76 breaks, lists, and hyperlinks.
77 Documentation files ending in ".md" or ".markdown" use the
78 [/md_rules | Markdown markup langauge].
79 Documentation files ending in ".txt" are plain text.
80 Wiki, markdown, and plain text documentation files
81 are rendered with the standard fossil header and footer added.
82 Most other mimetypes are delivered directly to the requesting
83 web browser without interpretation, additions, or changes.
84
85 Files with the mimetype "text/html" (the .html or .htm suffix) are
86 usually rendered directly to the browser without interpretation.
87 However, if the file begins with a &lt;div&gt; element like this:
88
89 <b>&lt;div class='fossil-doc' data-title='<i>Title Text</i>'&gt;</b>
90
91 Then the standard Fossil header and footer are added to the document
@@ -117,11 +117,11 @@
117 <blockquote><pre>
118 #!/usr/bin/fossil
119 repository: /fossil/fossil.fossil
120 </pre></blockquote>
121
122 This is one of four ways to set up a
123 <a href="./server.wiki">fossil web server</a>.
124
125 The "<b>/trunk/</b>" part of the URL tells fossil to use
126 the documentation files from the most recent trunk check-in.
127 If you wanted to see an historical version of this document,
@@ -138,11 +138,11 @@
138 <li> <i>YYYY-MM-DD</i>
139 <li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM</i>
140 <li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM:SS</i>
141 </ul>
142
143 When the symbolic name is a date and time, fossil shows the version
144 of the document that was most recently checked in as of the date
145 and time specified. So, for example, to see what the fossil website
146 looked like at the beginning of 2010, enter:
147
148 <blockquote>
149
--- www/embeddeddoc.wiki
+++ www/embeddeddoc.wiki
@@ -42,13 +42,13 @@
42 <b>http://www.hwaci.com/cgi-bin/fossil</b>.
43 If you launch the web server using the "<b>fossil server</b>" command line,
44 then the <i>&lt;baseurl&gt;</i> is usually
45 <b>http://localhost:8080/</b>.
46
47 The <i>&lt;version&gt;</i> is any unique prefix of the check-in ID for
48 the check-in containing the documentation you want to access.
49 Or <i>&lt;version&gt;</i> can be the name of a
50 [./branching.wiki | branch] in order to show
51 the documentation for the latest version of that branch.
52 Or <i>&lt;version&gt;</i> can be one of the keywords "<b>tip</b>" or
53 "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recent
54 check-in. This is useful if you want to see the very latest
@@ -62,30 +62,30 @@
62
63 Finally, the <i>&lt;filename&gt;</i> element of the URL is the
64 pathname of the documentation file relative to the root of the source
65 tree.
66
67 The mimetype (and thus the rendering) of documentation files is
68 determined by the file suffix. Fossil currently understands
69 [/mimetype_list|many different file suffixes],
70 including all the popular ones such as ".css", ".gif", ".htm",
71 ".html", ".jpg", ".jpeg", ".png", and ".txt".
72
73 Documentation files whose names end in ".wiki" use the
74 [/wiki_rules | fossil wiki markup] -
75 a safe subset of HTML together with some wiki rules for paragraph
76 breaks, lists, and hyperlinks.
77 Documentation files ending in ".md" or ".markdown" use the
78 [/md_rules | Markdown markup langauge].
79 Documentation files ending in ".txt" are plain text.
80 Wiki, markdown, and plain text documentation files
81 are rendered with the standard fossil header and footer added.
82 Most other mimetypes are delivered directly to the requesting
83 web browser without interpretation, additions, or changes.
84
85 Files with the mimetype "text/html" (the .html or .htm suffix) are
86 usually rendered directly to the browser without interpretation.
87 However, if the file begins with a &lt;div&gt; element like this:
88
89 <b>&lt;div class='fossil-doc' data-title='<i>Title Text</i>'&gt;</b>
90
91 Then the standard Fossil header and footer are added to the document
@@ -117,11 +117,11 @@
117 <blockquote><pre>
118 #!/usr/bin/fossil
119 repository: /fossil/fossil.fossil
120 </pre></blockquote>
121
122 This is one of four ways to set up a
123 <a href="./server.wiki">fossil web server</a>.
124
125 The "<b>/trunk/</b>" part of the URL tells fossil to use
126 the documentation files from the most recent trunk check-in.
127 If you wanted to see an historical version of this document,
@@ -138,11 +138,11 @@
138 <li> <i>YYYY-MM-DD</i>
139 <li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM</i>
140 <li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM:SS</i>
141 </ul>
142
143 When the symbolic name is a date and time, fossil shows the version
144 of the document that was most recently checked in as of the date
145 and time specified. So, for example, to see what the fossil website
146 looked like at the beginning of 2010, enter:
147
148 <blockquote>
149
M www/encryptedrepos.wiki
+1 -1
--- www/encryptedrepos.wiki
+++ www/encryptedrepos.wiki
@@ -3,11 +3,11 @@
33
 Fossil can be compiled so that it works with encrypted repositories using
44
 the [https://www.sqlite.org/see/doc/trunk/www/readme.wiki|SQLite Encryption Extension].
55
 This technical note explains the process.
66
 </blockquote>
77
 <h2>Building An Encryption-Enabled Fossil</h2><blockquote>
8
-The SQLite Encryption Extension (SEE) is proprietary software and requires
8
+The SQLite Encryption Extension (SEE) is proprietary software and requires
99
 [http://www.hwaci.com/cgi-bin/see-step1|purchasing a license].
1010
 <p>
1111
 Assuming you have an SEE license, the first step of compiling Fossil to
1212
 use SEE is to create an SEE-enabled version of the SQLite database source code.
1313
 This alternative SQLite database source file should be called "sqlite3-see.c"
1414
--- www/encryptedrepos.wiki
+++ www/encryptedrepos.wiki
@@ -3,11 +3,11 @@
3 Fossil can be compiled so that it works with encrypted repositories using
4 the [https://www.sqlite.org/see/doc/trunk/www/readme.wiki|SQLite Encryption Extension].
5 This technical note explains the process.
6 </blockquote>
7 <h2>Building An Encryption-Enabled Fossil</h2><blockquote>
8 The SQLite Encryption Extension (SEE) is proprietary software and requires
9 [http://www.hwaci.com/cgi-bin/see-step1|purchasing a license].
10 <p>
11 Assuming you have an SEE license, the first step of compiling Fossil to
12 use SEE is to create an SEE-enabled version of the SQLite database source code.
13 This alternative SQLite database source file should be called "sqlite3-see.c"
14
--- www/encryptedrepos.wiki
+++ www/encryptedrepos.wiki
@@ -3,11 +3,11 @@
3 Fossil can be compiled so that it works with encrypted repositories using
4 the [https://www.sqlite.org/see/doc/trunk/www/readme.wiki|SQLite Encryption Extension].
5 This technical note explains the process.
6 </blockquote>
7 <h2>Building An Encryption-Enabled Fossil</h2><blockquote>
8 The SQLite Encryption Extension (SEE) is proprietary software and requires
9 [http://www.hwaci.com/cgi-bin/see-step1|purchasing a license].
10 <p>
11 Assuming you have an SEE license, the first step of compiling Fossil to
12 use SEE is to create an SEE-enabled version of the SQLite database source code.
13 This alternative SQLite database source file should be called "sqlite3-see.c"
14
M www/event.wiki
+3 -3
--- www/event.wiki
+++ www/event.wiki
@@ -23,11 +23,11 @@
2323
 can be something simple like "Version 1.2.3" perhaps with a bright
2424
 color background to draw attention to the entry and the wiki content
2525
 can contain release notes, for example.
2626
2727
 * <b>Blog Entries</b>. Blog entries from developers describing the current
28
- state of a project, or rational for various design decisions, or
28
+ state of a project, or rational for various design decisions, or
2929
 roadmaps for future development, can be entered as technotes.
3030
3131
 * <b>Process Checkpoints</b>. For projects that have a formal process,
3232
 technotes can be used to record the completion or the initiation of
3333
 various process steps. For example, a technote can be used to record
@@ -49,11 +49,11 @@
4949
 stay better organized and provide a better historical record of the
5050
 development progress.
5151
5252
 <h2>Viewing Technotes</h2>
5353
54
-Because technotes are considered a special kind of wiki,
54
+Because technotes are considered a special kind of wiki,
5555
 users must have permission to read wiki in order read technotes.
5656
 Enable the "j" permission under the /Setup/Users menu in order
5757
 to give specific users or user classes the ability to view wiki
5858
 and technotes.
5959
@@ -64,12 +64,12 @@
6464
6565
 There is a hyperlink under the /wikihelp menu that can be used to create
6666
 new technotes. And there is a submenu hyperlink on technote displays for
6767
 editing existing technotes.
6868
69
-Users must have check-in privileges (permission "i") in order to
69
+Users must have check-in privileges (permission "i") in order to
7070
 create or edit technotes. In addition, users must have create-wiki
7171
 privilege (permission "f") to create new technotes and edit-wiki
7272
 privilege (permission "k") in order to edit existing technotes.
7373
7474
 Technote content may be formatted as [/wiki_rules | Fossil wiki],
7575
 [/md_rules | Markdown], or a plain text.
7676
--- www/event.wiki
+++ www/event.wiki
@@ -23,11 +23,11 @@
23 can be something simple like "Version 1.2.3" perhaps with a bright
24 color background to draw attention to the entry and the wiki content
25 can contain release notes, for example.
26
27 * <b>Blog Entries</b>. Blog entries from developers describing the current
28 state of a project, or rational for various design decisions, or
29 roadmaps for future development, can be entered as technotes.
30
31 * <b>Process Checkpoints</b>. For projects that have a formal process,
32 technotes can be used to record the completion or the initiation of
33 various process steps. For example, a technote can be used to record
@@ -49,11 +49,11 @@
49 stay better organized and provide a better historical record of the
50 development progress.
51
52 <h2>Viewing Technotes</h2>
53
54 Because technotes are considered a special kind of wiki,
55 users must have permission to read wiki in order read technotes.
56 Enable the "j" permission under the /Setup/Users menu in order
57 to give specific users or user classes the ability to view wiki
58 and technotes.
59
@@ -64,12 +64,12 @@
64
65 There is a hyperlink under the /wikihelp menu that can be used to create
66 new technotes. And there is a submenu hyperlink on technote displays for
67 editing existing technotes.
68
69 Users must have check-in privileges (permission "i") in order to
70 create or edit technotes. In addition, users must have create-wiki
71 privilege (permission "f") to create new technotes and edit-wiki
72 privilege (permission "k") in order to edit existing technotes.
73
74 Technote content may be formatted as [/wiki_rules | Fossil wiki],
75 [/md_rules | Markdown], or a plain text.
76
--- www/event.wiki
+++ www/event.wiki
@@ -23,11 +23,11 @@
23 can be something simple like "Version 1.2.3" perhaps with a bright
24 color background to draw attention to the entry and the wiki content
25 can contain release notes, for example.
26
27 * <b>Blog Entries</b>. Blog entries from developers describing the current
28 state of a project, or rational for various design decisions, or
29 roadmaps for future development, can be entered as technotes.
30
31 * <b>Process Checkpoints</b>. For projects that have a formal process,
32 technotes can be used to record the completion or the initiation of
33 various process steps. For example, a technote can be used to record
@@ -49,11 +49,11 @@
49 stay better organized and provide a better historical record of the
50 development progress.
51
52 <h2>Viewing Technotes</h2>
53
54 Because technotes are considered a special kind of wiki,
55 users must have permission to read wiki in order read technotes.
56 Enable the "j" permission under the /Setup/Users menu in order
57 to give specific users or user classes the ability to view wiki
58 and technotes.
59
@@ -64,12 +64,12 @@
64
65 There is a hyperlink under the /wikihelp menu that can be used to create
66 new technotes. And there is a submenu hyperlink on technote displays for
67 editing existing technotes.
68
69 Users must have check-in privileges (permission "i") in order to
70 create or edit technotes. In addition, users must have create-wiki
71 privilege (permission "f") to create new technotes and edit-wiki
72 privilege (permission "k") in order to edit existing technotes.
73
74 Technote content may be formatted as [/wiki_rules | Fossil wiki],
75 [/md_rules | Markdown], or a plain text.
76
M www/faq.wiki
+5 -5
--- www/faq.wiki
+++ www/faq.wiki
@@ -62,12 +62,12 @@
6262
 If you already have a fork in your check-in tree and you want to convert
6363
 that fork to a branch, you can do this from the web interface.
6464
 First locate the check-in that you want to be
6565
 the initial check-in of your branch on the timeline and click on its
6666
 link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
67
-link (near the "Commands:" label) and click on that. On the
68
-"Edit Check-in" page, check the box beside "Branching:" and fill in
67
+link (near the "Commands:" label) and click on that. On the
68
+"Edit Check-in" page, check the box beside "Branching:" and fill in
6969
 the name of your new branch to the right and press the "Apply Changes"
7070
 button.</blockquote></li>
7171
7272
 <a name="q4"></a>
7373
 <p><b>(4) How do I tag a check-in?</b></p>
@@ -89,11 +89,11 @@
8989
9090
 The CHECK-IN in the previous line can be any
9191
 [./checkin_names.wiki | valid check-in name format].
9292
9393
 You can also add (and remove) tags from a check-in using the
94
-[./webui.wiki | web interface]. First locate the check-in that you
94
+[./webui.wiki | web interface]. First locate the check-in that you
9595
 what to tag on the timeline, then click on the link to go the detailed
9696
 information page for that check-in. Then find the "<b>edit</b>"
9797
 link (near the "Commands:" label) and click on that. There are
9898
 controls on the edit page that allow new tags to be added and existing
9999
 tags to be removed.</blockquote></li>
@@ -100,13 +100,13 @@
100100
101101
 <a name="q5"></a>
102102
 <p><b>(5) How do I create a private branch that won't get pushed back to the
103103
 main repository.</b></p>
104104
105
-<blockquote>Use the <b>--private</b> command-line option on the
105
+<blockquote>Use the <b>--private</b> command-line option on the
106106
 <b>commit</b> command. The result will be a check-in which exists on
107
-your local repository only and is never pushed to other repositories.
107
+your local repository only and is never pushed to other repositories.
108108
 All descendants of a private check-in are also private.
109109
110110
 Unless you specify something different using the <b>--branch</b> and/or
111111
 <b>--bgcolor</b> options, the new private check-in will be put on a branch
112112
 named "private" with an orange background color.
113113
--- www/faq.wiki
+++ www/faq.wiki
@@ -62,12 +62,12 @@
62 If you already have a fork in your check-in tree and you want to convert
63 that fork to a branch, you can do this from the web interface.
64 First locate the check-in that you want to be
65 the initial check-in of your branch on the timeline and click on its
66 link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
67 link (near the "Commands:" label) and click on that. On the
68 "Edit Check-in" page, check the box beside "Branching:" and fill in
69 the name of your new branch to the right and press the "Apply Changes"
70 button.</blockquote></li>
71
72 <a name="q4"></a>
73 <p><b>(4) How do I tag a check-in?</b></p>
@@ -89,11 +89,11 @@
89
90 The CHECK-IN in the previous line can be any
91 [./checkin_names.wiki | valid check-in name format].
92
93 You can also add (and remove) tags from a check-in using the
94 [./webui.wiki | web interface]. First locate the check-in that you
95 what to tag on the timeline, then click on the link to go the detailed
96 information page for that check-in. Then find the "<b>edit</b>"
97 link (near the "Commands:" label) and click on that. There are
98 controls on the edit page that allow new tags to be added and existing
99 tags to be removed.</blockquote></li>
@@ -100,13 +100,13 @@
100
101 <a name="q5"></a>
102 <p><b>(5) How do I create a private branch that won't get pushed back to the
103 main repository.</b></p>
104
105 <blockquote>Use the <b>--private</b> command-line option on the
106 <b>commit</b> command. The result will be a check-in which exists on
107 your local repository only and is never pushed to other repositories.
108 All descendants of a private check-in are also private.
109
110 Unless you specify something different using the <b>--branch</b> and/or
111 <b>--bgcolor</b> options, the new private check-in will be put on a branch
112 named "private" with an orange background color.
113
--- www/faq.wiki
+++ www/faq.wiki
@@ -62,12 +62,12 @@
62 If you already have a fork in your check-in tree and you want to convert
63 that fork to a branch, you can do this from the web interface.
64 First locate the check-in that you want to be
65 the initial check-in of your branch on the timeline and click on its
66 link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
67 link (near the "Commands:" label) and click on that. On the
68 "Edit Check-in" page, check the box beside "Branching:" and fill in
69 the name of your new branch to the right and press the "Apply Changes"
70 button.</blockquote></li>
71
72 <a name="q4"></a>
73 <p><b>(4) How do I tag a check-in?</b></p>
@@ -89,11 +89,11 @@
89
90 The CHECK-IN in the previous line can be any
91 [./checkin_names.wiki | valid check-in name format].
92
93 You can also add (and remove) tags from a check-in using the
94 [./webui.wiki | web interface]. First locate the check-in that you
95 what to tag on the timeline, then click on the link to go the detailed
96 information page for that check-in. Then find the "<b>edit</b>"
97 link (near the "Commands:" label) and click on that. There are
98 controls on the edit page that allow new tags to be added and existing
99 tags to be removed.</blockquote></li>
@@ -100,13 +100,13 @@
100
101 <a name="q5"></a>
102 <p><b>(5) How do I create a private branch that won't get pushed back to the
103 main repository.</b></p>
104
105 <blockquote>Use the <b>--private</b> command-line option on the
106 <b>commit</b> command. The result will be a check-in which exists on
107 your local repository only and is never pushed to other repositories.
108 All descendants of a private check-in are also private.
109
110 Unless you specify something different using the <b>--branch</b> and/or
111 <b>--bgcolor</b> options, the new private check-in will be put on a branch
112 named "private" with an orange background color.
113
M www/fileformat.wiki
+26 -26
--- www/fileformat.wiki
+++ www/fileformat.wiki
@@ -2,11 +2,11 @@
22
 <h1 align="center">
33
 Fossil File Formats
44
 </h1>
55
66
 The global state of a fossil repository is kept simple so that it can
7
-endure in useful form for decades or centuries.
7
+endure in useful form for decades or centuries.
88
 A fossil repository is intended to be readable,
99
 searchable, and extensible by people not yet born.
1010
1111
 The global state of a fossil repository is an unordered
1212
 set of <i>artifacts</i>.
@@ -14,11 +14,11 @@
1414
 part of a trouble ticket, or one of several special control artifacts
1515
 used to show the relationships between other artifacts within the
1616
 project. Each artifact is normally represented on disk as a separate
1717
 file. Artifacts can be text or binary.
1818
19
-In addition to the global state,
19
+In addition to the global state,
2020
 each fossil repository also contains local state.
2121
 The local state consists of web-page formatting
2222
 preferences, authorized users, ticket display and reporting formats,
2323
 and so forth. The global state is shared in common among all
2424
 repositories for the same project, whereas the local state is often
@@ -30,11 +30,11 @@
3030
 mentioned here in order to distinguish it from global state.
3131
3232
 Each artifact in the repository is named by its SHA1 hash.
3333
 No prefixes or meta information is added to an artifact before
3434
 its hash is computed. The name of an artifact in the repository
35
-is exactly the same SHA1 hash that is computed by sha1sum
35
+is exactly the same SHA1 hash that is computed by sha1sum
3636
 on the file as it exists in your source tree.</p>
3737
3838
 Some artifacts have a particular format which gives them special
3939
 meaning to fossil. Fossil recognizes:
4040
@@ -84,11 +84,11 @@
8484
 Each card begins with a single
8585
 character "card type". Zero or more arguments may follow
8686
 the card type. All arguments are separated from each other
8787
 and from the card-type character by a single space
8888
 character. There is no surplus white space between arguments
89
-and no leading or trailing whitespace except for the newline
89
+and no leading or trailing whitespace except for the newline
9090
 character that acts as the card separator.
9191
9292
 All cards of the manifest occur in strict sorted lexicographical order.
9393
 No card may be duplicated.
9494
 The entire manifest may be PGP clear-signed, but otherwise it
@@ -114,18 +114,18 @@
114114
 another manifest that serves as the "baseline" for this manifest. A
115115
 manifest that has a B-card is called a delta-manifest and a manifest
116116
 that omits the B-card is a baseline-manifest. The other manifest
117117
 identified by the argument of the B-card must be a baseline-manifest.
118118
 A baseline-manifest records the complete contents of a check-in.
119
-A delta-manifest records only changes from its baseline.
119
+A delta-manifest records only changes from its baseline.
120120
121121
 A manifest must have exactly one C-card. The sole argument to
122122
 the C-card is a check-in comment that describes the check-in that
123123
 the manifest defines. The check-in comment is text. The following
124124
 escape sequences are applied to the text:
125125
 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
126
-newline (ASCII 0x0a) is "\n" (ASCII 0x5C, x6E). A backslash
126
+newline (ASCII 0x0a) is "\n" (ASCII 0x5C, x6E). A backslash
127127
 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
128128
 space and newline, no other whitespace characters are allowed in
129129
 the check-in comment. Nor are any unprintable characters allowed
130130
 in the comment.
131131
@@ -167,11 +167,11 @@
167167
 is used.
168168
169169
 A manifest has zero or one P-cards. Most manifests have one P-card.
170170
 The P-card has a varying number of arguments that
171171
 define other manifests from which the current manifest
172
-is derived. Each argument is a 40-character lowercase
172
+is derived. Each argument is a 40-character lowercase
173173
 hexadecimal SHA1 of a predecessor manifest. All arguments
174174
 to the P-card must be unique within that card.
175175
 The first argument is the SHA1 of the direct ancestor of the manifest.
176176
 Other arguments define manifests with which the first was
177177
 merged to yield the current manifest. Most manifests have
@@ -184,28 +184,28 @@
184184
 whereas a P-card defines the immediate ancestor or a merge
185185
 ancestor, the Q-card is used to identify a single check-in or a small
186186
 range of check-ins which were cherry-picked for inclusion in or
187187
 exclusion from the current manifest. The first argument of
188188
 the Q-card is the artifact ID of another manifest (the "target")
189
-which has had its changes included or excluded in the current manifest.
189
+which has had its changes included or excluded in the current manifest.
190190
 The target is preceded by "+" or "-" to show inclusion or
191191
 exclusion, respectively. The optional second argument to the
192192
 Q-card is another manifest artifact ID which is the "baseline"
193193
 for the cherry-pick. If omitted, the baseline is the primary
194194
 parent of the target. The
195195
 changes included or excluded consist of all changes moving from
196
-the baseline to the target.
196
+the baseline to the target.
197197
198
-The Q-card was added to the interface specification on 2011-02-26.
198
+The Q-card was added to the interface specification on 2011-02-26.
199199
 Older versions of Fossil will reject manifests that contain Q-cards.
200200
201201
 A manifest may optionally have a single R-card. The R-card has
202
-a single argument which is the MD5 checksum of all files in
202
+a single argument which is the MD5 checksum of all files in
203203
 the check-in except the manifest itself. The checksum is expressed
204204
 as 32 characters of lowercase hexadecimal. The checksum is
205205
 computed as follows: For each file in the check-in (except for
206
-the manifest itself) in strict sorted lexicographical order,
206
+the manifest itself) in strict sorted lexicographical order,
207207
 take the pathname of the file relative to the root of the
208208
 repository, append a single space (ASCII 0x20), the
209209
 size of the file in ASCII decimal, a single newline
210210
 character (ASCII 0x0A), and the complete text of the file.
211211
 Compute the MD5 checksum of the result.
@@ -228,12 +228,12 @@
228228
 is encoded using the same character escapes as is used for the
229229
 check-in comment argument to the C-card.
230230
231231
 A manifest must have a single Z-card as its last line. The argument
232232
 to the Z-card is a 32-character lowercase hexadecimal MD5 hash
233
-of all prior lines of the manifest up to and including the newline
234
-character that immediately precedes the "Z". The Z-card is
233
+of all prior lines of the manifest up to and including the newline
234
+character that immediately precedes the "Z". The Z-card is
235235
 a sanity check to prove that the manifest is well-formed and
236236
 consistent.
237237
238238
 A sample manifest from Fossil itself can be seen
239239
 [/artifact/28987096ac | here].
@@ -240,11 +240,11 @@
240240
241241
 <a name="cluster"></a>
242242
 <h2>2.0 Clusters</h2>
243243
244244
 A cluster is an artifact that declares the existence of other artifacts.
245
-Clusters are used during repository synchronization to help
245
+Clusters are used during repository synchronization to help
246246
 reduce network traffic. As such, clusters are an optimization and
247247
 may be removed from a repository without loss or damage to the
248248
 underlying project code.
249249
250250
 Clusters follow a syntax that is very similar to manifests.
@@ -252,15 +252,15 @@
252252
 (ASCII 0x0a) separate the artifact into cards. Each card begins with a single
253253
 character "card type". Zero or more arguments may follow
254254
 the card type. All arguments are separated from each other
255255
 and from the card-type character by a single space
256256
 character. There is no surplus white space between arguments
257
-and no leading or trailing whitespace except for the newline
257
+and no leading or trailing whitespace except for the newline
258258
 character that acts as the card separator.
259259
 All cards of a cluster occur in strict sorted lexicographical order.
260260
 No card may be duplicated.
261
-The cluster may not contain additional text or data beyond
261
+The cluster may not contain additional text or data beyond
262262
 what is described here.
263263
 Unlike manifests, clusters are never PGP signed.
264264
265265
 Allowed cards in the cluster are as follows:
266266
@@ -268,11 +268,11 @@
268268
 <b>M</b> <i>artifact-id</i><br />
269269
 <b>Z</b> <i>checksum</i>
270270
 </blockquote>
271271
272272
 A cluster contains one or more "M" cards followed by a single "Z"
273
-card. Each M card has a single argument which is the artifact ID of
273
+card. Each M card has a single argument which is the artifact ID of
274274
 another artifact in the repository. The Z card works exactly like
275275
 the Z card of a manifest. The argument to the Z card is the
276276
 lower-case hexadecimal representation of the MD5 checksum of all
277277
 prior cards in the cluster. The Z-card is required.
278278
@@ -315,11 +315,11 @@
315315
 first value is the tag name. The first character of the tag
316316
 is either "+", "-", or "*". The "+" means the tag should be added
317317
 to the artifact. The "-" means the tag should be removed.
318318
 The "*" character means the tag should be added to the artifact
319319
 and all direct descendants (but not descendants through a merge) down
320
-to but not including the first descendant that contains a
320
+to but not including the first descendant that contains a
321321
 more recent "-", "*", or "+" tag with the same name.
322322
 The optional third argument is the value of the tag. A tag
323323
 without a value is a Boolean.
324324
325325
 When two or more tags with the same name are applied to the
@@ -331,11 +331,11 @@
331331
 for display purposes. The "user" tag overrides the name of the
332332
 check-in user. The "date" tag overrides the check-in date.
333333
 The "branch" tag sets the name of the branch that at check-in
334334
 belongs to. Symbolic tags begin with the "sym-" prefix.
335335
336
-The U card is the name of the user that created the control
336
+The U card is the name of the user that created the control
337337
 artifact. The Z card is the usual required artifact checksum.
338338
339339
 An example control artifacts can be seen [/info/9d302ccda8 | here].
340340
341341
@@ -360,11 +360,11 @@
360360
361361
 The D card is the date and time when the wiki page was edited.
362362
 The P card specifies the parent wiki pages, if any. The L card
363363
 gives the name of the wiki page. The optional N card specifies
364364
 the mimetype of the wiki text. If the N card is omitted, the
365
-mimetype is assumed to be text/x-fossil-wiki.
365
+mimetype is assumed to be text/x-fossil-wiki.
366366
 The U card specifies the login
367367
 of the user who made this edit to the wiki page. The Z card is
368368
 the usual checksum over the entire artifact and is required.
369369
370370
 The W card is used to specify the text of the wiki page. The
@@ -405,11 +405,11 @@
405405
 If the <i>value</i> parameter of the J card is omitted, then the
406406
 field is set to an empty string.
407407
 Each fossil server has a ticket configuration which specifies the fields its
408408
 understands. The ticket configuration is part of the local state for
409409
 the repository and thus can vary from one repository to another.
410
-Hence a J card might specify a <i>field</i> that do not exist in the
410
+Hence a J card might specify a <i>field</i> that do not exist in the
411411
 local ticket configuration. If a J card specifies a <i>field</i> that
412412
 is not in the local configuration, then that J card
413413
 is simply ignored.
414414
415415
 The first argument of the J card is the field name. The second
@@ -424,11 +424,11 @@
424424
425425
 <a name="attachment"></a>
426426
 <h2>6.0 Attachments</h2>
427427
428428
 An attachment artifact associates some other artifact that is the
429
-attachment (the source artifact) with a ticket or wiki page or
429
+attachment (the source artifact) with a ticket or wiki page or
430430
 technical note to which
431431
 the attachment is connected (the target artifact).
432432
 The following cards are allowed on an attachment artifact:
433433
434434
 <blockquote>
@@ -441,11 +441,11 @@
441441
 </blockquote>
442442
443443
 The A card specifies a filename for the attachment in its first argument.
444444
 The second argument to the A card is the name of the wiki page or
445445
 ticket or technical note to which the attachment is connected. The
446
-third argument is either missing or else it is the 40-character artifact
446
+third argument is either missing or else it is the 40-character artifact
447447
 ID of the attachment itself. A missing third argument means that the
448448
 attachment should be deleted.
449449
450450
 The C card is an optional comment describing what the attachment is about.
451451
 The C card is optional, but there can only be one.
@@ -487,11 +487,11 @@
487487
 </blockquote>
488488
489489
 The C card contains text that is displayed on the timeline for the
490490
 technote. The C card is optional, but there can only be one.
491491
492
-A single D card is required to give the date and time when the
492
+A single D card is required to give the date and time when the
493493
 technote artifact was created. This is different from the time at which
494494
 the technote appears on the timeline.
495495
496496
 A single E card gives the time of the technote (the point on the timeline
497497
 where the technote is displayed) and a unique identifier for the technote.
@@ -525,11 +525,11 @@
525525
 display color for timelines.
526526
527527
 The optional U card gives name of the user who entered the technote.
528528
529529
 A single W card provides wiki text for the document associated with the
530
-technote. The format of the W card is exactly the same as for a
530
+technote. The format of the W card is exactly the same as for a
531531
 [#wikichng | wiki artifact].
532532
533533
 The Z card is the required checksum over the rest of the artifact.
534534
535535
536536
--- www/fileformat.wiki
+++ www/fileformat.wiki
@@ -2,11 +2,11 @@
2 <h1 align="center">
3 Fossil File Formats
4 </h1>
5
6 The global state of a fossil repository is kept simple so that it can
7 endure in useful form for decades or centuries.
8 A fossil repository is intended to be readable,
9 searchable, and extensible by people not yet born.
10
11 The global state of a fossil repository is an unordered
12 set of <i>artifacts</i>.
@@ -14,11 +14,11 @@
14 part of a trouble ticket, or one of several special control artifacts
15 used to show the relationships between other artifacts within the
16 project. Each artifact is normally represented on disk as a separate
17 file. Artifacts can be text or binary.
18
19 In addition to the global state,
20 each fossil repository also contains local state.
21 The local state consists of web-page formatting
22 preferences, authorized users, ticket display and reporting formats,
23 and so forth. The global state is shared in common among all
24 repositories for the same project, whereas the local state is often
@@ -30,11 +30,11 @@
30 mentioned here in order to distinguish it from global state.
31
32 Each artifact in the repository is named by its SHA1 hash.
33 No prefixes or meta information is added to an artifact before
34 its hash is computed. The name of an artifact in the repository
35 is exactly the same SHA1 hash that is computed by sha1sum
36 on the file as it exists in your source tree.</p>
37
38 Some artifacts have a particular format which gives them special
39 meaning to fossil. Fossil recognizes:
40
@@ -84,11 +84,11 @@
84 Each card begins with a single
85 character "card type". Zero or more arguments may follow
86 the card type. All arguments are separated from each other
87 and from the card-type character by a single space
88 character. There is no surplus white space between arguments
89 and no leading or trailing whitespace except for the newline
90 character that acts as the card separator.
91
92 All cards of the manifest occur in strict sorted lexicographical order.
93 No card may be duplicated.
94 The entire manifest may be PGP clear-signed, but otherwise it
@@ -114,18 +114,18 @@
114 another manifest that serves as the "baseline" for this manifest. A
115 manifest that has a B-card is called a delta-manifest and a manifest
116 that omits the B-card is a baseline-manifest. The other manifest
117 identified by the argument of the B-card must be a baseline-manifest.
118 A baseline-manifest records the complete contents of a check-in.
119 A delta-manifest records only changes from its baseline.
120
121 A manifest must have exactly one C-card. The sole argument to
122 the C-card is a check-in comment that describes the check-in that
123 the manifest defines. The check-in comment is text. The following
124 escape sequences are applied to the text:
125 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
126 newline (ASCII 0x0a) is "\n" (ASCII 0x5C, x6E). A backslash
127 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
128 space and newline, no other whitespace characters are allowed in
129 the check-in comment. Nor are any unprintable characters allowed
130 in the comment.
131
@@ -167,11 +167,11 @@
167 is used.
168
169 A manifest has zero or one P-cards. Most manifests have one P-card.
170 The P-card has a varying number of arguments that
171 define other manifests from which the current manifest
172 is derived. Each argument is a 40-character lowercase
173 hexadecimal SHA1 of a predecessor manifest. All arguments
174 to the P-card must be unique within that card.
175 The first argument is the SHA1 of the direct ancestor of the manifest.
176 Other arguments define manifests with which the first was
177 merged to yield the current manifest. Most manifests have
@@ -184,28 +184,28 @@
184 whereas a P-card defines the immediate ancestor or a merge
185 ancestor, the Q-card is used to identify a single check-in or a small
186 range of check-ins which were cherry-picked for inclusion in or
187 exclusion from the current manifest. The first argument of
188 the Q-card is the artifact ID of another manifest (the "target")
189 which has had its changes included or excluded in the current manifest.
190 The target is preceded by "+" or "-" to show inclusion or
191 exclusion, respectively. The optional second argument to the
192 Q-card is another manifest artifact ID which is the "baseline"
193 for the cherry-pick. If omitted, the baseline is the primary
194 parent of the target. The
195 changes included or excluded consist of all changes moving from
196 the baseline to the target.
197
198 The Q-card was added to the interface specification on 2011-02-26.
199 Older versions of Fossil will reject manifests that contain Q-cards.
200
201 A manifest may optionally have a single R-card. The R-card has
202 a single argument which is the MD5 checksum of all files in
203 the check-in except the manifest itself. The checksum is expressed
204 as 32 characters of lowercase hexadecimal. The checksum is
205 computed as follows: For each file in the check-in (except for
206 the manifest itself) in strict sorted lexicographical order,
207 take the pathname of the file relative to the root of the
208 repository, append a single space (ASCII 0x20), the
209 size of the file in ASCII decimal, a single newline
210 character (ASCII 0x0A), and the complete text of the file.
211 Compute the MD5 checksum of the result.
@@ -228,12 +228,12 @@
228 is encoded using the same character escapes as is used for the
229 check-in comment argument to the C-card.
230
231 A manifest must have a single Z-card as its last line. The argument
232 to the Z-card is a 32-character lowercase hexadecimal MD5 hash
233 of all prior lines of the manifest up to and including the newline
234 character that immediately precedes the "Z". The Z-card is
235 a sanity check to prove that the manifest is well-formed and
236 consistent.
237
238 A sample manifest from Fossil itself can be seen
239 [/artifact/28987096ac | here].
@@ -240,11 +240,11 @@
240
241 <a name="cluster"></a>
242 <h2>2.0 Clusters</h2>
243
244 A cluster is an artifact that declares the existence of other artifacts.
245 Clusters are used during repository synchronization to help
246 reduce network traffic. As such, clusters are an optimization and
247 may be removed from a repository without loss or damage to the
248 underlying project code.
249
250 Clusters follow a syntax that is very similar to manifests.
@@ -252,15 +252,15 @@
252 (ASCII 0x0a) separate the artifact into cards. Each card begins with a single
253 character "card type". Zero or more arguments may follow
254 the card type. All arguments are separated from each other
255 and from the card-type character by a single space
256 character. There is no surplus white space between arguments
257 and no leading or trailing whitespace except for the newline
258 character that acts as the card separator.
259 All cards of a cluster occur in strict sorted lexicographical order.
260 No card may be duplicated.
261 The cluster may not contain additional text or data beyond
262 what is described here.
263 Unlike manifests, clusters are never PGP signed.
264
265 Allowed cards in the cluster are as follows:
266
@@ -268,11 +268,11 @@
268 <b>M</b> <i>artifact-id</i><br />
269 <b>Z</b> <i>checksum</i>
270 </blockquote>
271
272 A cluster contains one or more "M" cards followed by a single "Z"
273 card. Each M card has a single argument which is the artifact ID of
274 another artifact in the repository. The Z card works exactly like
275 the Z card of a manifest. The argument to the Z card is the
276 lower-case hexadecimal representation of the MD5 checksum of all
277 prior cards in the cluster. The Z-card is required.
278
@@ -315,11 +315,11 @@
315 first value is the tag name. The first character of the tag
316 is either "+", "-", or "*". The "+" means the tag should be added
317 to the artifact. The "-" means the tag should be removed.
318 The "*" character means the tag should be added to the artifact
319 and all direct descendants (but not descendants through a merge) down
320 to but not including the first descendant that contains a
321 more recent "-", "*", or "+" tag with the same name.
322 The optional third argument is the value of the tag. A tag
323 without a value is a Boolean.
324
325 When two or more tags with the same name are applied to the
@@ -331,11 +331,11 @@
331 for display purposes. The "user" tag overrides the name of the
332 check-in user. The "date" tag overrides the check-in date.
333 The "branch" tag sets the name of the branch that at check-in
334 belongs to. Symbolic tags begin with the "sym-" prefix.
335
336 The U card is the name of the user that created the control
337 artifact. The Z card is the usual required artifact checksum.
338
339 An example control artifacts can be seen [/info/9d302ccda8 | here].
340
341
@@ -360,11 +360,11 @@
360
361 The D card is the date and time when the wiki page was edited.
362 The P card specifies the parent wiki pages, if any. The L card
363 gives the name of the wiki page. The optional N card specifies
364 the mimetype of the wiki text. If the N card is omitted, the
365 mimetype is assumed to be text/x-fossil-wiki.
366 The U card specifies the login
367 of the user who made this edit to the wiki page. The Z card is
368 the usual checksum over the entire artifact and is required.
369
370 The W card is used to specify the text of the wiki page. The
@@ -405,11 +405,11 @@
405 If the <i>value</i> parameter of the J card is omitted, then the
406 field is set to an empty string.
407 Each fossil server has a ticket configuration which specifies the fields its
408 understands. The ticket configuration is part of the local state for
409 the repository and thus can vary from one repository to another.
410 Hence a J card might specify a <i>field</i> that do not exist in the
411 local ticket configuration. If a J card specifies a <i>field</i> that
412 is not in the local configuration, then that J card
413 is simply ignored.
414
415 The first argument of the J card is the field name. The second
@@ -424,11 +424,11 @@
424
425 <a name="attachment"></a>
426 <h2>6.0 Attachments</h2>
427
428 An attachment artifact associates some other artifact that is the
429 attachment (the source artifact) with a ticket or wiki page or
430 technical note to which
431 the attachment is connected (the target artifact).
432 The following cards are allowed on an attachment artifact:
433
434 <blockquote>
@@ -441,11 +441,11 @@
441 </blockquote>
442
443 The A card specifies a filename for the attachment in its first argument.
444 The second argument to the A card is the name of the wiki page or
445 ticket or technical note to which the attachment is connected. The
446 third argument is either missing or else it is the 40-character artifact
447 ID of the attachment itself. A missing third argument means that the
448 attachment should be deleted.
449
450 The C card is an optional comment describing what the attachment is about.
451 The C card is optional, but there can only be one.
@@ -487,11 +487,11 @@
487 </blockquote>
488
489 The C card contains text that is displayed on the timeline for the
490 technote. The C card is optional, but there can only be one.
491
492 A single D card is required to give the date and time when the
493 technote artifact was created. This is different from the time at which
494 the technote appears on the timeline.
495
496 A single E card gives the time of the technote (the point on the timeline
497 where the technote is displayed) and a unique identifier for the technote.
@@ -525,11 +525,11 @@
525 display color for timelines.
526
527 The optional U card gives name of the user who entered the technote.
528
529 A single W card provides wiki text for the document associated with the
530 technote. The format of the W card is exactly the same as for a
531 [#wikichng | wiki artifact].
532
533 The Z card is the required checksum over the rest of the artifact.
534
535
536
--- www/fileformat.wiki
+++ www/fileformat.wiki
@@ -2,11 +2,11 @@
2 <h1 align="center">
3 Fossil File Formats
4 </h1>
5
6 The global state of a fossil repository is kept simple so that it can
7 endure in useful form for decades or centuries.
8 A fossil repository is intended to be readable,
9 searchable, and extensible by people not yet born.
10
11 The global state of a fossil repository is an unordered
12 set of <i>artifacts</i>.
@@ -14,11 +14,11 @@
14 part of a trouble ticket, or one of several special control artifacts
15 used to show the relationships between other artifacts within the
16 project. Each artifact is normally represented on disk as a separate
17 file. Artifacts can be text or binary.
18
19 In addition to the global state,
20 each fossil repository also contains local state.
21 The local state consists of web-page formatting
22 preferences, authorized users, ticket display and reporting formats,
23 and so forth. The global state is shared in common among all
24 repositories for the same project, whereas the local state is often
@@ -30,11 +30,11 @@
30 mentioned here in order to distinguish it from global state.
31
32 Each artifact in the repository is named by its SHA1 hash.
33 No prefixes or meta information is added to an artifact before
34 its hash is computed. The name of an artifact in the repository
35 is exactly the same SHA1 hash that is computed by sha1sum
36 on the file as it exists in your source tree.</p>
37
38 Some artifacts have a particular format which gives them special
39 meaning to fossil. Fossil recognizes:
40
@@ -84,11 +84,11 @@
84 Each card begins with a single
85 character "card type". Zero or more arguments may follow
86 the card type. All arguments are separated from each other
87 and from the card-type character by a single space
88 character. There is no surplus white space between arguments
89 and no leading or trailing whitespace except for the newline
90 character that acts as the card separator.
91
92 All cards of the manifest occur in strict sorted lexicographical order.
93 No card may be duplicated.
94 The entire manifest may be PGP clear-signed, but otherwise it
@@ -114,18 +114,18 @@
114 another manifest that serves as the "baseline" for this manifest. A
115 manifest that has a B-card is called a delta-manifest and a manifest
116 that omits the B-card is a baseline-manifest. The other manifest
117 identified by the argument of the B-card must be a baseline-manifest.
118 A baseline-manifest records the complete contents of a check-in.
119 A delta-manifest records only changes from its baseline.
120
121 A manifest must have exactly one C-card. The sole argument to
122 the C-card is a check-in comment that describes the check-in that
123 the manifest defines. The check-in comment is text. The following
124 escape sequences are applied to the text:
125 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
126 newline (ASCII 0x0a) is "\n" (ASCII 0x5C, x6E). A backslash
127 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
128 space and newline, no other whitespace characters are allowed in
129 the check-in comment. Nor are any unprintable characters allowed
130 in the comment.
131
@@ -167,11 +167,11 @@
167 is used.
168
169 A manifest has zero or one P-cards. Most manifests have one P-card.
170 The P-card has a varying number of arguments that
171 define other manifests from which the current manifest
172 is derived. Each argument is a 40-character lowercase
173 hexadecimal SHA1 of a predecessor manifest. All arguments
174 to the P-card must be unique within that card.
175 The first argument is the SHA1 of the direct ancestor of the manifest.
176 Other arguments define manifests with which the first was
177 merged to yield the current manifest. Most manifests have
@@ -184,28 +184,28 @@
184 whereas a P-card defines the immediate ancestor or a merge
185 ancestor, the Q-card is used to identify a single check-in or a small
186 range of check-ins which were cherry-picked for inclusion in or
187 exclusion from the current manifest. The first argument of
188 the Q-card is the artifact ID of another manifest (the "target")
189 which has had its changes included or excluded in the current manifest.
190 The target is preceded by "+" or "-" to show inclusion or
191 exclusion, respectively. The optional second argument to the
192 Q-card is another manifest artifact ID which is the "baseline"
193 for the cherry-pick. If omitted, the baseline is the primary
194 parent of the target. The
195 changes included or excluded consist of all changes moving from
196 the baseline to the target.
197
198 The Q-card was added to the interface specification on 2011-02-26.
199 Older versions of Fossil will reject manifests that contain Q-cards.
200
201 A manifest may optionally have a single R-card. The R-card has
202 a single argument which is the MD5 checksum of all files in
203 the check-in except the manifest itself. The checksum is expressed
204 as 32 characters of lowercase hexadecimal. The checksum is
205 computed as follows: For each file in the check-in (except for
206 the manifest itself) in strict sorted lexicographical order,
207 take the pathname of the file relative to the root of the
208 repository, append a single space (ASCII 0x20), the
209 size of the file in ASCII decimal, a single newline
210 character (ASCII 0x0A), and the complete text of the file.
211 Compute the MD5 checksum of the result.
@@ -228,12 +228,12 @@
228 is encoded using the same character escapes as is used for the
229 check-in comment argument to the C-card.
230
231 A manifest must have a single Z-card as its last line. The argument
232 to the Z-card is a 32-character lowercase hexadecimal MD5 hash
233 of all prior lines of the manifest up to and including the newline
234 character that immediately precedes the "Z". The Z-card is
235 a sanity check to prove that the manifest is well-formed and
236 consistent.
237
238 A sample manifest from Fossil itself can be seen
239 [/artifact/28987096ac | here].
@@ -240,11 +240,11 @@
240
241 <a name="cluster"></a>
242 <h2>2.0 Clusters</h2>
243
244 A cluster is an artifact that declares the existence of other artifacts.
245 Clusters are used during repository synchronization to help
246 reduce network traffic. As such, clusters are an optimization and
247 may be removed from a repository without loss or damage to the
248 underlying project code.
249
250 Clusters follow a syntax that is very similar to manifests.
@@ -252,15 +252,15 @@
252 (ASCII 0x0a) separate the artifact into cards. Each card begins with a single
253 character "card type". Zero or more arguments may follow
254 the card type. All arguments are separated from each other
255 and from the card-type character by a single space
256 character. There is no surplus white space between arguments
257 and no leading or trailing whitespace except for the newline
258 character that acts as the card separator.
259 All cards of a cluster occur in strict sorted lexicographical order.
260 No card may be duplicated.
261 The cluster may not contain additional text or data beyond
262 what is described here.
263 Unlike manifests, clusters are never PGP signed.
264
265 Allowed cards in the cluster are as follows:
266
@@ -268,11 +268,11 @@
268 <b>M</b> <i>artifact-id</i><br />
269 <b>Z</b> <i>checksum</i>
270 </blockquote>
271
272 A cluster contains one or more "M" cards followed by a single "Z"
273 card. Each M card has a single argument which is the artifact ID of
274 another artifact in the repository. The Z card works exactly like
275 the Z card of a manifest. The argument to the Z card is the
276 lower-case hexadecimal representation of the MD5 checksum of all
277 prior cards in the cluster. The Z-card is required.
278
@@ -315,11 +315,11 @@
315 first value is the tag name. The first character of the tag
316 is either "+", "-", or "*". The "+" means the tag should be added
317 to the artifact. The "-" means the tag should be removed.
318 The "*" character means the tag should be added to the artifact
319 and all direct descendants (but not descendants through a merge) down
320 to but not including the first descendant that contains a
321 more recent "-", "*", or "+" tag with the same name.
322 The optional third argument is the value of the tag. A tag
323 without a value is a Boolean.
324
325 When two or more tags with the same name are applied to the
@@ -331,11 +331,11 @@
331 for display purposes. The "user" tag overrides the name of the
332 check-in user. The "date" tag overrides the check-in date.
333 The "branch" tag sets the name of the branch that at check-in
334 belongs to. Symbolic tags begin with the "sym-" prefix.
335
336 The U card is the name of the user that created the control
337 artifact. The Z card is the usual required artifact checksum.
338
339 An example control artifacts can be seen [/info/9d302ccda8 | here].
340
341
@@ -360,11 +360,11 @@
360
361 The D card is the date and time when the wiki page was edited.
362 The P card specifies the parent wiki pages, if any. The L card
363 gives the name of the wiki page. The optional N card specifies
364 the mimetype of the wiki text. If the N card is omitted, the
365 mimetype is assumed to be text/x-fossil-wiki.
366 The U card specifies the login
367 of the user who made this edit to the wiki page. The Z card is
368 the usual checksum over the entire artifact and is required.
369
370 The W card is used to specify the text of the wiki page. The
@@ -405,11 +405,11 @@
405 If the <i>value</i> parameter of the J card is omitted, then the
406 field is set to an empty string.
407 Each fossil server has a ticket configuration which specifies the fields its
408 understands. The ticket configuration is part of the local state for
409 the repository and thus can vary from one repository to another.
410 Hence a J card might specify a <i>field</i> that do not exist in the
411 local ticket configuration. If a J card specifies a <i>field</i> that
412 is not in the local configuration, then that J card
413 is simply ignored.
414
415 The first argument of the J card is the field name. The second
@@ -424,11 +424,11 @@
424
425 <a name="attachment"></a>
426 <h2>6.0 Attachments</h2>
427
428 An attachment artifact associates some other artifact that is the
429 attachment (the source artifact) with a ticket or wiki page or
430 technical note to which
431 the attachment is connected (the target artifact).
432 The following cards are allowed on an attachment artifact:
433
434 <blockquote>
@@ -441,11 +441,11 @@
441 </blockquote>
442
443 The A card specifies a filename for the attachment in its first argument.
444 The second argument to the A card is the name of the wiki page or
445 ticket or technical note to which the attachment is connected. The
446 third argument is either missing or else it is the 40-character artifact
447 ID of the attachment itself. A missing third argument means that the
448 attachment should be deleted.
449
450 The C card is an optional comment describing what the attachment is about.
451 The C card is optional, but there can only be one.
@@ -487,11 +487,11 @@
487 </blockquote>
488
489 The C card contains text that is displayed on the timeline for the
490 technote. The C card is optional, but there can only be one.
491
492 A single D card is required to give the date and time when the
493 technote artifact was created. This is different from the time at which
494 the technote appears on the timeline.
495
496 A single E card gives the time of the technote (the point on the timeline
497 where the technote is displayed) and a unique identifier for the technote.
@@ -525,11 +525,11 @@
525 display color for timelines.
526
527 The optional U card gives name of the user who entered the technote.
528
529 A single W card provides wiki text for the document associated with the
530 technote. The format of the W card is exactly the same as for a
531 [#wikichng | wiki artifact].
532
533 The Z card is the required checksum over the rest of the artifact.
534
535
536
M www/fiveminutes.wiki
+19 -19
--- www/fiveminutes.wiki
+++ www/fiveminutes.wiki
@@ -4,65 +4,65 @@
44
 The following document was contributed by Gilles Ganault on 2013-01-08.
55
 </i></b>
66
 </p><hr>
77
88
 <h1>Up and running in 5 minutes as a single user</h1>
9
-<p>This short document explains the main basic Fossil commands for a single
10
-user, i.e. with no additional users, with no need to synchronize with some remote
9
+<p>This short document explains the main basic Fossil commands for a single
10
+user, i.e. with no additional users, with no need to synchronize with some remote
1111
 repository, and no need for branching/forking.</p>
1212
1313
 <h2>Create a new repository</h2>
1414
 <p>fossil new c:\test.repo</p>
15
-<p>This will create the new SQLite binary file that holds the repository, i.e.
16
-files, tickets, wiki, etc. It can be located anywhere, although it's considered
17
-best practice to keep it outside the work directory where you will work on files
15
+<p>This will create the new SQLite binary file that holds the repository, i.e.
16
+files, tickets, wiki, etc. It can be located anywhere, although it's considered
17
+best practice to keep it outside the work directory where you will work on files
1818
 after they've been checked out of the repository.</p>
1919
2020
 <h2>Open the repository</h2>
2121
 <p>cd c:\temp\test.fossil</p>
2222
 <p>fossil open c:\test.repo</p>
23
-<p>This will check out the last revision of all the files in the repository,
24
-if any, into the current work directory. In addition, it will create a binary
23
+<p>This will check out the last revision of all the files in the repository,
24
+if any, into the current work directory. In addition, it will create a binary
2525
 file _FOSSIL_ to keep track of changes (on non-Windows systems it is called
2626
 <tt>.fslckout</tt>).</p>
2727
2828
 <h2>Add new files</h2>
2929
 <p>fossil add .</p>
30
-<p>To tell Fossil to add new files to the repository. The files aren't actually
31
-added until you run &quot;commit&quot;. When using &quot;.&quot;, it tells Fossil
32
-to add all the files in the current directory recursively, i.e. including all
30
+<p>To tell Fossil to add new files to the repository. The files aren't actually
31
+added until you run &quot;commit&quot;. When using &quot;.&quot;, it tells Fossil
32
+to add all the files in the current directory recursively, i.e. including all
3333
 the files in all the subdirectories.</p>
3434
 <p>Note: To tell Fossil to ignore some extensions:</p>
3535
 <p>fossil settings ignore-glob &quot;*.o,*.obj,*.exe&quot; --global</p>
3636
3737
 <h2>Remove files that haven't been committed yet</h2>
3838
 <p>fossil delete myfile.c</p>
39
-<p>This will simply remove the item from the list of files that were previously
39
+<p>This will simply remove the item from the list of files that were previously
4040
 added through &quot;fossil add&quot;.</p>
4141
4242
 <h2>Check current status</h2>
4343
 <p>fossil changes</p>
44
-<p>This shows the list of changes that have been done and will be committed the
45
-next time you run &quot;fossil commit&quot;. It's a useful command to run before
44
+<p>This shows the list of changes that have been done and will be committed the
45
+next time you run &quot;fossil commit&quot;. It's a useful command to run before
4646
 running &quot;fossil commit&quot; just to check that things are OK before proceeding.</p>
4747
4848
 <h2>Commit changes</h2>
49
-<p>To actually apply the pending changes to the repository, e.g. new files marked
50
-for addition, checked-out files that have been edited and must be checked-in,
49
+<p>To actually apply the pending changes to the repository, e.g. new files marked
50
+for addition, checked-out files that have been edited and must be checked-in,
5151
 etc.</p>
5252
5353
 <p>fossil commit -m "Added stuff"</p>
5454
5555
 If no file names are provided on the command-line then all changes will be checked in,
5656
 otherwise just the listed file(s) will be checked in.
5757
5858
 <h2>Compare two revisions of a file</h2>
59
-<p>If you wish to compare the last revision of a file and its checked out version
59
+<p>If you wish to compare the last revision of a file and its checked out version
6060
 in your work directory:</p>
6161
 <p>fossil gdiff myfile.c</p>
6262
 <p>If you wish to compare two different revisions of a file in the repository:</p>
63
-<p>fossil finfo myfile: Note the first hash, which is the UUID of the commit
63
+<p>fossil finfo myfile: Note the first hash, which is the UUID of the commit
6464
 when the file was committed</p>
6565
 <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p>
6666
 <h2>Cancel changes and go back to previous revision</h2>
6767
 <p>fossil revert myfile.c</p>
6868
 <p>Fossil does not prompt when reverting a file. It simply reminds the user about the
@@ -69,8 +69,8 @@
6969
 "undo" command, just in case the revert was a mistake.</p>
7070
7171
7272
 <h2>Close the repository</h2>
7373
 <p>fossil close</p>
74
-<p>This will simply remove the _FOSSIL_ at the root of the work directory but
75
-will not delete the files in the work directory. From then on, any use of &quot;fossil&quot;
74
+<p>This will simply remove the _FOSSIL_ at the root of the work directory but
75
+will not delete the files in the work directory. From then on, any use of &quot;fossil&quot;
7676
 will trigger an error since there is no longer any connection.</p>
7777
--- www/fiveminutes.wiki
+++ www/fiveminutes.wiki
@@ -4,65 +4,65 @@
4 The following document was contributed by Gilles Ganault on 2013-01-08.
5 </i></b>
6 </p><hr>
7
8 <h1>Up and running in 5 minutes as a single user</h1>
9 <p>This short document explains the main basic Fossil commands for a single
10 user, i.e. with no additional users, with no need to synchronize with some remote
11 repository, and no need for branching/forking.</p>
12
13 <h2>Create a new repository</h2>
14 <p>fossil new c:\test.repo</p>
15 <p>This will create the new SQLite binary file that holds the repository, i.e.
16 files, tickets, wiki, etc. It can be located anywhere, although it's considered
17 best practice to keep it outside the work directory where you will work on files
18 after they've been checked out of the repository.</p>
19
20 <h2>Open the repository</h2>
21 <p>cd c:\temp\test.fossil</p>
22 <p>fossil open c:\test.repo</p>
23 <p>This will check out the last revision of all the files in the repository,
24 if any, into the current work directory. In addition, it will create a binary
25 file _FOSSIL_ to keep track of changes (on non-Windows systems it is called
26 <tt>.fslckout</tt>).</p>
27
28 <h2>Add new files</h2>
29 <p>fossil add .</p>
30 <p>To tell Fossil to add new files to the repository. The files aren't actually
31 added until you run &quot;commit&quot;. When using &quot;.&quot;, it tells Fossil
32 to add all the files in the current directory recursively, i.e. including all
33 the files in all the subdirectories.</p>
34 <p>Note: To tell Fossil to ignore some extensions:</p>
35 <p>fossil settings ignore-glob &quot;*.o,*.obj,*.exe&quot; --global</p>
36
37 <h2>Remove files that haven't been committed yet</h2>
38 <p>fossil delete myfile.c</p>
39 <p>This will simply remove the item from the list of files that were previously
40 added through &quot;fossil add&quot;.</p>
41
42 <h2>Check current status</h2>
43 <p>fossil changes</p>
44 <p>This shows the list of changes that have been done and will be committed the
45 next time you run &quot;fossil commit&quot;. It's a useful command to run before
46 running &quot;fossil commit&quot; just to check that things are OK before proceeding.</p>
47
48 <h2>Commit changes</h2>
49 <p>To actually apply the pending changes to the repository, e.g. new files marked
50 for addition, checked-out files that have been edited and must be checked-in,
51 etc.</p>
52
53 <p>fossil commit -m "Added stuff"</p>
54
55 If no file names are provided on the command-line then all changes will be checked in,
56 otherwise just the listed file(s) will be checked in.
57
58 <h2>Compare two revisions of a file</h2>
59 <p>If you wish to compare the last revision of a file and its checked out version
60 in your work directory:</p>
61 <p>fossil gdiff myfile.c</p>
62 <p>If you wish to compare two different revisions of a file in the repository:</p>
63 <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit
64 when the file was committed</p>
65 <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p>
66 <h2>Cancel changes and go back to previous revision</h2>
67 <p>fossil revert myfile.c</p>
68 <p>Fossil does not prompt when reverting a file. It simply reminds the user about the
@@ -69,8 +69,8 @@
69 "undo" command, just in case the revert was a mistake.</p>
70
71
72 <h2>Close the repository</h2>
73 <p>fossil close</p>
74 <p>This will simply remove the _FOSSIL_ at the root of the work directory but
75 will not delete the files in the work directory. From then on, any use of &quot;fossil&quot;
76 will trigger an error since there is no longer any connection.</p>
77
--- www/fiveminutes.wiki
+++ www/fiveminutes.wiki
@@ -4,65 +4,65 @@
4 The following document was contributed by Gilles Ganault on 2013-01-08.
5 </i></b>
6 </p><hr>
7
8 <h1>Up and running in 5 minutes as a single user</h1>
9 <p>This short document explains the main basic Fossil commands for a single
10 user, i.e. with no additional users, with no need to synchronize with some remote
11 repository, and no need for branching/forking.</p>
12
13 <h2>Create a new repository</h2>
14 <p>fossil new c:\test.repo</p>
15 <p>This will create the new SQLite binary file that holds the repository, i.e.
16 files, tickets, wiki, etc. It can be located anywhere, although it's considered
17 best practice to keep it outside the work directory where you will work on files
18 after they've been checked out of the repository.</p>
19
20 <h2>Open the repository</h2>
21 <p>cd c:\temp\test.fossil</p>
22 <p>fossil open c:\test.repo</p>
23 <p>This will check out the last revision of all the files in the repository,
24 if any, into the current work directory. In addition, it will create a binary
25 file _FOSSIL_ to keep track of changes (on non-Windows systems it is called
26 <tt>.fslckout</tt>).</p>
27
28 <h2>Add new files</h2>
29 <p>fossil add .</p>
30 <p>To tell Fossil to add new files to the repository. The files aren't actually
31 added until you run &quot;commit&quot;. When using &quot;.&quot;, it tells Fossil
32 to add all the files in the current directory recursively, i.e. including all
33 the files in all the subdirectories.</p>
34 <p>Note: To tell Fossil to ignore some extensions:</p>
35 <p>fossil settings ignore-glob &quot;*.o,*.obj,*.exe&quot; --global</p>
36
37 <h2>Remove files that haven't been committed yet</h2>
38 <p>fossil delete myfile.c</p>
39 <p>This will simply remove the item from the list of files that were previously
40 added through &quot;fossil add&quot;.</p>
41
42 <h2>Check current status</h2>
43 <p>fossil changes</p>
44 <p>This shows the list of changes that have been done and will be committed the
45 next time you run &quot;fossil commit&quot;. It's a useful command to run before
46 running &quot;fossil commit&quot; just to check that things are OK before proceeding.</p>
47
48 <h2>Commit changes</h2>
49 <p>To actually apply the pending changes to the repository, e.g. new files marked
50 for addition, checked-out files that have been edited and must be checked-in,
51 etc.</p>
52
53 <p>fossil commit -m "Added stuff"</p>
54
55 If no file names are provided on the command-line then all changes will be checked in,
56 otherwise just the listed file(s) will be checked in.
57
58 <h2>Compare two revisions of a file</h2>
59 <p>If you wish to compare the last revision of a file and its checked out version
60 in your work directory:</p>
61 <p>fossil gdiff myfile.c</p>
62 <p>If you wish to compare two different revisions of a file in the repository:</p>
63 <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit
64 when the file was committed</p>
65 <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p>
66 <h2>Cancel changes and go back to previous revision</h2>
67 <p>fossil revert myfile.c</p>
68 <p>Fossil does not prompt when reverting a file. It simply reminds the user about the
@@ -69,8 +69,8 @@
69 "undo" command, just in case the revert was a mistake.</p>
70
71
72 <h2>Close the repository</h2>
73 <p>fossil close</p>
74 <p>This will simply remove the _FOSSIL_ at the root of the work directory but
75 will not delete the files in the work directory. From then on, any use of &quot;fossil&quot;
76 will trigger an error since there is no longer any connection.</p>
77
M www/foss-cklist.wiki
+2 -2
--- www/foss-cklist.wiki
+++ www/foss-cklist.wiki
@@ -89,11 +89,11 @@
8989
9090
 <li><p>The project has a website.
9191
9292
 <li><p>Release version numbers are in the traditional X.Y or X.Y.Z format.
9393
94
-<li><p>Releases can be downloaded as tarball using
94
+<li><p>Releases can be downloaded as tarball using
9595
 gzip or bzip2 compression.
9696
9797
 <li><p>Releases unpack into a versioned top-level directory.
9898
 (ex: "projectname-1.2.3/").
9999
@@ -102,12 +102,12 @@
102102
 tarball.
103103
104104
 <li><p>There are no incompatible licenses in the code.
105105
106106
 <li><p>The project has not been blithely proclaimed "public domain" without
107
-having gone through the tedious and exacting legal steps to actually put it
107
+having gone through the tedious and exacting legal steps to actually put it
108108
 in the public domain.
109109
110110
 <li><p>There is an accurate change log in the code and on the website.
111111
112112
 <li><p>There is documentation in the code and on the website.
113113
 </ol>
114114
--- www/foss-cklist.wiki
+++ www/foss-cklist.wiki
@@ -89,11 +89,11 @@
89
90 <li><p>The project has a website.
91
92 <li><p>Release version numbers are in the traditional X.Y or X.Y.Z format.
93
94 <li><p>Releases can be downloaded as tarball using
95 gzip or bzip2 compression.
96
97 <li><p>Releases unpack into a versioned top-level directory.
98 (ex: "projectname-1.2.3/").
99
@@ -102,12 +102,12 @@
102 tarball.
103
104 <li><p>There are no incompatible licenses in the code.
105
106 <li><p>The project has not been blithely proclaimed "public domain" without
107 having gone through the tedious and exacting legal steps to actually put it
108 in the public domain.
109
110 <li><p>There is an accurate change log in the code and on the website.
111
112 <li><p>There is documentation in the code and on the website.
113 </ol>
114
--- www/foss-cklist.wiki
+++ www/foss-cklist.wiki
@@ -89,11 +89,11 @@
89
90 <li><p>The project has a website.
91
92 <li><p>Release version numbers are in the traditional X.Y or X.Y.Z format.
93
94 <li><p>Releases can be downloaded as tarball using
95 gzip or bzip2 compression.
96
97 <li><p>Releases unpack into a versioned top-level directory.
98 (ex: "projectname-1.2.3/").
99
@@ -102,12 +102,12 @@
102 tarball.
103
104 <li><p>There are no incompatible licenses in the code.
105
106 <li><p>The project has not been blithely proclaimed "public domain" without
107 having gone through the tedious and exacting legal steps to actually put it
108 in the public domain.
109
110 <li><p>There is an accurate change log in the code and on the website.
111
112 <li><p>There is documentation in the code and on the website.
113 </ol>
114
M www/fossil-from-msvc.wiki
+11 -11
--- www/fossil-from-msvc.wiki
+++ www/fossil-from-msvc.wiki
@@ -11,41 +11,41 @@
1111
 <li>Tools &gt; External Tools, where the items in this list map
1212
 to "External Tool X" that we'll add to our own Fossil
1313
 menu later: </li>
1414
 <ol type="1">
1515
 <li>Rename the default "&#91;New Tool 1&#93;" to eg.
16
- "Commit"&nbsp;&nbsp;&nbsp;2.
16
+ "Commit"&nbsp;&nbsp;&nbsp;2.
1717
 </li>
1818
 <li>Change Command to where Fossil is located eg.
1919
 "c:\fossil.exe"</li>
2020
 <li>Change Arguments to the required command, eg.
21
- "commit -m".
21
+ "commit -m".
2222
 The user will be prompted to type the comment that Commit expects</li>
23
- <li>Set "Initial Directory" to point it to the work directory
23
+ <li>Set "Initial Directory" to point it to the work directory
2424
 where the source files are currently checked out
2525
 by Fossil (eg. c:\Workspace). It's also possible to use system
2626
 variables such as "$(ProjectDir)" instead of hard-coding the path</li>
2727
 <li>Check "Prompt for arguments", since Commit
2828
 requires typing a comment. Useless for commands like Changes
2929
 that don't require arguments</li>
30
- <li>Uncheck "Close on Exit", so we can see what Fossil says
31
- before closing the DOS box. Note that "Use Output Window"
32
- will display the output in a child window within the IDE instead of
30
+ <li>Uncheck "Close on Exit", so we can see what Fossil says
31
+ before closing the DOS box. Note that "Use Output Window"
32
+ will display the output in a child window within the IDE instead of
3333
 opening a DOS box</li>
3434
 <li>Click on OK</li>
3535
 </ol>
3636
 <li>Tools &gt; Customize &gt; Commands</li>
3737
 <ol type="1">
38
- <li>With "Menu bar = Menu Bar" selected, click on "Add
38
+ <li>With "Menu bar = Menu Bar" selected, click on "Add
3939
 New Menu". A new "Fossil" menu is displayed in the
4040
 IDE's menu bar</li>
4141
 <li>Click on "Modify Selection" to rename it
4242
 "Fossil", and...</li>
4343
 <li>Use the "Move Down" button to move it lower in
4444
 the list</li>
4545
 </ol>
46
- <li>Still in Customize dialog: In the "Menu bar" combo, select
47
- the new Fossil menu you just created, and Click on "Add Command...":
48
- From Categories, select Tools, and select "External Command 1".
49
- Click on Close. It's unfortunate that the IDE doesn't say which command
46
+ <li>Still in Customize dialog: In the "Menu bar" combo, select
47
+ the new Fossil menu you just created, and Click on "Add Command...":
48
+ From Categories, select Tools, and select "External Command 1".
49
+ Click on Close. It's unfortunate that the IDE doesn't say which command
5050
 maps to "External Command X".</li>
5151
 </ol>
5252
--- www/fossil-from-msvc.wiki
+++ www/fossil-from-msvc.wiki
@@ -11,41 +11,41 @@
11 <li>Tools &gt; External Tools, where the items in this list map
12 to "External Tool X" that we'll add to our own Fossil
13 menu later: </li>
14 <ol type="1">
15 <li>Rename the default "&#91;New Tool 1&#93;" to eg.
16 "Commit"&nbsp;&nbsp;&nbsp;2.
17 </li>
18 <li>Change Command to where Fossil is located eg.
19 "c:\fossil.exe"</li>
20 <li>Change Arguments to the required command, eg.
21 "commit -m".
22 The user will be prompted to type the comment that Commit expects</li>
23 <li>Set "Initial Directory" to point it to the work directory
24 where the source files are currently checked out
25 by Fossil (eg. c:\Workspace). It's also possible to use system
26 variables such as "$(ProjectDir)" instead of hard-coding the path</li>
27 <li>Check "Prompt for arguments", since Commit
28 requires typing a comment. Useless for commands like Changes
29 that don't require arguments</li>
30 <li>Uncheck "Close on Exit", so we can see what Fossil says
31 before closing the DOS box. Note that "Use Output Window"
32 will display the output in a child window within the IDE instead of
33 opening a DOS box</li>
34 <li>Click on OK</li>
35 </ol>
36 <li>Tools &gt; Customize &gt; Commands</li>
37 <ol type="1">
38 <li>With "Menu bar = Menu Bar" selected, click on "Add
39 New Menu". A new "Fossil" menu is displayed in the
40 IDE's menu bar</li>
41 <li>Click on "Modify Selection" to rename it
42 "Fossil", and...</li>
43 <li>Use the "Move Down" button to move it lower in
44 the list</li>
45 </ol>
46 <li>Still in Customize dialog: In the "Menu bar" combo, select
47 the new Fossil menu you just created, and Click on "Add Command...":
48 From Categories, select Tools, and select "External Command 1".
49 Click on Close. It's unfortunate that the IDE doesn't say which command
50 maps to "External Command X".</li>
51 </ol>
52
--- www/fossil-from-msvc.wiki
+++ www/fossil-from-msvc.wiki
@@ -11,41 +11,41 @@
11 <li>Tools &gt; External Tools, where the items in this list map
12 to "External Tool X" that we'll add to our own Fossil
13 menu later: </li>
14 <ol type="1">
15 <li>Rename the default "&#91;New Tool 1&#93;" to eg.
16 "Commit"&nbsp;&nbsp;&nbsp;2.
17 </li>
18 <li>Change Command to where Fossil is located eg.
19 "c:\fossil.exe"</li>
20 <li>Change Arguments to the required command, eg.
21 "commit -m".
22 The user will be prompted to type the comment that Commit expects</li>
23 <li>Set "Initial Directory" to point it to the work directory
24 where the source files are currently checked out
25 by Fossil (eg. c:\Workspace). It's also possible to use system
26 variables such as "$(ProjectDir)" instead of hard-coding the path</li>
27 <li>Check "Prompt for arguments", since Commit
28 requires typing a comment. Useless for commands like Changes
29 that don't require arguments</li>
30 <li>Uncheck "Close on Exit", so we can see what Fossil says
31 before closing the DOS box. Note that "Use Output Window"
32 will display the output in a child window within the IDE instead of
33 opening a DOS box</li>
34 <li>Click on OK</li>
35 </ol>
36 <li>Tools &gt; Customize &gt; Commands</li>
37 <ol type="1">
38 <li>With "Menu bar = Menu Bar" selected, click on "Add
39 New Menu". A new "Fossil" menu is displayed in the
40 IDE's menu bar</li>
41 <li>Click on "Modify Selection" to rename it
42 "Fossil", and...</li>
43 <li>Use the "Move Down" button to move it lower in
44 the list</li>
45 </ol>
46 <li>Still in Customize dialog: In the "Menu bar" combo, select
47 the new Fossil menu you just created, and Click on "Add Command...":
48 From Categories, select Tools, and select "External Command 1".
49 Click on Close. It's unfortunate that the IDE doesn't say which command
50 maps to "External Command X".</li>
51 </ol>
52
M www/index.wiki
+1 -1
--- www/index.wiki
+++ www/index.wiki
@@ -38,11 +38,11 @@
3838
 ([./webpage-ex.md|examples]) designed to promote situational awareness.
3939
4040
 This entire website is just a running instance of Fossil.
4141
 The pages you see here are all [./wikitheory.wiki | wiki] or
4242
 [./embeddeddoc.wiki | embedded documentation] or (in the case of
43
- the [/uv/download.html|download] page)
43
+ the [/uv/download.html|download] page)
4444
 [./unvers.wiki | unversioned files].
4545
 When you clone Fossil from one of its
4646
 [./selfhost.wiki | self-hosting repositories],
4747
 you get more than just source code - you get this entire website.
4848
4949
--- www/index.wiki
+++ www/index.wiki
@@ -38,11 +38,11 @@
38 ([./webpage-ex.md|examples]) designed to promote situational awareness.
39
40 This entire website is just a running instance of Fossil.
41 The pages you see here are all [./wikitheory.wiki | wiki] or
42 [./embeddeddoc.wiki | embedded documentation] or (in the case of
43 the [/uv/download.html|download] page)
44 [./unvers.wiki | unversioned files].
45 When you clone Fossil from one of its
46 [./selfhost.wiki | self-hosting repositories],
47 you get more than just source code - you get this entire website.
48
49
--- www/index.wiki
+++ www/index.wiki
@@ -38,11 +38,11 @@
38 ([./webpage-ex.md|examples]) designed to promote situational awareness.
39
40 This entire website is just a running instance of Fossil.
41 The pages you see here are all [./wikitheory.wiki | wiki] or
42 [./embeddeddoc.wiki | embedded documentation] or (in the case of
43 the [/uv/download.html|download] page)
44 [./unvers.wiki | unversioned files].
45 When you clone Fossil from one of its
46 [./selfhost.wiki | self-hosting repositories],
47 you get more than just source code - you get this entire website.
48
49
M www/inout.wiki
+5 -5
--- www/inout.wiki
+++ www/inout.wiki
@@ -1,10 +1,10 @@
11
 <title>Import And Export</title>
22
3
-Fossil has the ability to import and export repositories from and to
3
+Fossil has the ability to import and export repositories from and to
44
 [http://git-scm.com/ | Git]. And since most other version control
5
-systems will also import/export from Git, that means that you can
5
+systems will also import/export from Git, that means that you can
66
 import/export a Fossil repository to most version control systems using
77
 Git as an intermediary.
88
99
 <h2>Git → Fossil</h2>
1010
@@ -20,11 +20,11 @@
2020
 command is the name of a new Fossil repository that is created to hold the Git
2121
 content.
2222
2323
 The --git option is not actually required. The git-fast-export file format
2424
 is currently the only VCS interchange format that Fossil understands. But
25
-future versions of Fossil might be enhanced to understand other VCS
25
+future versions of Fossil might be enhanced to understand other VCS
2626
 interchange formats, and so for compatibility, use of the
2727
 --git option is recommended.
2828
2929
 <h2>Fossil → Git</h2>
3030
@@ -43,14 +43,14 @@
4343
 Note that the "fossil export --git" command only exports the versioned files.
4444
 Tickets and wiki and events are not exported, since Git does not understand
4545
 those concepts.
4646
4747
 As with the "import" command, the --git option is not required
48
-since the git-fast-export file format is currently the only VCS interchange
48
+since the git-fast-export file format is currently the only VCS interchange
4949
 format that Fossil will generate. However,
5050
 future versions of Fossil might add the ability to generate other
51
-VCS interchange formats, and so for compatibility, the use of the --git
51
+VCS interchange formats, and so for compatibility, the use of the --git
5252
 option recommended.
5353
5454
 <h2>Bidirectional Synchronization</h2>
5555
 Fossil also has the ability to synchronize with a Git repository via repeated
5656
 imports and/or exports. To do this, it uses marks files to store a record of
5757
--- www/inout.wiki
+++ www/inout.wiki
@@ -1,10 +1,10 @@
1 <title>Import And Export</title>
2
3 Fossil has the ability to import and export repositories from and to
4 [http://git-scm.com/ | Git]. And since most other version control
5 systems will also import/export from Git, that means that you can
6 import/export a Fossil repository to most version control systems using
7 Git as an intermediary.
8
9 <h2>Git → Fossil</h2>
10
@@ -20,11 +20,11 @@
20 command is the name of a new Fossil repository that is created to hold the Git
21 content.
22
23 The --git option is not actually required. The git-fast-export file format
24 is currently the only VCS interchange format that Fossil understands. But
25 future versions of Fossil might be enhanced to understand other VCS
26 interchange formats, and so for compatibility, use of the
27 --git option is recommended.
28
29 <h2>Fossil → Git</h2>
30
@@ -43,14 +43,14 @@
43 Note that the "fossil export --git" command only exports the versioned files.
44 Tickets and wiki and events are not exported, since Git does not understand
45 those concepts.
46
47 As with the "import" command, the --git option is not required
48 since the git-fast-export file format is currently the only VCS interchange
49 format that Fossil will generate. However,
50 future versions of Fossil might add the ability to generate other
51 VCS interchange formats, and so for compatibility, the use of the --git
52 option recommended.
53
54 <h2>Bidirectional Synchronization</h2>
55 Fossil also has the ability to synchronize with a Git repository via repeated
56 imports and/or exports. To do this, it uses marks files to store a record of
57
--- www/inout.wiki
+++ www/inout.wiki
@@ -1,10 +1,10 @@
1 <title>Import And Export</title>
2
3 Fossil has the ability to import and export repositories from and to
4 [http://git-scm.com/ | Git]. And since most other version control
5 systems will also import/export from Git, that means that you can
6 import/export a Fossil repository to most version control systems using
7 Git as an intermediary.
8
9 <h2>Git → Fossil</h2>
10
@@ -20,11 +20,11 @@
20 command is the name of a new Fossil repository that is created to hold the Git
21 content.
22
23 The --git option is not actually required. The git-fast-export file format
24 is currently the only VCS interchange format that Fossil understands. But
25 future versions of Fossil might be enhanced to understand other VCS
26 interchange formats, and so for compatibility, use of the
27 --git option is recommended.
28
29 <h2>Fossil → Git</h2>
30
@@ -43,14 +43,14 @@
43 Note that the "fossil export --git" command only exports the versioned files.
44 Tickets and wiki and events are not exported, since Git does not understand
45 those concepts.
46
47 As with the "import" command, the --git option is not required
48 since the git-fast-export file format is currently the only VCS interchange
49 format that Fossil will generate. However,
50 future versions of Fossil might add the ability to generate other
51 VCS interchange formats, and so for compatibility, the use of the --git
52 option recommended.
53
54 <h2>Bidirectional Synchronization</h2>
55 Fossil also has the ability to synchronize with a Git repository via repeated
56 imports and/or exports. To do this, it uses marks files to store a record of
57
M www/makefile.wiki
+13 -13
--- www/makefile.wiki
+++ www/makefile.wiki
@@ -2,24 +2,24 @@
22
33
 <h1>1.0 Introduction</h1>
44
55
 The build process for Fossil is tricky in that the source code
66
 needs to be processed by three different preprocessor programs
7
-before it is compiled. Most users will download a
7
+before it is compiled. Most users will download a
88
 [http://www.fossil-scm.org/download.html | precompiled binary]
99
 so this is of no consequence to them, and even those who
10
-want to compile the code themselves can use one of the
11
-[./build.wiki | existing makefiles].
10
+want to compile the code themselves can use one of the
11
+[./build.wiki | existing makefiles].
1212
 So must people do not need to be concerned with the
1313
 build complexities of Fossil. But hard-core developers who desire
1414
 a deep understanding of how Fossil is put together can benefit
1515
 from reviewing this article.
1616
1717
 <a name="srctour"></a>
1818
 <h1>2.0 Source Code Tour</h1>
1919
20
-The source code for Fossil is found in the
20
+The source code for Fossil is found in the
2121
 [/dir?ci=trunk&name=src | src/] subdirectory of the
2222
 source tree. The src/ subdirectory contains all code, including
2323
 the code for the separate preprocessor programs.
2424
2525
 Each preprocessor program is a separate C program implemented in
@@ -50,11 +50,11 @@
5050
 The TH1 script engine is implemented using files:
5151
5252
 7. th.c
5353
 8. th.h
5454
55
-These two files are imports like the SQLite source files,
55
+These two files are imports like the SQLite source files,
5656
 and so are not preprocessed.
5757
5858
 The VERSION.h header file is generated from other information sources
5959
 using a small program called:
6060
@@ -86,11 +86,11 @@
8686
8787
 13. main.mk
8888
8989
 The main.mk makefile is invoked from the Makefile in the top-level
9090
 directory. The main.mk is generated by makemake.tcl and should not
91
-be hand edited. Other makefiles generated by makemake.tcl are in
91
+be hand edited. Other makefiles generated by makemake.tcl are in
9292
 other subdirectories (currently all in the win/ subdirectory).
9393
9494
 All the other files in the src/ subdirectory (79 files at the time of
9595
 this writing) are C source code files that are subject to the
9696
 preprocessing steps described below. In the sequel, we will call these
@@ -109,11 +109,11 @@
109109
 (The "manifest" and "manifest.uuid" files are automatically generated and
110110
 updated by Fossil itself. See the [/help/setting | fossil set manifest]
111111
 command for additional information.)
112112
113113
 The VERSION.h header file is generated by
114
-a C program: src/mkversion.c.
114
+a C program: src/mkversion.c.
115115
 To run the VERSION.h generator, first compile the src/mkversion.c
116116
 source file into a command-line program (named "mkversion.exe")
117117
 then run:
118118
119119
 <blockquote><pre>
@@ -126,11 +126,11 @@
126126
 in the root of the source tree are the three arguments and
127127
 the generated VERSION.h file appears on standard output.
128128
129129
 The builtin_data.h header file is generated by a C program: src/mkbuiltin.c.
130130
 The builtin_data.h file contains C-langauge byte-array definitions for
131
-the content of resource files used by Fossil. To generate the
131
+the content of resource files used by Fossil. To generate the
132132
 builtin_data.h file, first compile the mkbuiltin.c program, then run:
133133
134134
 <blockquote><pre>
135135
 mkbuiltin.exe diff.tcl <i>OtherFiles...</i> &gt;builtin_data.h
136136
 </pre></blockquote>
@@ -163,11 +163,11 @@
163163
 Note that "src.c" in the above is a stand-in for the (79) regular source
164164
 files of Fossil - all source files except for the exceptions described in
165165
 section 2.0 above.
166166
167167
 The output of the mkindex program is a header file that is #include-ed by
168
-the main.c source file during the final compilation step.
168
+the main.c source file during the final compilation step.
169169
170170
 <h2>4.2 The translate preprocessor</h2>
171171
172172
 The translate preprocessor looks for lines of source code that begin
173173
 with "@" and converts those lines into string constants or (depending on
@@ -181,11 +181,11 @@
181181
 </pre></blockquote>
182182
183183
 In this case, the "src.c" file represents any single source file from the
184184
 set of ordinary source files as described in section 2.0 above. Note that
185185
 each source file is translated separately. By convention, the names of
186
-the translated source files are the names of the input sources with a
186
+the translated source files are the names of the input sources with a
187187
 single "_" character at the end. But a new makefile can use any naming
188188
 convention it wants - the "_" is not critical to the build process.
189189
190190
 After being translated, the output files (the "src_.c" files) should be
191191
 used for all subsequent preprocessing and compilation steps.
@@ -209,16 +209,16 @@
209209
 <blockquote><pre>
210210
 makeheaders src_.c:src.h sqlite3.h th.h VERSION.h
211211
 </pre></blockquote>
212212
213213
 In the example above the "src_.c" and "src.h" names represent all of the
214
-(79) ordinary C source files, each as a separate argument.
214
+(79) ordinary C source files, each as a separate argument.
215215
216216
 <h1>5.0 Compilation</h1>
217217
218218
 After all generated files have been created and all ordinary source files
219
-have been preprocessed, the generated and preprocessed files can be
219
+have been preprocessed, the generated and preprocessed files can be
220220
 combined into a single executable using a C compiler. This can be done
221221
 all at once, or each preprocessed source file can be compiled into a
222222
 separate object code file and the resulting object code files linked
223223
 together in a final step.
224224
@@ -247,11 +247,11 @@
247247
 * -Dmain=sqlite3_main
248248
 * -DSQLITE_OMIT_LOAD_EXTENSION=1
249249
250250
 The "main()" routine in the shell must be changed into sqlite3_main()
251251
 to prevent it from colliding with the real main() in Fossil, and to give
252
-Fossil an entry point to jump to when the
252
+Fossil an entry point to jump to when the
253253
 [/help/sqlite3 | fossil sql] command is invoked.
254254
255255
 All the other source code files can be compiled without any special
256256
 options.
257257
258258
--- www/makefile.wiki
+++ www/makefile.wiki
@@ -2,24 +2,24 @@
2
3 <h1>1.0 Introduction</h1>
4
5 The build process for Fossil is tricky in that the source code
6 needs to be processed by three different preprocessor programs
7 before it is compiled. Most users will download a
8 [http://www.fossil-scm.org/download.html | precompiled binary]
9 so this is of no consequence to them, and even those who
10 want to compile the code themselves can use one of the
11 [./build.wiki | existing makefiles].
12 So must people do not need to be concerned with the
13 build complexities of Fossil. But hard-core developers who desire
14 a deep understanding of how Fossil is put together can benefit
15 from reviewing this article.
16
17 <a name="srctour"></a>
18 <h1>2.0 Source Code Tour</h1>
19
20 The source code for Fossil is found in the
21 [/dir?ci=trunk&name=src | src/] subdirectory of the
22 source tree. The src/ subdirectory contains all code, including
23 the code for the separate preprocessor programs.
24
25 Each preprocessor program is a separate C program implemented in
@@ -50,11 +50,11 @@
50 The TH1 script engine is implemented using files:
51
52 7. th.c
53 8. th.h
54
55 These two files are imports like the SQLite source files,
56 and so are not preprocessed.
57
58 The VERSION.h header file is generated from other information sources
59 using a small program called:
60
@@ -86,11 +86,11 @@
86
87 13. main.mk
88
89 The main.mk makefile is invoked from the Makefile in the top-level
90 directory. The main.mk is generated by makemake.tcl and should not
91 be hand edited. Other makefiles generated by makemake.tcl are in
92 other subdirectories (currently all in the win/ subdirectory).
93
94 All the other files in the src/ subdirectory (79 files at the time of
95 this writing) are C source code files that are subject to the
96 preprocessing steps described below. In the sequel, we will call these
@@ -109,11 +109,11 @@
109 (The "manifest" and "manifest.uuid" files are automatically generated and
110 updated by Fossil itself. See the [/help/setting | fossil set manifest]
111 command for additional information.)
112
113 The VERSION.h header file is generated by
114 a C program: src/mkversion.c.
115 To run the VERSION.h generator, first compile the src/mkversion.c
116 source file into a command-line program (named "mkversion.exe")
117 then run:
118
119 <blockquote><pre>
@@ -126,11 +126,11 @@
126 in the root of the source tree are the three arguments and
127 the generated VERSION.h file appears on standard output.
128
129 The builtin_data.h header file is generated by a C program: src/mkbuiltin.c.
130 The builtin_data.h file contains C-langauge byte-array definitions for
131 the content of resource files used by Fossil. To generate the
132 builtin_data.h file, first compile the mkbuiltin.c program, then run:
133
134 <blockquote><pre>
135 mkbuiltin.exe diff.tcl <i>OtherFiles...</i> &gt;builtin_data.h
136 </pre></blockquote>
@@ -163,11 +163,11 @@
163 Note that "src.c" in the above is a stand-in for the (79) regular source
164 files of Fossil - all source files except for the exceptions described in
165 section 2.0 above.
166
167 The output of the mkindex program is a header file that is #include-ed by
168 the main.c source file during the final compilation step.
169
170 <h2>4.2 The translate preprocessor</h2>
171
172 The translate preprocessor looks for lines of source code that begin
173 with "@" and converts those lines into string constants or (depending on
@@ -181,11 +181,11 @@
181 </pre></blockquote>
182
183 In this case, the "src.c" file represents any single source file from the
184 set of ordinary source files as described in section 2.0 above. Note that
185 each source file is translated separately. By convention, the names of
186 the translated source files are the names of the input sources with a
187 single "_" character at the end. But a new makefile can use any naming
188 convention it wants - the "_" is not critical to the build process.
189
190 After being translated, the output files (the "src_.c" files) should be
191 used for all subsequent preprocessing and compilation steps.
@@ -209,16 +209,16 @@
209 <blockquote><pre>
210 makeheaders src_.c:src.h sqlite3.h th.h VERSION.h
211 </pre></blockquote>
212
213 In the example above the "src_.c" and "src.h" names represent all of the
214 (79) ordinary C source files, each as a separate argument.
215
216 <h1>5.0 Compilation</h1>
217
218 After all generated files have been created and all ordinary source files
219 have been preprocessed, the generated and preprocessed files can be
220 combined into a single executable using a C compiler. This can be done
221 all at once, or each preprocessed source file can be compiled into a
222 separate object code file and the resulting object code files linked
223 together in a final step.
224
@@ -247,11 +247,11 @@
247 * -Dmain=sqlite3_main
248 * -DSQLITE_OMIT_LOAD_EXTENSION=1
249
250 The "main()" routine in the shell must be changed into sqlite3_main()
251 to prevent it from colliding with the real main() in Fossil, and to give
252 Fossil an entry point to jump to when the
253 [/help/sqlite3 | fossil sql] command is invoked.
254
255 All the other source code files can be compiled without any special
256 options.
257
258
--- www/makefile.wiki
+++ www/makefile.wiki
@@ -2,24 +2,24 @@
2
3 <h1>1.0 Introduction</h1>
4
5 The build process for Fossil is tricky in that the source code
6 needs to be processed by three different preprocessor programs
7 before it is compiled. Most users will download a
8 [http://www.fossil-scm.org/download.html | precompiled binary]
9 so this is of no consequence to them, and even those who
10 want to compile the code themselves can use one of the
11 [./build.wiki | existing makefiles].
12 So must people do not need to be concerned with the
13 build complexities of Fossil. But hard-core developers who desire
14 a deep understanding of how Fossil is put together can benefit
15 from reviewing this article.
16
17 <a name="srctour"></a>
18 <h1>2.0 Source Code Tour</h1>
19
20 The source code for Fossil is found in the
21 [/dir?ci=trunk&name=src | src/] subdirectory of the
22 source tree. The src/ subdirectory contains all code, including
23 the code for the separate preprocessor programs.
24
25 Each preprocessor program is a separate C program implemented in
@@ -50,11 +50,11 @@
50 The TH1 script engine is implemented using files:
51
52 7. th.c
53 8. th.h
54
55 These two files are imports like the SQLite source files,
56 and so are not preprocessed.
57
58 The VERSION.h header file is generated from other information sources
59 using a small program called:
60
@@ -86,11 +86,11 @@
86
87 13. main.mk
88
89 The main.mk makefile is invoked from the Makefile in the top-level
90 directory. The main.mk is generated by makemake.tcl and should not
91 be hand edited. Other makefiles generated by makemake.tcl are in
92 other subdirectories (currently all in the win/ subdirectory).
93
94 All the other files in the src/ subdirectory (79 files at the time of
95 this writing) are C source code files that are subject to the
96 preprocessing steps described below. In the sequel, we will call these
@@ -109,11 +109,11 @@
109 (The "manifest" and "manifest.uuid" files are automatically generated and
110 updated by Fossil itself. See the [/help/setting | fossil set manifest]
111 command for additional information.)
112
113 The VERSION.h header file is generated by
114 a C program: src/mkversion.c.
115 To run the VERSION.h generator, first compile the src/mkversion.c
116 source file into a command-line program (named "mkversion.exe")
117 then run:
118
119 <blockquote><pre>
@@ -126,11 +126,11 @@
126 in the root of the source tree are the three arguments and
127 the generated VERSION.h file appears on standard output.
128
129 The builtin_data.h header file is generated by a C program: src/mkbuiltin.c.
130 The builtin_data.h file contains C-langauge byte-array definitions for
131 the content of resource files used by Fossil. To generate the
132 builtin_data.h file, first compile the mkbuiltin.c program, then run:
133
134 <blockquote><pre>
135 mkbuiltin.exe diff.tcl <i>OtherFiles...</i> &gt;builtin_data.h
136 </pre></blockquote>
@@ -163,11 +163,11 @@
163 Note that "src.c" in the above is a stand-in for the (79) regular source
164 files of Fossil - all source files except for the exceptions described in
165 section 2.0 above.
166
167 The output of the mkindex program is a header file that is #include-ed by
168 the main.c source file during the final compilation step.
169
170 <h2>4.2 The translate preprocessor</h2>
171
172 The translate preprocessor looks for lines of source code that begin
173 with "@" and converts those lines into string constants or (depending on
@@ -181,11 +181,11 @@
181 </pre></blockquote>
182
183 In this case, the "src.c" file represents any single source file from the
184 set of ordinary source files as described in section 2.0 above. Note that
185 each source file is translated separately. By convention, the names of
186 the translated source files are the names of the input sources with a
187 single "_" character at the end. But a new makefile can use any naming
188 convention it wants - the "_" is not critical to the build process.
189
190 After being translated, the output files (the "src_.c" files) should be
191 used for all subsequent preprocessing and compilation steps.
@@ -209,16 +209,16 @@
209 <blockquote><pre>
210 makeheaders src_.c:src.h sqlite3.h th.h VERSION.h
211 </pre></blockquote>
212
213 In the example above the "src_.c" and "src.h" names represent all of the
214 (79) ordinary C source files, each as a separate argument.
215
216 <h1>5.0 Compilation</h1>
217
218 After all generated files have been created and all ordinary source files
219 have been preprocessed, the generated and preprocessed files can be
220 combined into a single executable using a C compiler. This can be done
221 all at once, or each preprocessed source file can be compiled into a
222 separate object code file and the resulting object code files linked
223 together in a final step.
224
@@ -247,11 +247,11 @@
247 * -Dmain=sqlite3_main
248 * -DSQLITE_OMIT_LOAD_EXTENSION=1
249
250 The "main()" routine in the shell must be changed into sqlite3_main()
251 to prevent it from colliding with the real main() in Fossil, and to give
252 Fossil an entry point to jump to when the
253 [/help/sqlite3 | fossil sql] command is invoked.
254
255 All the other source code files can be compiled without any special
256 options.
257
258
M www/newrepo.wiki
+1 -1
--- www/newrepo.wiki
+++ www/newrepo.wiki
@@ -53,11 +53,11 @@
5353
5454
 <verbatim>
5555
 stephan@ludo:~/fossil$ mkdir demo
5656
 stephan@ludo:~/fossil$ cd demo
5757
 stephan@ludo:~/fossil/demo$ fossil open ../demo.fossil
58
-stephan@ludo:~/fossil/demo$
58
+stephan@ludo:~/fossil/demo$
5959
 </verbatim>
6060
6161
 That creates a file called <tt>_FOSSIL_</tt> in the current
6262
 directory, and this file contains all kinds of fossil-related
6363
 information about your local repository. You can ignore it
6464
--- www/newrepo.wiki
+++ www/newrepo.wiki
@@ -53,11 +53,11 @@
53
54 <verbatim>
55 stephan@ludo:~/fossil$ mkdir demo
56 stephan@ludo:~/fossil$ cd demo
57 stephan@ludo:~/fossil/demo$ fossil open ../demo.fossil
58 stephan@ludo:~/fossil/demo$
59 </verbatim>
60
61 That creates a file called <tt>_FOSSIL_</tt> in the current
62 directory, and this file contains all kinds of fossil-related
63 information about your local repository. You can ignore it
64
--- www/newrepo.wiki
+++ www/newrepo.wiki
@@ -53,11 +53,11 @@
53
54 <verbatim>
55 stephan@ludo:~/fossil$ mkdir demo
56 stephan@ludo:~/fossil$ cd demo
57 stephan@ludo:~/fossil/demo$ fossil open ../demo.fossil
58 stephan@ludo:~/fossil/demo$
59 </verbatim>
60
61 That creates a file called <tt>_FOSSIL_</tt> in the current
62 directory, and this file contains all kinds of fossil-related
63 information about your local repository. You can ignore it
64
M www/pop.wiki
+5 -5
--- www/pop.wiki
+++ www/pop.wiki
@@ -4,18 +4,18 @@
44
 This page attempts to define the foundational principals upon
55
 which Fossil is built.
66
 </p>
77
88
 <ul>
9
-<li><p>A project consists of source files, wiki pages, and
9
+<li><p>A project consists of source files, wiki pages, and
1010
 trouble tickets, and control files (collectively "artifacts").
1111
 All historical copies of all artifacts
1212
 are saved. The project maintains an audit
1313
 trail.</p></li>
1414
1515
 <li><p>A project resides in one or more repositories. Each
16
-repository is administered and operates independently
16
+repository is administered and operates independently
1717
 of the others.</p></li>
1818
1919
 <li><p>Each repository has both global and local state. The
2020
 global state is common to all repositories (or at least
2121
 has the potential to be shared in common when the
@@ -24,28 +24,28 @@
2424
 The global state represents the content of the project.
2525
 The local state identifies the authorized users and
2626
 access policies for a particular repository.</p></li>
2727
2828
 <li><p>The global state of a repository is an unordered
29
-collection of artifacts. Each artifact is named by
29
+collection of artifacts. Each artifact is named by
3030
 its SHA1 hash encoded in lowercase hexadecimal.
3131
 In many contexts, the name can be
3232
 abbreviated to a unique prefix. A five- or six-character
3333
 prefix usually suffices to uniquely identify a file.</p></li>
3434
3535
 <li><p>Because artifacts are named by their SHA1 hash, all artifacts
36
-are immutable. Any change to the content of an artifact also
36
+are immutable. Any change to the content of an artifact also
3737
 changes the hash that forms the artifacts name, thus
3838
 creating a new artifact. Both the old original version of the
3939
 artifact and the new change are preserved under different names.</p></li>
4040
4141
 <li><p>It is theoretically possible for two artifacts with different
4242
 content to share the same hash. But finding two such
4343
 artifacts is so incredibly difficult and unlikely that we
4444
 consider it to be an impossibility.</p></li>
4545
46
-<li><p>The signature of an artifact is the SHA1 hash of the
46
+<li><p>The signature of an artifact is the SHA1 hash of the
4747
 artifact itself, exactly as it would appear in a disk file. No prefix
4848
 or meta-information about the artifact is added before computing
4949
 the hash. So you can
5050
 always find the SHA1 signature of a file by using the
5151
 "sha1sum" command-line utility.</p></li>
5252
--- www/pop.wiki
+++ www/pop.wiki
@@ -4,18 +4,18 @@
4 This page attempts to define the foundational principals upon
5 which Fossil is built.
6 </p>
7
8 <ul>
9 <li><p>A project consists of source files, wiki pages, and
10 trouble tickets, and control files (collectively "artifacts").
11 All historical copies of all artifacts
12 are saved. The project maintains an audit
13 trail.</p></li>
14
15 <li><p>A project resides in one or more repositories. Each
16 repository is administered and operates independently
17 of the others.</p></li>
18
19 <li><p>Each repository has both global and local state. The
20 global state is common to all repositories (or at least
21 has the potential to be shared in common when the
@@ -24,28 +24,28 @@
24 The global state represents the content of the project.
25 The local state identifies the authorized users and
26 access policies for a particular repository.</p></li>
27
28 <li><p>The global state of a repository is an unordered
29 collection of artifacts. Each artifact is named by
30 its SHA1 hash encoded in lowercase hexadecimal.
31 In many contexts, the name can be
32 abbreviated to a unique prefix. A five- or six-character
33 prefix usually suffices to uniquely identify a file.</p></li>
34
35 <li><p>Because artifacts are named by their SHA1 hash, all artifacts
36 are immutable. Any change to the content of an artifact also
37 changes the hash that forms the artifacts name, thus
38 creating a new artifact. Both the old original version of the
39 artifact and the new change are preserved under different names.</p></li>
40
41 <li><p>It is theoretically possible for two artifacts with different
42 content to share the same hash. But finding two such
43 artifacts is so incredibly difficult and unlikely that we
44 consider it to be an impossibility.</p></li>
45
46 <li><p>The signature of an artifact is the SHA1 hash of the
47 artifact itself, exactly as it would appear in a disk file. No prefix
48 or meta-information about the artifact is added before computing
49 the hash. So you can
50 always find the SHA1 signature of a file by using the
51 "sha1sum" command-line utility.</p></li>
52
--- www/pop.wiki
+++ www/pop.wiki
@@ -4,18 +4,18 @@
4 This page attempts to define the foundational principals upon
5 which Fossil is built.
6 </p>
7
8 <ul>
9 <li><p>A project consists of source files, wiki pages, and
10 trouble tickets, and control files (collectively "artifacts").
11 All historical copies of all artifacts
12 are saved. The project maintains an audit
13 trail.</p></li>
14
15 <li><p>A project resides in one or more repositories. Each
16 repository is administered and operates independently
17 of the others.</p></li>
18
19 <li><p>Each repository has both global and local state. The
20 global state is common to all repositories (or at least
21 has the potential to be shared in common when the
@@ -24,28 +24,28 @@
24 The global state represents the content of the project.
25 The local state identifies the authorized users and
26 access policies for a particular repository.</p></li>
27
28 <li><p>The global state of a repository is an unordered
29 collection of artifacts. Each artifact is named by
30 its SHA1 hash encoded in lowercase hexadecimal.
31 In many contexts, the name can be
32 abbreviated to a unique prefix. A five- or six-character
33 prefix usually suffices to uniquely identify a file.</p></li>
34
35 <li><p>Because artifacts are named by their SHA1 hash, all artifacts
36 are immutable. Any change to the content of an artifact also
37 changes the hash that forms the artifacts name, thus
38 creating a new artifact. Both the old original version of the
39 artifact and the new change are preserved under different names.</p></li>
40
41 <li><p>It is theoretically possible for two artifacts with different
42 content to share the same hash. But finding two such
43 artifacts is so incredibly difficult and unlikely that we
44 consider it to be an impossibility.</p></li>
45
46 <li><p>The signature of an artifact is the SHA1 hash of the
47 artifact itself, exactly as it would appear in a disk file. No prefix
48 or meta-information about the artifact is added before computing
49 the hash. So you can
50 always find the SHA1 signature of a file by using the
51 "sha1sum" command-line utility.</p></li>
52
M www/private.wiki
+3 -3
--- www/private.wiki
+++ www/private.wiki
@@ -41,11 +41,11 @@
4141
 <h2>Syncing Private Branches</h2>
4242
4343
 A private branch normally stays on the one repository where it was
4444
 originally created. But sometimes you want to share private branches
4545
 with another repository. For example, you might be building a cross-platform
46
-application and have separate repositories on your Windows laptop,
46
+application and have separate repositories on your Windows laptop,
4747
 your Linux desktop, and your iMac. You can transfer private branches
4848
 between these machines by using the --private option on the "sync",
4949
 "push", "pull", and "clone" commands. For example, if you are running
5050
 "fossil server" on your Linux box and you want to clone that repository
5151
 to your Mac, including all private branches, use:
@@ -67,11 +67,11 @@
6767
 only enable "x" for local repositories when you need to share private
6868
 branches.
6969
7070
 Private branch sync only works if you use the --private command-line option.
7171
 Private branches are never synced via the auto-sync mechanism. Once
72
-again, this restriction is designed to make it hard to accidently
72
+again, this restriction is designed to make it hard to accidently
7373
 push private branches beyond their intended audience.
7474
7575
 <h2>Purging Private Branches</h2>
7676
7777
 You can remove all private branches from a repository using this command:
@@ -85,10 +85,10 @@
8585
 removed, they cannot be retrieved (unless you have synced them to another
8686
 repository.) So be careful with the command.
8787
8888
 <h2>Additional Notes</h2>
8989
90
-All of the features above apply to <u>all</u> private branches in a
90
+All of the features above apply to <u>all</u> private branches in a
9191
 single repository at once. There is no mechanism in Fossil (currently)
9292
 that allows you to push, pull, clone, sync, or scrub and individual
9393
 private branch within a repository that contains multiple private
9494
 branches.
9595
--- www/private.wiki
+++ www/private.wiki
@@ -41,11 +41,11 @@
41 <h2>Syncing Private Branches</h2>
42
43 A private branch normally stays on the one repository where it was
44 originally created. But sometimes you want to share private branches
45 with another repository. For example, you might be building a cross-platform
46 application and have separate repositories on your Windows laptop,
47 your Linux desktop, and your iMac. You can transfer private branches
48 between these machines by using the --private option on the "sync",
49 "push", "pull", and "clone" commands. For example, if you are running
50 "fossil server" on your Linux box and you want to clone that repository
51 to your Mac, including all private branches, use:
@@ -67,11 +67,11 @@
67 only enable "x" for local repositories when you need to share private
68 branches.
69
70 Private branch sync only works if you use the --private command-line option.
71 Private branches are never synced via the auto-sync mechanism. Once
72 again, this restriction is designed to make it hard to accidently
73 push private branches beyond their intended audience.
74
75 <h2>Purging Private Branches</h2>
76
77 You can remove all private branches from a repository using this command:
@@ -85,10 +85,10 @@
85 removed, they cannot be retrieved (unless you have synced them to another
86 repository.) So be careful with the command.
87
88 <h2>Additional Notes</h2>
89
90 All of the features above apply to <u>all</u> private branches in a
91 single repository at once. There is no mechanism in Fossil (currently)
92 that allows you to push, pull, clone, sync, or scrub and individual
93 private branch within a repository that contains multiple private
94 branches.
95
--- www/private.wiki
+++ www/private.wiki
@@ -41,11 +41,11 @@
41 <h2>Syncing Private Branches</h2>
42
43 A private branch normally stays on the one repository where it was
44 originally created. But sometimes you want to share private branches
45 with another repository. For example, you might be building a cross-platform
46 application and have separate repositories on your Windows laptop,
47 your Linux desktop, and your iMac. You can transfer private branches
48 between these machines by using the --private option on the "sync",
49 "push", "pull", and "clone" commands. For example, if you are running
50 "fossil server" on your Linux box and you want to clone that repository
51 to your Mac, including all private branches, use:
@@ -67,11 +67,11 @@
67 only enable "x" for local repositories when you need to share private
68 branches.
69
70 Private branch sync only works if you use the --private command-line option.
71 Private branches are never synced via the auto-sync mechanism. Once
72 again, this restriction is designed to make it hard to accidently
73 push private branches beyond their intended audience.
74
75 <h2>Purging Private Branches</h2>
76
77 You can remove all private branches from a repository using this command:
@@ -85,10 +85,10 @@
85 removed, they cannot be retrieved (unless you have synced them to another
86 repository.) So be careful with the command.
87
88 <h2>Additional Notes</h2>
89
90 All of the features above apply to <u>all</u> private branches in a
91 single repository at once. There is no mechanism in Fossil (currently)
92 that allows you to push, pull, clone, sync, or scrub and individual
93 private branch within a repository that contains multiple private
94 branches.
95
M www/qandc.wiki
+10 -10
--- www/qandc.wiki
+++ www/qandc.wiki
@@ -22,11 +22,11 @@
2222
 <li> Integrated <a href="wikitheory.wiki">wiki</a>. </li>
2323
 <li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li>
2424
 <li> Immutable artifacts </li>
2525
 <li> Self-contained, stand-alone executable that can be run in
2626
 a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li>
27
- <li> Simple, well-defined,
27
+ <li> Simple, well-defined,
2828
 <a href="fileformat.wiki">enduring file format</a> </li>
2929
 <li> Integrated <a href="webui.wiki">web interface</a> </li>
3030
 </ol>
3131
 </blockquote>
3232
@@ -36,11 +36,11 @@
3636
 <ol>
3737
 <li> Fossil is distributed. You can view and/or edit tickets, wiki, and
3838
 code while off network, then sync your changes later. With Trac, you
3939
 can only view and edit tickets and wiki while you are connected to
4040
 the server. </li>
41
- <li> Fossil is lightweight and fully self-contained. It is very easy
41
+ <li> Fossil is lightweight and fully self-contained. It is very easy
4242
 to setup on a low-resource machine. Fossil does not require an
4343
 administrator.</li>
4444
 <li> Fossil integrates code versioning into the same repository with
4545
 wiki and tickets. There is nothing extra to add or install.
4646
 Fossil is an all-in-one turnkey solution. </li>
@@ -48,25 +48,25 @@
4848
 </blockquote>
4949
5050
 <b>Love the concept here. Anyone using this for real work yet?</b>
5151
5252
 <blockquote>
53
-Fossil is <a href="http://www.fossil-scm.org/">self-hosting</a>.
53
+Fossil is <a href="http://www.fossil-scm.org/">self-hosting</a>.
5454
 In fact, this page was probably delivered
5555
 to your web-browser via a working fossil instance. The same virtual
5656
 machine that hosts http://www.fossil-scm.org/
5757
 (a <a href="http://www.linode.com/">Linode 720</a>)
5858
 also hosts 24 other fossil repositories for various small projects.
59
-The documentation files for
59
+The documentation files for
6060
 <a href="http://www.sqlite.org/">SQLite</a> are hosted in a
6161
 fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>,
6262
 for example.
6363
 Other projects are also adopting fossil. But fossil does not yet have
6464
 the massive user base of git or mercurial.
6565
 </blockquote>
6666
67
-<b>Fossil looks like the bug tracker that would be in your
67
+<b>Fossil looks like the bug tracker that would be in your
6868
 Linksys Router's administration screen.</b>
6969
7070
 <blockquote>
7171
 <p>I take a pragmatic approach to software: form follows function.
7272
 To me, it is more important to have a reliable, fast, efficient,
@@ -83,11 +83,11 @@
8383
 keeps the bug-tracking database in a versioned file. That file can
8484
 then be pushed and pulled along with the rest repository.</b>
8585
8686
 <blockquote>
8787
 <p>Fossil already <u>does</u> push and pull bugs along with the files
88
-in your repository.
88
+in your repository.
8989
 But fossil does <u>not</u> track bugs as files in the source tree.
9090
 That approach to bug tracking was rejected for three reasons:</p>
9191
9292
 <ol>
9393
 <li> Check-ins in fossil are immutable. So if
@@ -108,11 +108,11 @@
108108
109109
 <p>These points are reiterated in the opening paragraphs of
110110
 the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.</p>
111111
 </blockquote>
112112
113
-<b>Fossil is already the name of a plan9 versioned
113
+<b>Fossil is already the name of a plan9 versioned
114114
 append-only filesystem.</b>
115115
116116
 <blockquote>
117117
 I did not know that. Perhaps they selected the name for the same reason that
118118
 I did: because a repository with immutable artifacts preserves
@@ -137,22 +137,22 @@
137137
 Subversion or Bazaar.</b>
138138
139139
 <blockquote>
140140
 <p>I have no doubt that Trac has many features that fossil lacks. But that
141141
 is not the point. Fossil has several key features that Trac lacks and that
142
-I need: most notably the fact that
142
+I need: most notably the fact that
143143
 fossil supports disconnected operation.</p>
144144
145145
 <p>As for bloat: Fossil is a single self-contained executable.
146
-You do not need any other packages
146
+You do not need any other packages
147147
 (diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache,
148148
 sqlite, and so forth)
149149
 in order to run fossil. Fossil runs just fine in a chroot jail all
150150
 by itself. And the self-contained fossil
151151
 executable is much less than 1MB in size. (Update 2015-01-12: Fossil has
152
-grown in the years since the previous sentence was written but is still
152
+grown in the years since the previous sentence was written but is still
153153
 much less than 2MB according to "size" when compiled using -Os on x64 Linux.)
154154
 Fossil is the very opposite of bloat.</p>
155155
 </blockquote>
156156
157157
158158
 </nowiki>
159159
--- www/qandc.wiki
+++ www/qandc.wiki
@@ -22,11 +22,11 @@
22 <li> Integrated <a href="wikitheory.wiki">wiki</a>. </li>
23 <li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li>
24 <li> Immutable artifacts </li>
25 <li> Self-contained, stand-alone executable that can be run in
26 a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li>
27 <li> Simple, well-defined,
28 <a href="fileformat.wiki">enduring file format</a> </li>
29 <li> Integrated <a href="webui.wiki">web interface</a> </li>
30 </ol>
31 </blockquote>
32
@@ -36,11 +36,11 @@
36 <ol>
37 <li> Fossil is distributed. You can view and/or edit tickets, wiki, and
38 code while off network, then sync your changes later. With Trac, you
39 can only view and edit tickets and wiki while you are connected to
40 the server. </li>
41 <li> Fossil is lightweight and fully self-contained. It is very easy
42 to setup on a low-resource machine. Fossil does not require an
43 administrator.</li>
44 <li> Fossil integrates code versioning into the same repository with
45 wiki and tickets. There is nothing extra to add or install.
46 Fossil is an all-in-one turnkey solution. </li>
@@ -48,25 +48,25 @@
48 </blockquote>
49
50 <b>Love the concept here. Anyone using this for real work yet?</b>
51
52 <blockquote>
53 Fossil is <a href="http://www.fossil-scm.org/">self-hosting</a>.
54 In fact, this page was probably delivered
55 to your web-browser via a working fossil instance. The same virtual
56 machine that hosts http://www.fossil-scm.org/
57 (a <a href="http://www.linode.com/">Linode 720</a>)
58 also hosts 24 other fossil repositories for various small projects.
59 The documentation files for
60 <a href="http://www.sqlite.org/">SQLite</a> are hosted in a
61 fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>,
62 for example.
63 Other projects are also adopting fossil. But fossil does not yet have
64 the massive user base of git or mercurial.
65 </blockquote>
66
67 <b>Fossil looks like the bug tracker that would be in your
68 Linksys Router's administration screen.</b>
69
70 <blockquote>
71 <p>I take a pragmatic approach to software: form follows function.
72 To me, it is more important to have a reliable, fast, efficient,
@@ -83,11 +83,11 @@
83 keeps the bug-tracking database in a versioned file. That file can
84 then be pushed and pulled along with the rest repository.</b>
85
86 <blockquote>
87 <p>Fossil already <u>does</u> push and pull bugs along with the files
88 in your repository.
89 But fossil does <u>not</u> track bugs as files in the source tree.
90 That approach to bug tracking was rejected for three reasons:</p>
91
92 <ol>
93 <li> Check-ins in fossil are immutable. So if
@@ -108,11 +108,11 @@
108
109 <p>These points are reiterated in the opening paragraphs of
110 the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.</p>
111 </blockquote>
112
113 <b>Fossil is already the name of a plan9 versioned
114 append-only filesystem.</b>
115
116 <blockquote>
117 I did not know that. Perhaps they selected the name for the same reason that
118 I did: because a repository with immutable artifacts preserves
@@ -137,22 +137,22 @@
137 Subversion or Bazaar.</b>
138
139 <blockquote>
140 <p>I have no doubt that Trac has many features that fossil lacks. But that
141 is not the point. Fossil has several key features that Trac lacks and that
142 I need: most notably the fact that
143 fossil supports disconnected operation.</p>
144
145 <p>As for bloat: Fossil is a single self-contained executable.
146 You do not need any other packages
147 (diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache,
148 sqlite, and so forth)
149 in order to run fossil. Fossil runs just fine in a chroot jail all
150 by itself. And the self-contained fossil
151 executable is much less than 1MB in size. (Update 2015-01-12: Fossil has
152 grown in the years since the previous sentence was written but is still
153 much less than 2MB according to "size" when compiled using -Os on x64 Linux.)
154 Fossil is the very opposite of bloat.</p>
155 </blockquote>
156
157
158 </nowiki>
159
--- www/qandc.wiki
+++ www/qandc.wiki
@@ -22,11 +22,11 @@
22 <li> Integrated <a href="wikitheory.wiki">wiki</a>. </li>
23 <li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li>
24 <li> Immutable artifacts </li>
25 <li> Self-contained, stand-alone executable that can be run in
26 a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li>
27 <li> Simple, well-defined,
28 <a href="fileformat.wiki">enduring file format</a> </li>
29 <li> Integrated <a href="webui.wiki">web interface</a> </li>
30 </ol>
31 </blockquote>
32
@@ -36,11 +36,11 @@
36 <ol>
37 <li> Fossil is distributed. You can view and/or edit tickets, wiki, and
38 code while off network, then sync your changes later. With Trac, you
39 can only view and edit tickets and wiki while you are connected to
40 the server. </li>
41 <li> Fossil is lightweight and fully self-contained. It is very easy
42 to setup on a low-resource machine. Fossil does not require an
43 administrator.</li>
44 <li> Fossil integrates code versioning into the same repository with
45 wiki and tickets. There is nothing extra to add or install.
46 Fossil is an all-in-one turnkey solution. </li>
@@ -48,25 +48,25 @@
48 </blockquote>
49
50 <b>Love the concept here. Anyone using this for real work yet?</b>
51
52 <blockquote>
53 Fossil is <a href="http://www.fossil-scm.org/">self-hosting</a>.
54 In fact, this page was probably delivered
55 to your web-browser via a working fossil instance. The same virtual
56 machine that hosts http://www.fossil-scm.org/
57 (a <a href="http://www.linode.com/">Linode 720</a>)
58 also hosts 24 other fossil repositories for various small projects.
59 The documentation files for
60 <a href="http://www.sqlite.org/">SQLite</a> are hosted in a
61 fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>,
62 for example.
63 Other projects are also adopting fossil. But fossil does not yet have
64 the massive user base of git or mercurial.
65 </blockquote>
66
67 <b>Fossil looks like the bug tracker that would be in your
68 Linksys Router's administration screen.</b>
69
70 <blockquote>
71 <p>I take a pragmatic approach to software: form follows function.
72 To me, it is more important to have a reliable, fast, efficient,
@@ -83,11 +83,11 @@
83 keeps the bug-tracking database in a versioned file. That file can
84 then be pushed and pulled along with the rest repository.</b>
85
86 <blockquote>
87 <p>Fossil already <u>does</u> push and pull bugs along with the files
88 in your repository.
89 But fossil does <u>not</u> track bugs as files in the source tree.
90 That approach to bug tracking was rejected for three reasons:</p>
91
92 <ol>
93 <li> Check-ins in fossil are immutable. So if
@@ -108,11 +108,11 @@
108
109 <p>These points are reiterated in the opening paragraphs of
110 the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.</p>
111 </blockquote>
112
113 <b>Fossil is already the name of a plan9 versioned
114 append-only filesystem.</b>
115
116 <blockquote>
117 I did not know that. Perhaps they selected the name for the same reason that
118 I did: because a repository with immutable artifacts preserves
@@ -137,22 +137,22 @@
137 Subversion or Bazaar.</b>
138
139 <blockquote>
140 <p>I have no doubt that Trac has many features that fossil lacks. But that
141 is not the point. Fossil has several key features that Trac lacks and that
142 I need: most notably the fact that
143 fossil supports disconnected operation.</p>
144
145 <p>As for bloat: Fossil is a single self-contained executable.
146 You do not need any other packages
147 (diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache,
148 sqlite, and so forth)
149 in order to run fossil. Fossil runs just fine in a chroot jail all
150 by itself. And the self-contained fossil
151 executable is much less than 1MB in size. (Update 2015-01-12: Fossil has
152 grown in the years since the previous sentence was written but is still
153 much less than 2MB according to "size" when compiled using -Os on x64 Linux.)
154 Fossil is the very opposite of bloat.</p>
155 </blockquote>
156
157
158 </nowiki>
159
M www/quickstart.wiki
+26 -26
--- www/quickstart.wiki
+++ www/quickstart.wiki
@@ -5,16 +5,16 @@
55
 and painlessly.</p>
66
77
 <h2>Installing</h2>
88
99
 <p>Fossil is a single self-contained C program. You need to
10
- either download a
10
+ either download a
1111
 <a href="http://www.fossil-scm.org/download.html">precompiled binary</a>
1212
 or <a href="build.wiki">compile it yourself</a> from sources.
1313
 Install fossil by putting the fossil binary
1414
 someplace on your $PATH.</p>
15
-
15
+
1616
 <a name="fslclone"></a>
1717
 <h2>General Work Flow</h2>
1818
1919
 <p>Fossil works with repository files (a database with the project's
2020
 complete history) and with checked-out local trees (the working directory
@@ -34,11 +34,11 @@
3434
3535
 <h2>Starting A New Project</h2>
3636
3737
 <p>To start a new project with fossil, create a new empty repository
3838
 this way: ([/help/init | more info]) </p>
39
-
39
+
4040
 <blockquote>
4141
 <b>fossil init </b><i> repository-filename</i>
4242
 </blockquote>
4343
4444
 <h2>Cloning An Existing Repository</h2>
@@ -46,36 +46,36 @@
4646
 <p>Most fossil operations interact with a repository that is on the
4747
 local disk drive, not on a remote system. Hence, before accessing
4848
 a remote repository it is necessary to make a local copy of that
4949
 repository. Making a local copy of a remote repository is called
5050
 "cloning".</p>
51
-
51
+
5252
 <p>Clone a remote repository as follows: ([/help/clone | more info])</p>
53
-
53
+
5454
 <blockquote>
5555
 <b>fossil clone</b> <i>URL repository-filename</i>
5656
 </blockquote>
57
-
57
+
5858
 <p>The <i>URL</i> specifies the fossil repository
5959
 you want to clone. The <i>repository-filename</i> is the new local
6060
 filename into which the cloned repository will be written. For
6161
 example:
62
-
62
+
6363
 <blockquote>
6464
 <b>fossil clone http://www.fossil-scm.org/ myclone.fossil</b>
6565
 </blockquote>
6666
67
- <p>If the remote repository requires a login, include a
67
+ <p>If the remote repository requires a login, include a
6868
 userid in the URL like this:
6969
7070
 <blockquote>
7171
 <b>fossil clone http://</b><i>userid</i><b>@www.fossil-scm.org/ myclone.fossil</b>
7272
 </blockquote>
73
-
73
+
7474
7575
 <p>You will be prompted separately for the password.
76
- Use "%HH" escapes for special characters in the userid.
76
+ Use "%HH" escapes for special characters in the userid.
7777
 Examples: "%40" in place of "@" and "%2F" in place of "/".
7878
7979
 <p>If you are behind a restrictive firewall, you might need
8080
 to <a href="#proxy">specify an HTTP proxy</a>.</p>
8181
@@ -85,31 +85,31 @@
8585
 information above and beyond the versioned files, including some
8686
 sensitive information such as password hashes and email addresses. If you
8787
 want to share Fossil repositories directly, consider running the
8888
 [/help/scrub|fossil scrub] command to remove sensitive information
8989
 before transmitting the file.
90
-
90
+
9191
 <h2>Importing From Another Version Control System</h2>
9292
9393
 <p>Rather than start a new project, or clone an existing Fossil project,
94
- you might prefer to
94
+ you might prefer to
9595
 <a href="./inout.wiki">import an existing Git project</a>
9696
 into Fossil using the [/help/import | fossil import] command.
9797
9898
 <h2>Checking Out A Local Tree</h2>
9999
100100
 <p>To work on a project in fossil, you need to check out a local
101101
 copy of the source tree. Create the directory you want to be
102102
 the root of your tree and cd into that directory. Then
103103
 do this: ([/help/open | more info])</p>
104
-
104
+
105105
 <blockquote>
106106
 <b>fossil open </b><i> repository-filename</i>
107107
 </blockquote>
108
-
108
+
109109
 <p>This leaves you with the newest version of the tree
110
- checked out.
110
+ checked out.
111111
 From anywhere underneath the root of your local tree, you
112112
 can type commands like the following to find out the status of
113113
 your local tree:</p>
114114
115115
 <blockquote>
@@ -122,11 +122,11 @@
122122
 <b>[/help/branch | fossil branch]</b><br>
123123
 </blockquote>
124124
125125
 <p>Note that Fossil allows you to make multiple check-outs in
126126
 separate directories from the same repository. This enables you,
127
- for example, to do builds from multiple branches or versions at
127
+ for example, to do builds from multiple branches or versions at
128128
 the same time without having to generate extra clones.</p>
129129
130130
 <p>To switch a checkout between different versions and branches,
131131
 use:</p>
132132
@@ -140,17 +140,17 @@
140140
 version, whereas [/help/checkout | checkout] does not
141141
 automatically sync and does a "hard" switch, overwriting local
142142
 changes if told to do so.</p>
143143
144144
 <h2>Configuring Your Local Repository</h2>
145
-
145
+
146146
 <p>When you create a new repository, either by cloning an existing
147147
 project or create a new project of your own, you usually want to do some
148148
 local configuration. This is easily accomplished using the web-server
149149
 that is built into fossil. Start the fossil webserver like this:
150150
 ([/help/ui | more info])</p>
151
-
151
+
152152
 <blockquote>
153153
 <b>fossil ui </b><i> repository-filename</i>
154154
 </blockquote>
155155
156156
 <p>You can omit the <i>repository-filename</i> from the command above
@@ -163,15 +163,15 @@
163163
 where to find your web browser using a command like this:</p>
164164
165165
 <blockquote>
166166
 <b>fossil setting web-browser </b><i> path-to-web-browser</i>
167167
 </blockquote>
168
-
168
+
169169
 <p>By default, fossil does not require a login for HTTP connections
170170
 coming in from the IP loopback address 127.0.0.1. You can, and perhaps
171171
 should, change this after you create a few users.</p>
172
-
172
+
173173
 <p>When you are finished configuring, just press Control-C or use
174174
 the <b>kill</b> command to shut down the mini-server.</p>
175175
176176
 <h2>Making Changes</h2>
177177
@@ -194,18 +194,18 @@
194194
 <p>You will be prompted for check-in comments using whatever editor
195195
 is specified by your VISUAL or EDITOR environment variable.</p>
196196
197197
 In the default configuration, the [/help/commit|commit]
198198
 command will also automatically [/help/push|push] your changes, but that
199
- feature can be disabled. (More information about
199
+ feature can be disabled. (More information about
200200
 [./concepts.wiki#workflow|autosync] and how to disable it.)
201
- Remember that your coworkers can not see your changes until you
201
+ Remember that your coworkers can not see your changes until you
202202
 commit and push them.</p>
203203
204204
 <h2>Sharing Changes</h2>
205205
206
- <p>When [./concepts.wiki#workflow|autosync] is turned off,
206
+ <p>When [./concepts.wiki#workflow|autosync] is turned off,
207207
 the changes you [/help/commit | commit] are only
208208
 on your local repository.
209209
 To share those changes with other repositories, do:</p>
210210
211211
 <blockquote>
@@ -241,11 +241,11 @@
241241
 the <i>VERSION</i>, then fossil moves you to the
242242
 latest version of the branch your are currently on.</p>
243243
244244
 <p>The default behavior is for [./concepts.wiki#workflow|autosync] to
245245
 be turned on. That means that a [/help/pull|pull] automatically occurs
246
- when you run [/help/update|update] and a [/help/push|push] happens
246
+ when you run [/help/update|update] and a [/help/push|push] happens
247247
 automatically after you [/help/commit|commit]. So in normal practice,
248248
 the push, pull, and sync commands are rarely used. But it is important
249249
 to know about them, all the same.</p>
250250
251251
 <blockquote>
@@ -342,11 +342,11 @@
342342
 <li>[./server.wiki#cgi|CGI]
343343
 <li>[./server.wiki#scgi|SCGI]
344344
 </ul>
345345
346346
 <p>The [./selfhost.wiki | self-hosting fossil repositories] use
347
- CGI.
347
+ CGI.
348348
349349
 <a name="proxy"></a>
350350
 <h2>HTTP Proxies</h2>
351351
352352
 <p>If you are behind a restrictive firewall that requires you to use
@@ -382,11 +382,11 @@
382382
 <p>Or unset the environment variable. The fossil setting for the
383383
 HTTP proxy takes precedence over the environment variable and the
384384
 command-line option overrides both. If you have an persistent
385385
 proxy setting that you want to override for a one-time sync, that
386386
 is easily done on the command-line. For example, to sync with
387
- a co-workers repository on your LAN, you might type:</p>
387
+ a co-workers repository on your LAN, you might type:</p>
388388
389389
 <blockquote>
390390
 <b>fossil sync http://192.168.1.36:8080/ --proxy off</b>
391391
 </blockquote>
392392
393393
--- www/quickstart.wiki
+++ www/quickstart.wiki
@@ -5,16 +5,16 @@
5 and painlessly.</p>
6
7 <h2>Installing</h2>
8
9 <p>Fossil is a single self-contained C program. You need to
10 either download a
11 <a href="http://www.fossil-scm.org/download.html">precompiled binary</a>
12 or <a href="build.wiki">compile it yourself</a> from sources.
13 Install fossil by putting the fossil binary
14 someplace on your $PATH.</p>
15
16 <a name="fslclone"></a>
17 <h2>General Work Flow</h2>
18
19 <p>Fossil works with repository files (a database with the project's
20 complete history) and with checked-out local trees (the working directory
@@ -34,11 +34,11 @@
34
35 <h2>Starting A New Project</h2>
36
37 <p>To start a new project with fossil, create a new empty repository
38 this way: ([/help/init | more info]) </p>
39
40 <blockquote>
41 <b>fossil init </b><i> repository-filename</i>
42 </blockquote>
43
44 <h2>Cloning An Existing Repository</h2>
@@ -46,36 +46,36 @@
46 <p>Most fossil operations interact with a repository that is on the
47 local disk drive, not on a remote system. Hence, before accessing
48 a remote repository it is necessary to make a local copy of that
49 repository. Making a local copy of a remote repository is called
50 "cloning".</p>
51
52 <p>Clone a remote repository as follows: ([/help/clone | more info])</p>
53
54 <blockquote>
55 <b>fossil clone</b> <i>URL repository-filename</i>
56 </blockquote>
57
58 <p>The <i>URL</i> specifies the fossil repository
59 you want to clone. The <i>repository-filename</i> is the new local
60 filename into which the cloned repository will be written. For
61 example:
62
63 <blockquote>
64 <b>fossil clone http://www.fossil-scm.org/ myclone.fossil</b>
65 </blockquote>
66
67 <p>If the remote repository requires a login, include a
68 userid in the URL like this:
69
70 <blockquote>
71 <b>fossil clone http://</b><i>userid</i><b>@www.fossil-scm.org/ myclone.fossil</b>
72 </blockquote>
73
74
75 <p>You will be prompted separately for the password.
76 Use "%HH" escapes for special characters in the userid.
77 Examples: "%40" in place of "@" and "%2F" in place of "/".
78
79 <p>If you are behind a restrictive firewall, you might need
80 to <a href="#proxy">specify an HTTP proxy</a>.</p>
81
@@ -85,31 +85,31 @@
85 information above and beyond the versioned files, including some
86 sensitive information such as password hashes and email addresses. If you
87 want to share Fossil repositories directly, consider running the
88 [/help/scrub|fossil scrub] command to remove sensitive information
89 before transmitting the file.
90
91 <h2>Importing From Another Version Control System</h2>
92
93 <p>Rather than start a new project, or clone an existing Fossil project,
94 you might prefer to
95 <a href="./inout.wiki">import an existing Git project</a>
96 into Fossil using the [/help/import | fossil import] command.
97
98 <h2>Checking Out A Local Tree</h2>
99
100 <p>To work on a project in fossil, you need to check out a local
101 copy of the source tree. Create the directory you want to be
102 the root of your tree and cd into that directory. Then
103 do this: ([/help/open | more info])</p>
104
105 <blockquote>
106 <b>fossil open </b><i> repository-filename</i>
107 </blockquote>
108
109 <p>This leaves you with the newest version of the tree
110 checked out.
111 From anywhere underneath the root of your local tree, you
112 can type commands like the following to find out the status of
113 your local tree:</p>
114
115 <blockquote>
@@ -122,11 +122,11 @@
122 <b>[/help/branch | fossil branch]</b><br>
123 </blockquote>
124
125 <p>Note that Fossil allows you to make multiple check-outs in
126 separate directories from the same repository. This enables you,
127 for example, to do builds from multiple branches or versions at
128 the same time without having to generate extra clones.</p>
129
130 <p>To switch a checkout between different versions and branches,
131 use:</p>
132
@@ -140,17 +140,17 @@
140 version, whereas [/help/checkout | checkout] does not
141 automatically sync and does a "hard" switch, overwriting local
142 changes if told to do so.</p>
143
144 <h2>Configuring Your Local Repository</h2>
145
146 <p>When you create a new repository, either by cloning an existing
147 project or create a new project of your own, you usually want to do some
148 local configuration. This is easily accomplished using the web-server
149 that is built into fossil. Start the fossil webserver like this:
150 ([/help/ui | more info])</p>
151
152 <blockquote>
153 <b>fossil ui </b><i> repository-filename</i>
154 </blockquote>
155
156 <p>You can omit the <i>repository-filename</i> from the command above
@@ -163,15 +163,15 @@
163 where to find your web browser using a command like this:</p>
164
165 <blockquote>
166 <b>fossil setting web-browser </b><i> path-to-web-browser</i>
167 </blockquote>
168
169 <p>By default, fossil does not require a login for HTTP connections
170 coming in from the IP loopback address 127.0.0.1. You can, and perhaps
171 should, change this after you create a few users.</p>
172
173 <p>When you are finished configuring, just press Control-C or use
174 the <b>kill</b> command to shut down the mini-server.</p>
175
176 <h2>Making Changes</h2>
177
@@ -194,18 +194,18 @@
194 <p>You will be prompted for check-in comments using whatever editor
195 is specified by your VISUAL or EDITOR environment variable.</p>
196
197 In the default configuration, the [/help/commit|commit]
198 command will also automatically [/help/push|push] your changes, but that
199 feature can be disabled. (More information about
200 [./concepts.wiki#workflow|autosync] and how to disable it.)
201 Remember that your coworkers can not see your changes until you
202 commit and push them.</p>
203
204 <h2>Sharing Changes</h2>
205
206 <p>When [./concepts.wiki#workflow|autosync] is turned off,
207 the changes you [/help/commit | commit] are only
208 on your local repository.
209 To share those changes with other repositories, do:</p>
210
211 <blockquote>
@@ -241,11 +241,11 @@
241 the <i>VERSION</i>, then fossil moves you to the
242 latest version of the branch your are currently on.</p>
243
244 <p>The default behavior is for [./concepts.wiki#workflow|autosync] to
245 be turned on. That means that a [/help/pull|pull] automatically occurs
246 when you run [/help/update|update] and a [/help/push|push] happens
247 automatically after you [/help/commit|commit]. So in normal practice,
248 the push, pull, and sync commands are rarely used. But it is important
249 to know about them, all the same.</p>
250
251 <blockquote>
@@ -342,11 +342,11 @@
342 <li>[./server.wiki#cgi|CGI]
343 <li>[./server.wiki#scgi|SCGI]
344 </ul>
345
346 <p>The [./selfhost.wiki | self-hosting fossil repositories] use
347 CGI.
348
349 <a name="proxy"></a>
350 <h2>HTTP Proxies</h2>
351
352 <p>If you are behind a restrictive firewall that requires you to use
@@ -382,11 +382,11 @@
382 <p>Or unset the environment variable. The fossil setting for the
383 HTTP proxy takes precedence over the environment variable and the
384 command-line option overrides both. If you have an persistent
385 proxy setting that you want to override for a one-time sync, that
386 is easily done on the command-line. For example, to sync with
387 a co-workers repository on your LAN, you might type:</p>
388
389 <blockquote>
390 <b>fossil sync http://192.168.1.36:8080/ --proxy off</b>
391 </blockquote>
392
393
--- www/quickstart.wiki
+++ www/quickstart.wiki
@@ -5,16 +5,16 @@
5 and painlessly.</p>
6
7 <h2>Installing</h2>
8
9 <p>Fossil is a single self-contained C program. You need to
10 either download a
11 <a href="http://www.fossil-scm.org/download.html">precompiled binary</a>
12 or <a href="build.wiki">compile it yourself</a> from sources.
13 Install fossil by putting the fossil binary
14 someplace on your $PATH.</p>
15
16 <a name="fslclone"></a>
17 <h2>General Work Flow</h2>
18
19 <p>Fossil works with repository files (a database with the project's
20 complete history) and with checked-out local trees (the working directory
@@ -34,11 +34,11 @@
34
35 <h2>Starting A New Project</h2>
36
37 <p>To start a new project with fossil, create a new empty repository
38 this way: ([/help/init | more info]) </p>
39
40 <blockquote>
41 <b>fossil init </b><i> repository-filename</i>
42 </blockquote>
43
44 <h2>Cloning An Existing Repository</h2>
@@ -46,36 +46,36 @@
46 <p>Most fossil operations interact with a repository that is on the
47 local disk drive, not on a remote system. Hence, before accessing
48 a remote repository it is necessary to make a local copy of that
49 repository. Making a local copy of a remote repository is called
50 "cloning".</p>
51
52 <p>Clone a remote repository as follows: ([/help/clone | more info])</p>
53
54 <blockquote>
55 <b>fossil clone</b> <i>URL repository-filename</i>
56 </blockquote>
57
58 <p>The <i>URL</i> specifies the fossil repository
59 you want to clone. The <i>repository-filename</i> is the new local
60 filename into which the cloned repository will be written. For
61 example:
62
63 <blockquote>
64 <b>fossil clone http://www.fossil-scm.org/ myclone.fossil</b>
65 </blockquote>
66
67 <p>If the remote repository requires a login, include a
68 userid in the URL like this:
69
70 <blockquote>
71 <b>fossil clone http://</b><i>userid</i><b>@www.fossil-scm.org/ myclone.fossil</b>
72 </blockquote>
73
74
75 <p>You will be prompted separately for the password.
76 Use "%HH" escapes for special characters in the userid.
77 Examples: "%40" in place of "@" and "%2F" in place of "/".
78
79 <p>If you are behind a restrictive firewall, you might need
80 to <a href="#proxy">specify an HTTP proxy</a>.</p>
81
@@ -85,31 +85,31 @@
85 information above and beyond the versioned files, including some
86 sensitive information such as password hashes and email addresses. If you
87 want to share Fossil repositories directly, consider running the
88 [/help/scrub|fossil scrub] command to remove sensitive information
89 before transmitting the file.
90
91 <h2>Importing From Another Version Control System</h2>
92
93 <p>Rather than start a new project, or clone an existing Fossil project,
94 you might prefer to
95 <a href="./inout.wiki">import an existing Git project</a>
96 into Fossil using the [/help/import | fossil import] command.
97
98 <h2>Checking Out A Local Tree</h2>
99
100 <p>To work on a project in fossil, you need to check out a local
101 copy of the source tree. Create the directory you want to be
102 the root of your tree and cd into that directory. Then
103 do this: ([/help/open | more info])</p>
104
105 <blockquote>
106 <b>fossil open </b><i> repository-filename</i>
107 </blockquote>
108
109 <p>This leaves you with the newest version of the tree
110 checked out.
111 From anywhere underneath the root of your local tree, you
112 can type commands like the following to find out the status of
113 your local tree:</p>
114
115 <blockquote>
@@ -122,11 +122,11 @@
122 <b>[/help/branch | fossil branch]</b><br>
123 </blockquote>
124
125 <p>Note that Fossil allows you to make multiple check-outs in
126 separate directories from the same repository. This enables you,
127 for example, to do builds from multiple branches or versions at
128 the same time without having to generate extra clones.</p>
129
130 <p>To switch a checkout between different versions and branches,
131 use:</p>
132
@@ -140,17 +140,17 @@
140 version, whereas [/help/checkout | checkout] does not
141 automatically sync and does a "hard" switch, overwriting local
142 changes if told to do so.</p>
143
144 <h2>Configuring Your Local Repository</h2>
145
146 <p>When you create a new repository, either by cloning an existing
147 project or create a new project of your own, you usually want to do some
148 local configuration. This is easily accomplished using the web-server
149 that is built into fossil. Start the fossil webserver like this:
150 ([/help/ui | more info])</p>
151
152 <blockquote>
153 <b>fossil ui </b><i> repository-filename</i>
154 </blockquote>
155
156 <p>You can omit the <i>repository-filename</i> from the command above
@@ -163,15 +163,15 @@
163 where to find your web browser using a command like this:</p>
164
165 <blockquote>
166 <b>fossil setting web-browser </b><i> path-to-web-browser</i>
167 </blockquote>
168
169 <p>By default, fossil does not require a login for HTTP connections
170 coming in from the IP loopback address 127.0.0.1. You can, and perhaps
171 should, change this after you create a few users.</p>
172
173 <p>When you are finished configuring, just press Control-C or use
174 the <b>kill</b> command to shut down the mini-server.</p>
175
176 <h2>Making Changes</h2>
177
@@ -194,18 +194,18 @@
194 <p>You will be prompted for check-in comments using whatever editor
195 is specified by your VISUAL or EDITOR environment variable.</p>
196
197 In the default configuration, the [/help/commit|commit]
198 command will also automatically [/help/push|push] your changes, but that
199 feature can be disabled. (More information about
200 [./concepts.wiki#workflow|autosync] and how to disable it.)
201 Remember that your coworkers can not see your changes until you
202 commit and push them.</p>
203
204 <h2>Sharing Changes</h2>
205
206 <p>When [./concepts.wiki#workflow|autosync] is turned off,
207 the changes you [/help/commit | commit] are only
208 on your local repository.
209 To share those changes with other repositories, do:</p>
210
211 <blockquote>
@@ -241,11 +241,11 @@
241 the <i>VERSION</i>, then fossil moves you to the
242 latest version of the branch your are currently on.</p>
243
244 <p>The default behavior is for [./concepts.wiki#workflow|autosync] to
245 be turned on. That means that a [/help/pull|pull] automatically occurs
246 when you run [/help/update|update] and a [/help/push|push] happens
247 automatically after you [/help/commit|commit]. So in normal practice,
248 the push, pull, and sync commands are rarely used. But it is important
249 to know about them, all the same.</p>
250
251 <blockquote>
@@ -342,11 +342,11 @@
342 <li>[./server.wiki#cgi|CGI]
343 <li>[./server.wiki#scgi|SCGI]
344 </ul>
345
346 <p>The [./selfhost.wiki | self-hosting fossil repositories] use
347 CGI.
348
349 <a name="proxy"></a>
350 <h2>HTTP Proxies</h2>
351
352 <p>If you are behind a restrictive firewall that requires you to use
@@ -382,11 +382,11 @@
382 <p>Or unset the environment variable. The fossil setting for the
383 HTTP proxy takes precedence over the environment variable and the
384 command-line option overrides both. If you have an persistent
385 proxy setting that you want to override for a one-time sync, that
386 is easily done on the command-line. For example, to sync with
387 a co-workers repository on your LAN, you might type:</p>
388
389 <blockquote>
390 <b>fossil sync http://192.168.1.36:8080/ --proxy off</b>
391 </blockquote>
392
393
M www/quotes.wiki
+13 -13
--- www/quotes.wiki
+++ www/quotes.wiki
@@ -5,19 +5,19 @@
55
 by the creator of Fossil, so of course there is selection bias...
66
77
 <h2>On The Usability Of Git:</h2>
88
99
 <ol>
10
-<li>Git approaches the usability of iptables, which is to say, utterly
10
+<li>Git approaches the usability of iptables, which is to say, utterly
1111
 unusable unless you have the manpage tattooed on you arm.
1212
1313
 <blockquote>
1414
 <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i>
1515
 </blockquote>
1616
1717
 <li><nowiki>It's simplest to think of the state of your [git] repository
18
-as a point in a high-dimensional "code-space", in which branches are
18
+as a point in a high-dimensional "code-space", in which branches are
1919
 represented as n-dimensional membranes, mapping the spatial loci of
2020
 successive commits onto the projected manifold of each cloned
2121
 repository.</nowiki>
2222
2323
 <blockquote>
@@ -25,11 +25,11 @@
2525
 </blockquote>
2626
2727
 <li>Git is not a Prius. Git is a Model T.
2828
 Its plumbing and wiring sticks out all over the place.
2929
 You have to be a mechanic to operate it successfully or you'll be
30
-stuck on the side of the road when it breaks down.
30
+stuck on the side of the road when it breaks down.
3131
 And it <b>will</b> break down.
3232
3333
 <blockquote>
3434
 <i>Nick Farina at [http://nfarina.com/post/9868516270/git-is-simpler]</i>
3535
 </blockquote>
@@ -39,11 +39,11 @@
3939
 <blockquote>
4040
 <i>Linus Torvalds - 2005-04-07 22:13:13<br>
4141
 Commit comment on the very first source-code check-in for git
4242
 </blockquote>
4343
44
-<li>I've been experimenting a lot with git at work.
44
+<li>I've been experimenting a lot with git at work.
4545
 Damn, it's complicated.
4646
 It has things to trip you up with that sane people just wouldn't ever both with
4747
 including the ability to allow you to commit stuff in such a way that you can't find
4848
 it again afterwards (!!!)
4949
 Demented workflow complexity on acid?
@@ -104,19 +104,19 @@
104104
105105
 <blockquote>
106106
 <i>Joe Prostko at [http://www.mail-archive.com/[email protected]/msg16716.html]
107107
 </blockquote>
108108
109
-<li>Fossil is awesome!!! I have never seen an app like that before,
109
+<li>Fossil is awesome!!! I have never seen an app like that before,
110110
 such simplicity and flexibility!!!
111111
112112
 <blockquote>
113113
 <i>zengr at [http://stackoverflow.com/questions/138621/best-version-control-for-lone-developer]</i>
114114
 </blockquote>
115115
116116
 <li>This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own
117
-server, ticketing system, Wiki pages, and a very, very helpful timeline visualization. And
117
+server, ticketing system, Wiki pages, and a very, very helpful timeline visualization. And
118118
 the entire program in a single file!
119119
120120
 <blockquote>
121121
 <i>thunderbong commenting on hacker news: [https://news.ycombinator.com/item?id=9131619]</i>
122122
 </blockquote>
@@ -127,30 +127,30 @@
127127
128128
 <h2>On Git Versus Fossil</h2>
129129
130130
 <ol>
131131
 <li value=15>
132
-Just want to say thanks for fossil making my life easier....
132
+Just want to say thanks for fossil making my life easier....
133133
 Also <nowiki>[for]</nowiki> not having a misanthropic command line interface.
134134
135135
 <blockquote>
136136
 <i>Joshua Paine at [http://www.mail-archive.com/[email protected]/msg02736.html]</i>
137137
 </blockquote>
138138
139139
 <li>We use it at a large university to manage code that small teams write.
140
-The runs everywhere, ease of installation and portability is something that
141
-seems to be a good fit with the environment we have (highly ditrobuted,
142
-sometimes very restrictive firewalls, OSX/Win/Linux). We are happy with it
143
-and teaching a Msc/Phd student (read complete novice) fossil has just
140
+The runs everywhere, ease of installation and portability is something that
141
+seems to be a good fit with the environment we have (highly ditrobuted,
142
+sometimes very restrictive firewalls, OSX/Win/Linux). We are happy with it
143
+and teaching a Msc/Phd student (read complete novice) fossil has just
144144
 been a smoother ride than Git was.
145145
146146
 <blockquote>
147147
 <i>viablepanic at [http://www.reddit.com/r/programming/comments/bxcto/why_not_fossil_scm/]</i>
148148
 </blockquote>
149149
150
-<li>In the fossil community - and hence in fossil itself - development history
151
-is pretty much sacrosanct. The very name "fossil" was to chosen to
150
+<li>In the fossil community - and hence in fossil itself - development history
151
+is pretty much sacrosanct. The very name "fossil" was to chosen to
152152
 reflect the unchanging nature of things in that history.
153153
154154
 <p>In git (or rather, the git community), the development history is part of
155155
 the published aspect of the project, so it provides tools for rearranging
156156
 that history so you can present what you "should" have done rather
157157
--- www/quotes.wiki
+++ www/quotes.wiki
@@ -5,19 +5,19 @@
5 by the creator of Fossil, so of course there is selection bias...
6
7 <h2>On The Usability Of Git:</h2>
8
9 <ol>
10 <li>Git approaches the usability of iptables, which is to say, utterly
11 unusable unless you have the manpage tattooed on you arm.
12
13 <blockquote>
14 <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i>
15 </blockquote>
16
17 <li><nowiki>It's simplest to think of the state of your [git] repository
18 as a point in a high-dimensional "code-space", in which branches are
19 represented as n-dimensional membranes, mapping the spatial loci of
20 successive commits onto the projected manifold of each cloned
21 repository.</nowiki>
22
23 <blockquote>
@@ -25,11 +25,11 @@
25 </blockquote>
26
27 <li>Git is not a Prius. Git is a Model T.
28 Its plumbing and wiring sticks out all over the place.
29 You have to be a mechanic to operate it successfully or you'll be
30 stuck on the side of the road when it breaks down.
31 And it <b>will</b> break down.
32
33 <blockquote>
34 <i>Nick Farina at [http://nfarina.com/post/9868516270/git-is-simpler]</i>
35 </blockquote>
@@ -39,11 +39,11 @@
39 <blockquote>
40 <i>Linus Torvalds - 2005-04-07 22:13:13<br>
41 Commit comment on the very first source-code check-in for git
42 </blockquote>
43
44 <li>I've been experimenting a lot with git at work.
45 Damn, it's complicated.
46 It has things to trip you up with that sane people just wouldn't ever both with
47 including the ability to allow you to commit stuff in such a way that you can't find
48 it again afterwards (!!!)
49 Demented workflow complexity on acid?
@@ -104,19 +104,19 @@
104
105 <blockquote>
106 <i>Joe Prostko at [http://www.mail-archive.com/[email protected]/msg16716.html]
107 </blockquote>
108
109 <li>Fossil is awesome!!! I have never seen an app like that before,
110 such simplicity and flexibility!!!
111
112 <blockquote>
113 <i>zengr at [http://stackoverflow.com/questions/138621/best-version-control-for-lone-developer]</i>
114 </blockquote>
115
116 <li>This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own
117 server, ticketing system, Wiki pages, and a very, very helpful timeline visualization. And
118 the entire program in a single file!
119
120 <blockquote>
121 <i>thunderbong commenting on hacker news: [https://news.ycombinator.com/item?id=9131619]</i>
122 </blockquote>
@@ -127,30 +127,30 @@
127
128 <h2>On Git Versus Fossil</h2>
129
130 <ol>
131 <li value=15>
132 Just want to say thanks for fossil making my life easier....
133 Also <nowiki>[for]</nowiki> not having a misanthropic command line interface.
134
135 <blockquote>
136 <i>Joshua Paine at [http://www.mail-archive.com/[email protected]/msg02736.html]</i>
137 </blockquote>
138
139 <li>We use it at a large university to manage code that small teams write.
140 The runs everywhere, ease of installation and portability is something that
141 seems to be a good fit with the environment we have (highly ditrobuted,
142 sometimes very restrictive firewalls, OSX/Win/Linux). We are happy with it
143 and teaching a Msc/Phd student (read complete novice) fossil has just
144 been a smoother ride than Git was.
145
146 <blockquote>
147 <i>viablepanic at [http://www.reddit.com/r/programming/comments/bxcto/why_not_fossil_scm/]</i>
148 </blockquote>
149
150 <li>In the fossil community - and hence in fossil itself - development history
151 is pretty much sacrosanct. The very name "fossil" was to chosen to
152 reflect the unchanging nature of things in that history.
153
154 <p>In git (or rather, the git community), the development history is part of
155 the published aspect of the project, so it provides tools for rearranging
156 that history so you can present what you "should" have done rather
157
--- www/quotes.wiki
+++ www/quotes.wiki
@@ -5,19 +5,19 @@
5 by the creator of Fossil, so of course there is selection bias...
6
7 <h2>On The Usability Of Git:</h2>
8
9 <ol>
10 <li>Git approaches the usability of iptables, which is to say, utterly
11 unusable unless you have the manpage tattooed on you arm.
12
13 <blockquote>
14 <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i>
15 </blockquote>
16
17 <li><nowiki>It's simplest to think of the state of your [git] repository
18 as a point in a high-dimensional "code-space", in which branches are
19 represented as n-dimensional membranes, mapping the spatial loci of
20 successive commits onto the projected manifold of each cloned
21 repository.</nowiki>
22
23 <blockquote>
@@ -25,11 +25,11 @@
25 </blockquote>
26
27 <li>Git is not a Prius. Git is a Model T.
28 Its plumbing and wiring sticks out all over the place.
29 You have to be a mechanic to operate it successfully or you'll be
30 stuck on the side of the road when it breaks down.
31 And it <b>will</b> break down.
32
33 <blockquote>
34 <i>Nick Farina at [http://nfarina.com/post/9868516270/git-is-simpler]</i>
35 </blockquote>
@@ -39,11 +39,11 @@
39 <blockquote>
40 <i>Linus Torvalds - 2005-04-07 22:13:13<br>
41 Commit comment on the very first source-code check-in for git
42 </blockquote>
43
44 <li>I've been experimenting a lot with git at work.
45 Damn, it's complicated.
46 It has things to trip you up with that sane people just wouldn't ever both with
47 including the ability to allow you to commit stuff in such a way that you can't find
48 it again afterwards (!!!)
49 Demented workflow complexity on acid?
@@ -104,19 +104,19 @@
104
105 <blockquote>
106 <i>Joe Prostko at [http://www.mail-archive.com/[email protected]/msg16716.html]
107 </blockquote>
108
109 <li>Fossil is awesome!!! I have never seen an app like that before,
110 such simplicity and flexibility!!!
111
112 <blockquote>
113 <i>zengr at [http://stackoverflow.com/questions/138621/best-version-control-for-lone-developer]</i>
114 </blockquote>
115
116 <li>This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own
117 server, ticketing system, Wiki pages, and a very, very helpful timeline visualization. And
118 the entire program in a single file!
119
120 <blockquote>
121 <i>thunderbong commenting on hacker news: [https://news.ycombinator.com/item?id=9131619]</i>
122 </blockquote>
@@ -127,30 +127,30 @@
127
128 <h2>On Git Versus Fossil</h2>
129
130 <ol>
131 <li value=15>
132 Just want to say thanks for fossil making my life easier....
133 Also <nowiki>[for]</nowiki> not having a misanthropic command line interface.
134
135 <blockquote>
136 <i>Joshua Paine at [http://www.mail-archive.com/[email protected]/msg02736.html]</i>
137 </blockquote>
138
139 <li>We use it at a large university to manage code that small teams write.
140 The runs everywhere, ease of installation and portability is something that
141 seems to be a good fit with the environment we have (highly ditrobuted,
142 sometimes very restrictive firewalls, OSX/Win/Linux). We are happy with it
143 and teaching a Msc/Phd student (read complete novice) fossil has just
144 been a smoother ride than Git was.
145
146 <blockquote>
147 <i>viablepanic at [http://www.reddit.com/r/programming/comments/bxcto/why_not_fossil_scm/]</i>
148 </blockquote>
149
150 <li>In the fossil community - and hence in fossil itself - development history
151 is pretty much sacrosanct. The very name "fossil" was to chosen to
152 reflect the unchanging nature of things in that history.
153
154 <p>In git (or rather, the git community), the development history is part of
155 the published aspect of the project, so it provides tools for rearranging
156 that history so you can present what you "should" have done rather
157
M www/reviews.wiki
+12 -12
--- www/reviews.wiki
+++ www/reviews.wiki
@@ -1,8 +1,8 @@
11
 <title>Reviews</title>
22
 <b>External links:</b>
3
-
3
+
44
 * [http://nixtu.blogspot.com/2010/03/fossil-dvcs-on-go-first-impressions.html |
55
 Fossil DVCS on the Go - First Impressions]
66
 * [http://blog.mired.org/2011/02/fossil-sweet-spot-in-vcs-space.html |
77
 Fossil - a sweet spot in the VCS space] by Mike Meyer.
88
 * [http://blog.s11n.net/?p=72|Four reasons to take a closer look at the Fossil SCM] by Stephan Beal
@@ -22,27 +22,27 @@
2222
2323
2424
 <b>Joshua Paine on 2010-10-22:</b>
2525
2626
 <blockquote>
27
-With one of my several hats on, I'm in a small team using git. Another
28
-team member just checked some stuff into trunk that should have been on
29
-a branch. Nothing else had happened since, so in fossil I would have
30
-just edited that commit and put it on a new branch. In git that can't
31
-actually be done without danger once other people have pulled, so I had
32
-to create a new commit rolling back the changes, then branch and cherry
33
-pick the earlier changes, then figure out how to make my new branch
34
-shared instead of private. Just want to say thanks for fossil making my
35
-life easier on most of my projects, and being able to move commits to
36
-another branch after the fact and shared-by-default branches are good
27
+With one of my several hats on, I'm in a small team using git. Another
28
+team member just checked some stuff into trunk that should have been on
29
+a branch. Nothing else had happened since, so in fossil I would have
30
+just edited that commit and put it on a new branch. In git that can't
31
+actually be done without danger once other people have pulled, so I had
32
+to create a new commit rolling back the changes, then branch and cherry
33
+pick the earlier changes, then figure out how to make my new branch
34
+shared instead of private. Just want to say thanks for fossil making my
35
+life easier on most of my projects, and being able to move commits to
36
+another branch after the fact and shared-by-default branches are good
3737
 features. Also not having a misanthropic command line interface.
3838
 </blockquote>
3939
4040
 <b>Stephan Beal writes on 2009-01-11:</b>
4141
4242
 <blockquote>
43
-Sometime in late 2007 I came across a link to fossil on
43
+Sometime in late 2007 I came across a link to fossil on
4444
 <a href="http://www.sqlite.org/">sqlite.org</a>. It
4545
 was a good thing I bookmarked it, because I was never able to find the
4646
 link again (it might have been in a bug report or something). The
4747
 reasons I first took a close look at it were (A) it stemmed from the
4848
 sqlite project, which I've held in high regards for years (e.g. I
4949
--- www/reviews.wiki
+++ www/reviews.wiki
@@ -1,8 +1,8 @@
1 <title>Reviews</title>
2 <b>External links:</b>
3
4 * [http://nixtu.blogspot.com/2010/03/fossil-dvcs-on-go-first-impressions.html |
5 Fossil DVCS on the Go - First Impressions]
6 * [http://blog.mired.org/2011/02/fossil-sweet-spot-in-vcs-space.html |
7 Fossil - a sweet spot in the VCS space] by Mike Meyer.
8 * [http://blog.s11n.net/?p=72|Four reasons to take a closer look at the Fossil SCM] by Stephan Beal
@@ -22,27 +22,27 @@
22
23
24 <b>Joshua Paine on 2010-10-22:</b>
25
26 <blockquote>
27 With one of my several hats on, I'm in a small team using git. Another
28 team member just checked some stuff into trunk that should have been on
29 a branch. Nothing else had happened since, so in fossil I would have
30 just edited that commit and put it on a new branch. In git that can't
31 actually be done without danger once other people have pulled, so I had
32 to create a new commit rolling back the changes, then branch and cherry
33 pick the earlier changes, then figure out how to make my new branch
34 shared instead of private. Just want to say thanks for fossil making my
35 life easier on most of my projects, and being able to move commits to
36 another branch after the fact and shared-by-default branches are good
37 features. Also not having a misanthropic command line interface.
38 </blockquote>
39
40 <b>Stephan Beal writes on 2009-01-11:</b>
41
42 <blockquote>
43 Sometime in late 2007 I came across a link to fossil on
44 <a href="http://www.sqlite.org/">sqlite.org</a>. It
45 was a good thing I bookmarked it, because I was never able to find the
46 link again (it might have been in a bug report or something). The
47 reasons I first took a close look at it were (A) it stemmed from the
48 sqlite project, which I've held in high regards for years (e.g. I
49
--- www/reviews.wiki
+++ www/reviews.wiki
@@ -1,8 +1,8 @@
1 <title>Reviews</title>
2 <b>External links:</b>
3
4 * [http://nixtu.blogspot.com/2010/03/fossil-dvcs-on-go-first-impressions.html |
5 Fossil DVCS on the Go - First Impressions]
6 * [http://blog.mired.org/2011/02/fossil-sweet-spot-in-vcs-space.html |
7 Fossil - a sweet spot in the VCS space] by Mike Meyer.
8 * [http://blog.s11n.net/?p=72|Four reasons to take a closer look at the Fossil SCM] by Stephan Beal
@@ -22,27 +22,27 @@
22
23
24 <b>Joshua Paine on 2010-10-22:</b>
25
26 <blockquote>
27 With one of my several hats on, I'm in a small team using git. Another
28 team member just checked some stuff into trunk that should have been on
29 a branch. Nothing else had happened since, so in fossil I would have
30 just edited that commit and put it on a new branch. In git that can't
31 actually be done without danger once other people have pulled, so I had
32 to create a new commit rolling back the changes, then branch and cherry
33 pick the earlier changes, then figure out how to make my new branch
34 shared instead of private. Just want to say thanks for fossil making my
35 life easier on most of my projects, and being able to move commits to
36 another branch after the fact and shared-by-default branches are good
37 features. Also not having a misanthropic command line interface.
38 </blockquote>
39
40 <b>Stephan Beal writes on 2009-01-11:</b>
41
42 <blockquote>
43 Sometime in late 2007 I came across a link to fossil on
44 <a href="http://www.sqlite.org/">sqlite.org</a>. It
45 was a good thing I bookmarked it, because I was never able to find the
46 link again (it might have been in a bug report or something). The
47 reasons I first took a close look at it were (A) it stemmed from the
48 sqlite project, which I've held in high regards for years (e.g. I
49
M www/selfcheck.wiki
+3 -3
--- www/selfcheck.wiki
+++ www/selfcheck.wiki
@@ -14,11 +14,11 @@
1414
 lost. The integrity checks are doing their job well.</p>
1515
1616
 <h2>Atomic Check-ins With Rollback</h2>
1717
1818
 The fossil repository is stored in an
19
-<a href="http://www.sqlite.org/">SQLite</a> database file.
19
+<a href="http://www.sqlite.org/">SQLite</a> database file.
2020
 ([./tech_overview.wiki | Addition information] about the repository
2121
 file format.)
2222
 SQLite is very mature and stable and has been in wide-spread use for many
2323
 years, so we are confident it will not cause repository
2424
 corruption. SQLite
@@ -61,11 +61,11 @@
6161
 message is printed and the transaction rolls back.
6262
6363
 So, in other words, fossil always checks to make sure it can
6464
 re-extract a file before it commits a change to that file.
6565
 Hence bugs in fossil are unlikely to corrupt the repository in
66
-a way that prevents us from extracting historical versions of
66
+a way that prevents us from extracting historical versions of
6767
 files.
6868
6969
 <h2>Checksum Over All Files In A Check-in</h2>
7070
7171
 Manifest artifacts that define a check-in have two fields (the
@@ -102,7 +102,7 @@
102102
 <a href="http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare">tortoise</a>:
103103
 reliability is more important than raw speed. The developers of
104104
 fossil see no merit in getting the wrong answer quickly.
105105
106106
 Fossil may not be the fastest versioning system, but it is "fast enough".
107
-Fossil runs quickly enough to stay out of the developers way.
107
+Fossil runs quickly enough to stay out of the developers way.
108108
 Most operations complete in under a second.
109109
--- www/selfcheck.wiki
+++ www/selfcheck.wiki
@@ -14,11 +14,11 @@
14 lost. The integrity checks are doing their job well.</p>
15
16 <h2>Atomic Check-ins With Rollback</h2>
17
18 The fossil repository is stored in an
19 <a href="http://www.sqlite.org/">SQLite</a> database file.
20 ([./tech_overview.wiki | Addition information] about the repository
21 file format.)
22 SQLite is very mature and stable and has been in wide-spread use for many
23 years, so we are confident it will not cause repository
24 corruption. SQLite
@@ -61,11 +61,11 @@
61 message is printed and the transaction rolls back.
62
63 So, in other words, fossil always checks to make sure it can
64 re-extract a file before it commits a change to that file.
65 Hence bugs in fossil are unlikely to corrupt the repository in
66 a way that prevents us from extracting historical versions of
67 files.
68
69 <h2>Checksum Over All Files In A Check-in</h2>
70
71 Manifest artifacts that define a check-in have two fields (the
@@ -102,7 +102,7 @@
102 <a href="http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare">tortoise</a>:
103 reliability is more important than raw speed. The developers of
104 fossil see no merit in getting the wrong answer quickly.
105
106 Fossil may not be the fastest versioning system, but it is "fast enough".
107 Fossil runs quickly enough to stay out of the developers way.
108 Most operations complete in under a second.
109
--- www/selfcheck.wiki
+++ www/selfcheck.wiki
@@ -14,11 +14,11 @@
14 lost. The integrity checks are doing their job well.</p>
15
16 <h2>Atomic Check-ins With Rollback</h2>
17
18 The fossil repository is stored in an
19 <a href="http://www.sqlite.org/">SQLite</a> database file.
20 ([./tech_overview.wiki | Addition information] about the repository
21 file format.)
22 SQLite is very mature and stable and has been in wide-spread use for many
23 years, so we are confident it will not cause repository
24 corruption. SQLite
@@ -61,11 +61,11 @@
61 message is printed and the transaction rolls back.
62
63 So, in other words, fossil always checks to make sure it can
64 re-extract a file before it commits a change to that file.
65 Hence bugs in fossil are unlikely to corrupt the repository in
66 a way that prevents us from extracting historical versions of
67 files.
68
69 <h2>Checksum Over All Files In A Check-in</h2>
70
71 Manifest artifacts that define a check-in have two fields (the
@@ -102,7 +102,7 @@
102 <a href="http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare">tortoise</a>:
103 reliability is more important than raw speed. The developers of
104 fossil see no merit in getting the wrong answer quickly.
105
106 Fossil may not be the fastest versioning system, but it is "fast enough".
107 Fossil runs quickly enough to stay out of the developers way.
108 Most operations complete in under a second.
109
M www/selfhost.wiki
+6 -6
--- www/selfhost.wiki
+++ www/selfhost.wiki
@@ -7,23 +7,23 @@
77
 2. [http://www2.fossil-scm.org/]
88
 3. [http://www3.fossil-scm.org/site.cgi]
99
1010
1111
 The canonical repository is (1). Repositories (2) and (3) automatically
12
-stay in synchronization with (1) via a
12
+stay in synchronization with (1) via a
1313
 <a href="http://en.wikipedia.org/wiki/Cron">cron job</a> that invokes
1414
 "fossil sync" at regular intervals.
1515
1616
 Note that the two secondary repositories are more than just read-only mirrors.
1717
 All three servers support full read/write capabilities.
18
-Changes (such as new tickets or wiki or check-ins) can be implemented
18
+Changes (such as new tickets or wiki or check-ins) can be implemented
1919
 on any of the three servers and those changes automatically propagate to the
2020
 other two servers.
2121
2222
 Server (1) runs as a CGI script on a
2323
 <a href="http://www.linode.com/">Linode 1024</a> located in Dallas, TX
24
-- on the same virtual machine that
24
+- on the same virtual machine that
2525
 hosts <a href="http://www.sqlite.org/">SQLite</a> and over a
2626
 dozen other smaller projects. This demonstrates that Fossil can run on
2727
 a low-power host processor.
2828
 Multiple fossil-based projects can easily be hosted on the same machine,
2929
 even if that machine is itself one of several dozen virtual machines on
@@ -34,17 +34,17 @@
3434
 #!/usr/bin/fossil
3535
 repository: /fossil/fossil.fossil
3636
 </pre></blockquote>
3737
3838
 Server (3) runs as a CGI script on a shared hosting account at
39
-<a href="http://www.he.net/">Hurricane Electric</a> in Fremont, CA.
39
+<a href="http://www.he.net/">Hurricane Electric</a> in Fremont, CA.
4040
 This server demonstrates the ability of
4141
 Fossil to run on an economical shared-host web account with no
4242
 privileges beyond port 80 HTTP access and CGI. It is not necessary
4343
 to have a dedicated computer with administrator privileges to run Fossil.
44
-As far as we are aware,
45
-Fossil is the only full-featured configuration management system
44
+As far as we are aware,
45
+Fossil is the only full-featured configuration management system
4646
 that can run in
4747
 such a restricted environment. The CGI script that runs on the
4848
 Hurricane Electric server is the same as the CGI script shown above,
4949
 except that the pathnames are modified to suit the environment:
5050
5151
--- www/selfhost.wiki
+++ www/selfhost.wiki
@@ -7,23 +7,23 @@
7 2. [http://www2.fossil-scm.org/]
8 3. [http://www3.fossil-scm.org/site.cgi]
9
10
11 The canonical repository is (1). Repositories (2) and (3) automatically
12 stay in synchronization with (1) via a
13 <a href="http://en.wikipedia.org/wiki/Cron">cron job</a> that invokes
14 "fossil sync" at regular intervals.
15
16 Note that the two secondary repositories are more than just read-only mirrors.
17 All three servers support full read/write capabilities.
18 Changes (such as new tickets or wiki or check-ins) can be implemented
19 on any of the three servers and those changes automatically propagate to the
20 other two servers.
21
22 Server (1) runs as a CGI script on a
23 <a href="http://www.linode.com/">Linode 1024</a> located in Dallas, TX
24 - on the same virtual machine that
25 hosts <a href="http://www.sqlite.org/">SQLite</a> and over a
26 dozen other smaller projects. This demonstrates that Fossil can run on
27 a low-power host processor.
28 Multiple fossil-based projects can easily be hosted on the same machine,
29 even if that machine is itself one of several dozen virtual machines on
@@ -34,17 +34,17 @@
34 #!/usr/bin/fossil
35 repository: /fossil/fossil.fossil
36 </pre></blockquote>
37
38 Server (3) runs as a CGI script on a shared hosting account at
39 <a href="http://www.he.net/">Hurricane Electric</a> in Fremont, CA.
40 This server demonstrates the ability of
41 Fossil to run on an economical shared-host web account with no
42 privileges beyond port 80 HTTP access and CGI. It is not necessary
43 to have a dedicated computer with administrator privileges to run Fossil.
44 As far as we are aware,
45 Fossil is the only full-featured configuration management system
46 that can run in
47 such a restricted environment. The CGI script that runs on the
48 Hurricane Electric server is the same as the CGI script shown above,
49 except that the pathnames are modified to suit the environment:
50
51
--- www/selfhost.wiki
+++ www/selfhost.wiki
@@ -7,23 +7,23 @@
7 2. [http://www2.fossil-scm.org/]
8 3. [http://www3.fossil-scm.org/site.cgi]
9
10
11 The canonical repository is (1). Repositories (2) and (3) automatically
12 stay in synchronization with (1) via a
13 <a href="http://en.wikipedia.org/wiki/Cron">cron job</a> that invokes
14 "fossil sync" at regular intervals.
15
16 Note that the two secondary repositories are more than just read-only mirrors.
17 All three servers support full read/write capabilities.
18 Changes (such as new tickets or wiki or check-ins) can be implemented
19 on any of the three servers and those changes automatically propagate to the
20 other two servers.
21
22 Server (1) runs as a CGI script on a
23 <a href="http://www.linode.com/">Linode 1024</a> located in Dallas, TX
24 - on the same virtual machine that
25 hosts <a href="http://www.sqlite.org/">SQLite</a> and over a
26 dozen other smaller projects. This demonstrates that Fossil can run on
27 a low-power host processor.
28 Multiple fossil-based projects can easily be hosted on the same machine,
29 even if that machine is itself one of several dozen virtual machines on
@@ -34,17 +34,17 @@
34 #!/usr/bin/fossil
35 repository: /fossil/fossil.fossil
36 </pre></blockquote>
37
38 Server (3) runs as a CGI script on a shared hosting account at
39 <a href="http://www.he.net/">Hurricane Electric</a> in Fremont, CA.
40 This server demonstrates the ability of
41 Fossil to run on an economical shared-host web account with no
42 privileges beyond port 80 HTTP access and CGI. It is not necessary
43 to have a dedicated computer with administrator privileges to run Fossil.
44 As far as we are aware,
45 Fossil is the only full-featured configuration management system
46 that can run in
47 such a restricted environment. The CGI script that runs on the
48 Hurricane Electric server is the same as the CGI script shown above,
49 except that the pathnames are modified to suit the environment:
50
51
M www/server.wiki
+20 -20
--- www/server.wiki
+++ www/server.wiki
@@ -2,11 +2,11 @@
22
 <h2>Introduction</h2><blockquote>
33
 <p>A server is not necessary to use Fossil, but a server does help in collaborating with
44
 peers. A Fossil server also works well as a complete website for a project.
55
 For example, the complete [https://www.fossil-scm.org/] website, including the
66
 page you are now reading,
7
-is just a Fossil server displaying the content of the
7
+is just a Fossil server displaying the content of the
88
 self-hosting repository for Fossil.</p>
99
 <p>This article is a guide for setting up your own Fossil server.
1010
 <p>See "[./aboutcgi.wiki|How CGI Works In Fossil]" for background
1111
 information on the underlying CGI technology.
1212
 See "[./sync.wiki|The Fossil Sync Protocol]" for information on the
@@ -18,11 +18,11 @@
1818
 <li>A stand-alone server
1919
 <li>Using inetd or xinetd or stunnel
2020
 <li>CGI
2121
 <li>SCGI (a.k.a. SimpleCGI)
2222
 </ol>
23
-Each of these can serve either a single repository, or a directory hierarchy
23
+Each of these can serve either a single repository, or a directory hierarchy
2424
 containing many repositories with names ending in ".fossil".
2525
 </blockquote>
2626
 <a name="standalone"></a>
2727
 <h2>Standalone server</h2><blockquote>
2828
 The easiest way to set up a Fossil server is to use either the
@@ -34,11 +34,11 @@
3434
 <p>
3535
 The <i>REPOSITORY</i> argument is either the name of the repository file, or
3636
 a directory containing many repositories.
3737
 Both of these commands start a Fossil server, usually on TCP port 8080, though
3838
 a higher numbered port might also be used if 8080 is already occupied. You can
39
-access these using URLs of the form <b>http://localhost:8080/</b>, or if
39
+access these using URLs of the form <b>http://localhost:8080/</b>, or if
4040
 <i>REPOSITORY</i> is a directory, URLs of the form
4141
 <b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is the base
4242
 name of the repository file without the ".fossil" suffix.
4343
 The difference between "ui" and "server" is that "ui" will
4444
 also start a web browser and point it
@@ -75,23 +75,23 @@
7575
 need to modify the pathnames for your particular setup.
7676
 The final argument is either the name of the fossil repository to be served,
7777
 or a directory containing multiple repositories.
7878
 </p>
7979
 <p>
80
-If you use a non-standard TCP port on
81
-systems where the port-specification must be a symbolic name and cannot be
80
+If you use a non-standard TCP port on
81
+systems where the port-specification must be a symbolic name and cannot be
8282
 numeric, add the desired name and port to /etc/services. For example, if
8383
 you want your Fossil server running on TCP port 12345 instead of 80, you
8484
 will need to add:
8585
 <blockquote>
8686
 <pre>
8787
 fossil 12345/tcp #fossil server
8888
 </pre>
8989
 </blockquote>
90
-and use the symbolic name ('fossil' in this example) instead of the numeral ('12345')
91
-in inetd.conf. For details, see the relevant section in your system's documentation, e.g.
92
-the [https://www.freebsd.org/doc/en/books/handbook/network-inetd.html|FreeBSD Handbook] in
90
+and use the symbolic name ('fossil' in this example) instead of the numeral ('12345')
91
+in inetd.conf. For details, see the relevant section in your system's documentation, e.g.
92
+the [https://www.freebsd.org/doc/en/books/handbook/network-inetd.html|FreeBSD Handbook] in
9393
 case you use FreeBSD.
9494
 </p>
9595
 <p>
9696
 If your system is running xinetd, then the configuration is likely to be
9797
 in the file "/etc/xinetd.conf" or in a subfile of "/etc/xinetd.d".
@@ -119,11 +119,11 @@
119119
 jail for the user who owns the fossil repository before reading any information
120120
 off of the wire.
121121
 </p>
122122
 <p>
123123
 Inetd or xinetd must be enabled, and must be (re)started whenever their configuration
124
-changes - consult your system's documentation for details.
124
+changes - consult your system's documentation for details.
125125
 </p>
126126
 <p>
127127
 [https://www.stunnel.org/ | Stunnel version 5] is an inetd-like process that
128128
 accepts and decodes SSL-encrypted connections. Fossil can be run directly from
129129
 stunnel in a manner similar to inetd and xinetd. This can be used to provide
@@ -137,15 +137,15 @@
137137
 TIMEOUTclose = 0
138138
 exec = /usr/bin/fossil
139139
 execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https
140140
 </nowiki></pre></blockquote>
141141
 See the stunnel5 documentation for further details about the /etc/stunnel/stunnel.conf
142
-configuration file. Note that the [/help/http|fossil http] command should include
142
+configuration file. Note that the [/help/http|fossil http] command should include
143143
 the --https option to let Fossil know to use "https" instead of "http" as the scheme
144144
 on generated hyperlinks.
145145
 <p>
146
-Using inetd or xinetd or stunnel is a more complex setup
146
+Using inetd or xinetd or stunnel is a more complex setup
147147
 than the "standalone" server, but it has the
148148
 advantage of only using system resources when an actual connection is
149149
 attempted. If no-one ever connects to that port, a Fossil server will
150150
 not (automatically) run. It has the disadvantage of requiring "root" access
151151
 and therefore may not normally be available to lower-priced "shared" servers
@@ -155,11 +155,11 @@
155155
 <a name="cgi"></a>
156156
 <h2>Fossil as CGI</h2><blockquote>
157157
 <p>
158158
 A Fossil server can also be run from an ordinary web server as a CGI program.
159159
 This feature allows Fossil to be seamlessly integrated into a larger website.
160
-CGI is how the [./selfhost.wiki | self-hosting fossil repositories] are
160
+CGI is how the [./selfhost.wiki | self-hosting fossil repositories] are
161161
 implemented.
162162
 </p>
163163
 <p>
164164
 To run Fossil as CGI, create a CGI script (here called "repo") in the CGI directory
165165
 of your web server and having content like this:
@@ -184,12 +184,12 @@
184184
 script itself must be executable for the user under which it will run (which often differs
185185
 from the one running the web server - consult your site's documentation or administrator).</li>
186186
 <li>The repository file AND the directory containing it must be writable by the same account
187187
 which executes the Fossil binary (again, this might differ from the WWW user). The directory
188188
 needs to be writable so that sqlite can write its journal files.</li>
189
-<li>Fossil must be able to create temporary files, the default directory
190
-for which depends on the OS. When the CGI process is operating within
189
+<li>Fossil must be able to create temporary files, the default directory
190
+for which depends on the OS. When the CGI process is operating within
191191
 a chroot, ensure that this directory exists and is readable/writeable
192192
 by the user who executes the Fossil binary.</li>
193193
 </ul>
194194
 </p>
195195
@@ -219,11 +219,11 @@
219219
220220
 <a name="scgi"></a>
221221
 <h2>Fossil as SCGI</h2><blockquote>
222222
223223
 <p>
224
-The [/help/server|fossil server] command, described above as a way of
224
+The [/help/server|fossil server] command, described above as a way of
225225
 starting a stand-alone web server, can also be used for SCGI. Simply add
226226
 the --scgi command-line option and the stand-alone server will interpret
227227
 and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can
228228
 be used in combination with a webserver (such as [http://nginx.org|Nginx])
229229
 that does not support CGI. A typical Nginx configuration to support SCGI
@@ -284,27 +284,27 @@
284284
 </blockquote>
285285
286286
 <a name="loadmgmt"></a>
287287
 <h2>Managing Server Load</h2><blockquote>
288288
 <p>
289
-A Fossil server is very efficient and normally presents a very light
289
+A Fossil server is very efficient and normally presents a very light
290290
 load on the server.
291291
 The Fossil [./selfhost.wiki | self-hosting server] is a 1/24th slice VM at
292292
 [http://www.linode.com | Linode.com] hosting 65 other repositories in
293293
 addition to Fossil (and including some very high-traffic sites such
294294
 as [http://www.sqlite.org] and [http://system.data.sqlite.org]) and
295295
 it has a typical load of 0.05 to 0.1. A single HTTP request to Fossil
296296
 normally takes less than 10 milliseconds of CPU time to complete. So
297
-requests can be arriving at a continuous rate of 20 or more per second
297
+requests can be arriving at a continuous rate of 20 or more per second
298298
 and the CPU can still be mostly idle.
299299
 <p>
300
-However, there are some Fossil web pages that can consume large
300
+However, there are some Fossil web pages that can consume large
301301
 amounts of CPU time, especially on repositories with a large number
302302
 of files or with long revision histories. High CPU usage pages include
303303
 [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball],
304304
 [/help?cmd=/annotate | /annotate] and others. On very large repositories,
305
-these commands can take 15 seconds or more of CPU time.
305
+these commands can take 15 seconds or more of CPU time.
306306
 If these kinds of requests arrive too quickly, the load average on the
307307
 server can grow dramatically, making the server unresponsive.
308308
 <p>
309309
 Fossil provides two capabilities to help avoid server overload problems
310310
 due to excessive requests to expensive pages:
@@ -312,11 +312,11 @@
312312
 <li><p>An optional cache is available that remembers the 10 most recently
313313
 requested /zip or /tarball pages and returns the precomputed answer
314314
 if the same page is requested again.
315315
 <li><p>Page requests can be configured to fail with a
316316
 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.3 | "503 Server Overload"]
317
- HTTP error if an expensive request is received while the host load
317
+ HTTP error if an expensive request is received while the host load
318318
 average is too high.
319319
 </ol>
320320
 Both of these load-control mechanisms are turned off by default, but they
321321
 are recommended for high-traffic sites.
322322
 <p>
323323
--- www/server.wiki
+++ www/server.wiki
@@ -2,11 +2,11 @@
2 <h2>Introduction</h2><blockquote>
3 <p>A server is not necessary to use Fossil, but a server does help in collaborating with
4 peers. A Fossil server also works well as a complete website for a project.
5 For example, the complete [https://www.fossil-scm.org/] website, including the
6 page you are now reading,
7 is just a Fossil server displaying the content of the
8 self-hosting repository for Fossil.</p>
9 <p>This article is a guide for setting up your own Fossil server.
10 <p>See "[./aboutcgi.wiki|How CGI Works In Fossil]" for background
11 information on the underlying CGI technology.
12 See "[./sync.wiki|The Fossil Sync Protocol]" for information on the
@@ -18,11 +18,11 @@
18 <li>A stand-alone server
19 <li>Using inetd or xinetd or stunnel
20 <li>CGI
21 <li>SCGI (a.k.a. SimpleCGI)
22 </ol>
23 Each of these can serve either a single repository, or a directory hierarchy
24 containing many repositories with names ending in ".fossil".
25 </blockquote>
26 <a name="standalone"></a>
27 <h2>Standalone server</h2><blockquote>
28 The easiest way to set up a Fossil server is to use either the
@@ -34,11 +34,11 @@
34 <p>
35 The <i>REPOSITORY</i> argument is either the name of the repository file, or
36 a directory containing many repositories.
37 Both of these commands start a Fossil server, usually on TCP port 8080, though
38 a higher numbered port might also be used if 8080 is already occupied. You can
39 access these using URLs of the form <b>http://localhost:8080/</b>, or if
40 <i>REPOSITORY</i> is a directory, URLs of the form
41 <b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is the base
42 name of the repository file without the ".fossil" suffix.
43 The difference between "ui" and "server" is that "ui" will
44 also start a web browser and point it
@@ -75,23 +75,23 @@
75 need to modify the pathnames for your particular setup.
76 The final argument is either the name of the fossil repository to be served,
77 or a directory containing multiple repositories.
78 </p>
79 <p>
80 If you use a non-standard TCP port on
81 systems where the port-specification must be a symbolic name and cannot be
82 numeric, add the desired name and port to /etc/services. For example, if
83 you want your Fossil server running on TCP port 12345 instead of 80, you
84 will need to add:
85 <blockquote>
86 <pre>
87 fossil 12345/tcp #fossil server
88 </pre>
89 </blockquote>
90 and use the symbolic name ('fossil' in this example) instead of the numeral ('12345')
91 in inetd.conf. For details, see the relevant section in your system's documentation, e.g.
92 the [https://www.freebsd.org/doc/en/books/handbook/network-inetd.html|FreeBSD Handbook] in
93 case you use FreeBSD.
94 </p>
95 <p>
96 If your system is running xinetd, then the configuration is likely to be
97 in the file "/etc/xinetd.conf" or in a subfile of "/etc/xinetd.d".
@@ -119,11 +119,11 @@
119 jail for the user who owns the fossil repository before reading any information
120 off of the wire.
121 </p>
122 <p>
123 Inetd or xinetd must be enabled, and must be (re)started whenever their configuration
124 changes - consult your system's documentation for details.
125 </p>
126 <p>
127 [https://www.stunnel.org/ | Stunnel version 5] is an inetd-like process that
128 accepts and decodes SSL-encrypted connections. Fossil can be run directly from
129 stunnel in a manner similar to inetd and xinetd. This can be used to provide
@@ -137,15 +137,15 @@
137 TIMEOUTclose = 0
138 exec = /usr/bin/fossil
139 execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https
140 </nowiki></pre></blockquote>
141 See the stunnel5 documentation for further details about the /etc/stunnel/stunnel.conf
142 configuration file. Note that the [/help/http|fossil http] command should include
143 the --https option to let Fossil know to use "https" instead of "http" as the scheme
144 on generated hyperlinks.
145 <p>
146 Using inetd or xinetd or stunnel is a more complex setup
147 than the "standalone" server, but it has the
148 advantage of only using system resources when an actual connection is
149 attempted. If no-one ever connects to that port, a Fossil server will
150 not (automatically) run. It has the disadvantage of requiring "root" access
151 and therefore may not normally be available to lower-priced "shared" servers
@@ -155,11 +155,11 @@
155 <a name="cgi"></a>
156 <h2>Fossil as CGI</h2><blockquote>
157 <p>
158 A Fossil server can also be run from an ordinary web server as a CGI program.
159 This feature allows Fossil to be seamlessly integrated into a larger website.
160 CGI is how the [./selfhost.wiki | self-hosting fossil repositories] are
161 implemented.
162 </p>
163 <p>
164 To run Fossil as CGI, create a CGI script (here called "repo") in the CGI directory
165 of your web server and having content like this:
@@ -184,12 +184,12 @@
184 script itself must be executable for the user under which it will run (which often differs
185 from the one running the web server - consult your site's documentation or administrator).</li>
186 <li>The repository file AND the directory containing it must be writable by the same account
187 which executes the Fossil binary (again, this might differ from the WWW user). The directory
188 needs to be writable so that sqlite can write its journal files.</li>
189 <li>Fossil must be able to create temporary files, the default directory
190 for which depends on the OS. When the CGI process is operating within
191 a chroot, ensure that this directory exists and is readable/writeable
192 by the user who executes the Fossil binary.</li>
193 </ul>
194 </p>
195
@@ -219,11 +219,11 @@
219
220 <a name="scgi"></a>
221 <h2>Fossil as SCGI</h2><blockquote>
222
223 <p>
224 The [/help/server|fossil server] command, described above as a way of
225 starting a stand-alone web server, can also be used for SCGI. Simply add
226 the --scgi command-line option and the stand-alone server will interpret
227 and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can
228 be used in combination with a webserver (such as [http://nginx.org|Nginx])
229 that does not support CGI. A typical Nginx configuration to support SCGI
@@ -284,27 +284,27 @@
284 </blockquote>
285
286 <a name="loadmgmt"></a>
287 <h2>Managing Server Load</h2><blockquote>
288 <p>
289 A Fossil server is very efficient and normally presents a very light
290 load on the server.
291 The Fossil [./selfhost.wiki | self-hosting server] is a 1/24th slice VM at
292 [http://www.linode.com | Linode.com] hosting 65 other repositories in
293 addition to Fossil (and including some very high-traffic sites such
294 as [http://www.sqlite.org] and [http://system.data.sqlite.org]) and
295 it has a typical load of 0.05 to 0.1. A single HTTP request to Fossil
296 normally takes less than 10 milliseconds of CPU time to complete. So
297 requests can be arriving at a continuous rate of 20 or more per second
298 and the CPU can still be mostly idle.
299 <p>
300 However, there are some Fossil web pages that can consume large
301 amounts of CPU time, especially on repositories with a large number
302 of files or with long revision histories. High CPU usage pages include
303 [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball],
304 [/help?cmd=/annotate | /annotate] and others. On very large repositories,
305 these commands can take 15 seconds or more of CPU time.
306 If these kinds of requests arrive too quickly, the load average on the
307 server can grow dramatically, making the server unresponsive.
308 <p>
309 Fossil provides two capabilities to help avoid server overload problems
310 due to excessive requests to expensive pages:
@@ -312,11 +312,11 @@
312 <li><p>An optional cache is available that remembers the 10 most recently
313 requested /zip or /tarball pages and returns the precomputed answer
314 if the same page is requested again.
315 <li><p>Page requests can be configured to fail with a
316 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.3 | "503 Server Overload"]
317 HTTP error if an expensive request is received while the host load
318 average is too high.
319 </ol>
320 Both of these load-control mechanisms are turned off by default, but they
321 are recommended for high-traffic sites.
322 <p>
323
--- www/server.wiki
+++ www/server.wiki
@@ -2,11 +2,11 @@
2 <h2>Introduction</h2><blockquote>
3 <p>A server is not necessary to use Fossil, but a server does help in collaborating with
4 peers. A Fossil server also works well as a complete website for a project.
5 For example, the complete [https://www.fossil-scm.org/] website, including the
6 page you are now reading,
7 is just a Fossil server displaying the content of the
8 self-hosting repository for Fossil.</p>
9 <p>This article is a guide for setting up your own Fossil server.
10 <p>See "[./aboutcgi.wiki|How CGI Works In Fossil]" for background
11 information on the underlying CGI technology.
12 See "[./sync.wiki|The Fossil Sync Protocol]" for information on the
@@ -18,11 +18,11 @@
18 <li>A stand-alone server
19 <li>Using inetd or xinetd or stunnel
20 <li>CGI
21 <li>SCGI (a.k.a. SimpleCGI)
22 </ol>
23 Each of these can serve either a single repository, or a directory hierarchy
24 containing many repositories with names ending in ".fossil".
25 </blockquote>
26 <a name="standalone"></a>
27 <h2>Standalone server</h2><blockquote>
28 The easiest way to set up a Fossil server is to use either the
@@ -34,11 +34,11 @@
34 <p>
35 The <i>REPOSITORY</i> argument is either the name of the repository file, or
36 a directory containing many repositories.
37 Both of these commands start a Fossil server, usually on TCP port 8080, though
38 a higher numbered port might also be used if 8080 is already occupied. You can
39 access these using URLs of the form <b>http://localhost:8080/</b>, or if
40 <i>REPOSITORY</i> is a directory, URLs of the form
41 <b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is the base
42 name of the repository file without the ".fossil" suffix.
43 The difference between "ui" and "server" is that "ui" will
44 also start a web browser and point it
@@ -75,23 +75,23 @@
75 need to modify the pathnames for your particular setup.
76 The final argument is either the name of the fossil repository to be served,
77 or a directory containing multiple repositories.
78 </p>
79 <p>
80 If you use a non-standard TCP port on
81 systems where the port-specification must be a symbolic name and cannot be
82 numeric, add the desired name and port to /etc/services. For example, if
83 you want your Fossil server running on TCP port 12345 instead of 80, you
84 will need to add:
85 <blockquote>
86 <pre>
87 fossil 12345/tcp #fossil server
88 </pre>
89 </blockquote>
90 and use the symbolic name ('fossil' in this example) instead of the numeral ('12345')
91 in inetd.conf. For details, see the relevant section in your system's documentation, e.g.
92 the [https://www.freebsd.org/doc/en/books/handbook/network-inetd.html|FreeBSD Handbook] in
93 case you use FreeBSD.
94 </p>
95 <p>
96 If your system is running xinetd, then the configuration is likely to be
97 in the file "/etc/xinetd.conf" or in a subfile of "/etc/xinetd.d".
@@ -119,11 +119,11 @@
119 jail for the user who owns the fossil repository before reading any information
120 off of the wire.
121 </p>
122 <p>
123 Inetd or xinetd must be enabled, and must be (re)started whenever their configuration
124 changes - consult your system's documentation for details.
125 </p>
126 <p>
127 [https://www.stunnel.org/ | Stunnel version 5] is an inetd-like process that
128 accepts and decodes SSL-encrypted connections. Fossil can be run directly from
129 stunnel in a manner similar to inetd and xinetd. This can be used to provide
@@ -137,15 +137,15 @@
137 TIMEOUTclose = 0
138 exec = /usr/bin/fossil
139 execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https
140 </nowiki></pre></blockquote>
141 See the stunnel5 documentation for further details about the /etc/stunnel/stunnel.conf
142 configuration file. Note that the [/help/http|fossil http] command should include
143 the --https option to let Fossil know to use "https" instead of "http" as the scheme
144 on generated hyperlinks.
145 <p>
146 Using inetd or xinetd or stunnel is a more complex setup
147 than the "standalone" server, but it has the
148 advantage of only using system resources when an actual connection is
149 attempted. If no-one ever connects to that port, a Fossil server will
150 not (automatically) run. It has the disadvantage of requiring "root" access
151 and therefore may not normally be available to lower-priced "shared" servers
@@ -155,11 +155,11 @@
155 <a name="cgi"></a>
156 <h2>Fossil as CGI</h2><blockquote>
157 <p>
158 A Fossil server can also be run from an ordinary web server as a CGI program.
159 This feature allows Fossil to be seamlessly integrated into a larger website.
160 CGI is how the [./selfhost.wiki | self-hosting fossil repositories] are
161 implemented.
162 </p>
163 <p>
164 To run Fossil as CGI, create a CGI script (here called "repo") in the CGI directory
165 of your web server and having content like this:
@@ -184,12 +184,12 @@
184 script itself must be executable for the user under which it will run (which often differs
185 from the one running the web server - consult your site's documentation or administrator).</li>
186 <li>The repository file AND the directory containing it must be writable by the same account
187 which executes the Fossil binary (again, this might differ from the WWW user). The directory
188 needs to be writable so that sqlite can write its journal files.</li>
189 <li>Fossil must be able to create temporary files, the default directory
190 for which depends on the OS. When the CGI process is operating within
191 a chroot, ensure that this directory exists and is readable/writeable
192 by the user who executes the Fossil binary.</li>
193 </ul>
194 </p>
195
@@ -219,11 +219,11 @@
219
220 <a name="scgi"></a>
221 <h2>Fossil as SCGI</h2><blockquote>
222
223 <p>
224 The [/help/server|fossil server] command, described above as a way of
225 starting a stand-alone web server, can also be used for SCGI. Simply add
226 the --scgi command-line option and the stand-alone server will interpret
227 and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can
228 be used in combination with a webserver (such as [http://nginx.org|Nginx])
229 that does not support CGI. A typical Nginx configuration to support SCGI
@@ -284,27 +284,27 @@
284 </blockquote>
285
286 <a name="loadmgmt"></a>
287 <h2>Managing Server Load</h2><blockquote>
288 <p>
289 A Fossil server is very efficient and normally presents a very light
290 load on the server.
291 The Fossil [./selfhost.wiki | self-hosting server] is a 1/24th slice VM at
292 [http://www.linode.com | Linode.com] hosting 65 other repositories in
293 addition to Fossil (and including some very high-traffic sites such
294 as [http://www.sqlite.org] and [http://system.data.sqlite.org]) and
295 it has a typical load of 0.05 to 0.1. A single HTTP request to Fossil
296 normally takes less than 10 milliseconds of CPU time to complete. So
297 requests can be arriving at a continuous rate of 20 or more per second
298 and the CPU can still be mostly idle.
299 <p>
300 However, there are some Fossil web pages that can consume large
301 amounts of CPU time, especially on repositories with a large number
302 of files or with long revision histories. High CPU usage pages include
303 [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball],
304 [/help?cmd=/annotate | /annotate] and others. On very large repositories,
305 these commands can take 15 seconds or more of CPU time.
306 If these kinds of requests arrive too quickly, the load average on the
307 server can grow dramatically, making the server unresponsive.
308 <p>
309 Fossil provides two capabilities to help avoid server overload problems
310 due to excessive requests to expensive pages:
@@ -312,11 +312,11 @@
312 <li><p>An optional cache is available that remembers the 10 most recently
313 requested /zip or /tarball pages and returns the precomputed answer
314 if the same page is requested again.
315 <li><p>Page requests can be configured to fail with a
316 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.3 | "503 Server Overload"]
317 HTTP error if an expensive request is received while the host load
318 average is too high.
319 </ol>
320 Both of these load-control mechanisms are turned off by default, but they
321 are recommended for high-traffic sites.
322 <p>
323
M www/settings.wiki
+3 -3
--- www/settings.wiki
+++ www/settings.wiki
@@ -4,11 +4,11 @@
44
55
 Settings control the behaviour of fossil. They are set with the
66
 <tt>fossil settings</tt> command, or through the web interface in
77
 the Settings page in the Admin section.
88
9
-For a list of all settings, view the Settings page, or type
9
+For a list of all settings, view the Settings page, or type
1010
 <tt>fossil help settings</tt> from the command line.
1111
1212
1313
 <h3>Repository settings</h3>
1414
@@ -16,17 +16,17 @@
1616
 a subset of settings are copied to your local repository.
1717
1818
 If you make a change to a setting on your local repository, it is not
1919
 synced back to the server when you <tt>push</tt> or <tt>sync</tt>. If
2020
 you make a change on the server, you need to manually make the change on
21
-all repositories which are cloned from this repository.
21
+all repositories which are cloned from this repository.
2222
2323
 You can also set a setting globally on your local machine. The value
2424
 will be used for all repositories cloned to your machine, unless
2525
 overridden explicitly in a particular repository. Global settings can be
2626
 set by using the <tt>-global</tt> option on the <tt>fossil settings</tt>
27
-command.
27
+command.
2828
2929
 <h3>"Versionable" settings</h3>
3030
3131
 Most of the settings control the behaviour of fossil on your local
3232
 machine, largely acting to reflect your preference on how you want to
3333
--- www/settings.wiki
+++ www/settings.wiki
@@ -4,11 +4,11 @@
4
5 Settings control the behaviour of fossil. They are set with the
6 <tt>fossil settings</tt> command, or through the web interface in
7 the Settings page in the Admin section.
8
9 For a list of all settings, view the Settings page, or type
10 <tt>fossil help settings</tt> from the command line.
11
12
13 <h3>Repository settings</h3>
14
@@ -16,17 +16,17 @@
16 a subset of settings are copied to your local repository.
17
18 If you make a change to a setting on your local repository, it is not
19 synced back to the server when you <tt>push</tt> or <tt>sync</tt>. If
20 you make a change on the server, you need to manually make the change on
21 all repositories which are cloned from this repository.
22
23 You can also set a setting globally on your local machine. The value
24 will be used for all repositories cloned to your machine, unless
25 overridden explicitly in a particular repository. Global settings can be
26 set by using the <tt>-global</tt> option on the <tt>fossil settings</tt>
27 command.
28
29 <h3>"Versionable" settings</h3>
30
31 Most of the settings control the behaviour of fossil on your local
32 machine, largely acting to reflect your preference on how you want to
33
--- www/settings.wiki
+++ www/settings.wiki
@@ -4,11 +4,11 @@
4
5 Settings control the behaviour of fossil. They are set with the
6 <tt>fossil settings</tt> command, or through the web interface in
7 the Settings page in the Admin section.
8
9 For a list of all settings, view the Settings page, or type
10 <tt>fossil help settings</tt> from the command line.
11
12
13 <h3>Repository settings</h3>
14
@@ -16,17 +16,17 @@
16 a subset of settings are copied to your local repository.
17
18 If you make a change to a setting on your local repository, it is not
19 synced back to the server when you <tt>push</tt> or <tt>sync</tt>. If
20 you make a change on the server, you need to manually make the change on
21 all repositories which are cloned from this repository.
22
23 You can also set a setting globally on your local machine. The value
24 will be used for all repositories cloned to your machine, unless
25 overridden explicitly in a particular repository. Global settings can be
26 set by using the <tt>-global</tt> option on the <tt>fossil settings</tt>
27 command.
28
29 <h3>"Versionable" settings</h3>
30
31 Most of the settings control the behaviour of fossil on your local
32 machine, largely acting to reflect your preference on how you want to
33
M www/shunning.wiki
+10 -10
--- www/shunning.wiki
+++ www/shunning.wiki
@@ -2,11 +2,11 @@
22
 <h1 align="center">Deleting Content From Fossil</h1>
33
44
 Fossil is designed to keep all historical content forever. Users
55
 of Fossil are discouraged from "deleting" content simply because it
66
 has become obsolete. Old content is part of the historical record
7
-(part of the "fossil record") and should be maintained indefinitely.
7
+(part of the "fossil record") and should be maintained indefinitely.
88
 Such is the design intent of Fossil.
99
1010
 Nevertheless, there may occasionally arise legitimate reasons for
1111
 deleting content. Such reasons might include:
1212
@@ -21,35 +21,35 @@
2121
 disrupting the operation of Fossil.
2222
2323
 <h2>Shunning</h2>
2424
2525
 Fossil provides a mechanism called "shunning" for removing content from
26
-a repository.
26
+a repository.
2727
2828
 Every Fossil repository maintains a list of the SHA1 hash names of
2929
 "shunned" artifacts.
30
-Fossil will refuse to push or pull any shunned artifact.
30
+Fossil will refuse to push or pull any shunned artifact.
3131
 Furthermore, all shunned artifacts (but not the shunning list
3232
 itself) are removed from the
3333
 repository whenever the repository is reconstructed using the
3434
 "rebuild" command.
3535
3636
 <h3>Shunning lists are local state</h3>
3737
3838
 The shunning list is part of the local state of a Fossil repository.
39
-In other words, shunning does not propagate to a remote repository
39
+In other words, shunning does not propagate to a remote repository
4040
 using the normal "sync" mechanism. An artifact can be
4141
 shunned from one repository but be allowed to exist in another. The fact that
4242
 the shunning list does not propagate is a security feature. If the
4343
 shunning list propagated then a malicious user (or
4444
 a bug in the fossil code) might introduce a shun record that would
45
-propagate through all repositories in a network and permanently
45
+propagate through all repositories in a network and permanently
4646
 destroy vital information. By refusing to propagate the shunning list,
47
-Fossil ensures that no remote user will ever be able to remove
47
+Fossil ensures that no remote user will ever be able to remove
4848
 information from your personal repositories without your permission.
4949
50
-The shunning list does not propagate to a remote repository
50
+The shunning list does not propagate to a remote repository
5151
 by the normal "sync" mechanism,
5252
 but it is still possible to copy shuns from one repository to another
5353
 using the "configuration" command:
5454
5555
 <b>fossil configuration pull shun</b> <i>remote-url</i><br>
@@ -56,12 +56,12 @@
5656
 <b>fossil configuration push shun</b> <i>remote-url</i>
5757
5858
 The two command above will pull or push shunning lists from or to
5959
 the <i>remote-url</i> indicated and merge the lists on the receiving
6060
 end. "Admin" privilege on the remote server is required in order to
61
-push a shun list. In contrast, the shunning list will be automatically
62
-received by default as part of a normal client "pull" operation unless
61
+push a shun list. In contrast, the shunning list will be automatically
62
+received by default as part of a normal client "pull" operation unless
6363
 disabled by the "<tt>auto-shun</tt>" setting.
6464
6565
 Note that the shunning list remains in the repository even after the
6666
 shunned artifact has been removed. This is to prevent the artifact
6767
 from being reintroduced into the repository the next time it syncs with
@@ -68,11 +68,11 @@
6868
 another repository that has not shunned the artifact.
6969
7070
 <h3>Managing the shunning list</h3>
7171
7272
 The complete shunning list for a repository can be viewed by a user
73
-with "admin" privilege on the "/shun" URL of the web interface to Fossil.
73
+with "admin" privilege on the "/shun" URL of the web interface to Fossil.
7474
 That URL is accessible under the "Admin" button on the default menu
7575
 bar. Items can be added to or removed from the shunning list. "Sync"
7676
 operations are inhibited as soon as the artifact is added to the
7777
 shunning list, but the content of the artifact is not actually removed
7878
 from the repository until the next time the repository is rebuilt.
7979
--- www/shunning.wiki
+++ www/shunning.wiki
@@ -2,11 +2,11 @@
2 <h1 align="center">Deleting Content From Fossil</h1>
3
4 Fossil is designed to keep all historical content forever. Users
5 of Fossil are discouraged from "deleting" content simply because it
6 has become obsolete. Old content is part of the historical record
7 (part of the "fossil record") and should be maintained indefinitely.
8 Such is the design intent of Fossil.
9
10 Nevertheless, there may occasionally arise legitimate reasons for
11 deleting content. Such reasons might include:
12
@@ -21,35 +21,35 @@
21 disrupting the operation of Fossil.
22
23 <h2>Shunning</h2>
24
25 Fossil provides a mechanism called "shunning" for removing content from
26 a repository.
27
28 Every Fossil repository maintains a list of the SHA1 hash names of
29 "shunned" artifacts.
30 Fossil will refuse to push or pull any shunned artifact.
31 Furthermore, all shunned artifacts (but not the shunning list
32 itself) are removed from the
33 repository whenever the repository is reconstructed using the
34 "rebuild" command.
35
36 <h3>Shunning lists are local state</h3>
37
38 The shunning list is part of the local state of a Fossil repository.
39 In other words, shunning does not propagate to a remote repository
40 using the normal "sync" mechanism. An artifact can be
41 shunned from one repository but be allowed to exist in another. The fact that
42 the shunning list does not propagate is a security feature. If the
43 shunning list propagated then a malicious user (or
44 a bug in the fossil code) might introduce a shun record that would
45 propagate through all repositories in a network and permanently
46 destroy vital information. By refusing to propagate the shunning list,
47 Fossil ensures that no remote user will ever be able to remove
48 information from your personal repositories without your permission.
49
50 The shunning list does not propagate to a remote repository
51 by the normal "sync" mechanism,
52 but it is still possible to copy shuns from one repository to another
53 using the "configuration" command:
54
55 <b>fossil configuration pull shun</b> <i>remote-url</i><br>
@@ -56,12 +56,12 @@
56 <b>fossil configuration push shun</b> <i>remote-url</i>
57
58 The two command above will pull or push shunning lists from or to
59 the <i>remote-url</i> indicated and merge the lists on the receiving
60 end. "Admin" privilege on the remote server is required in order to
61 push a shun list. In contrast, the shunning list will be automatically
62 received by default as part of a normal client "pull" operation unless
63 disabled by the "<tt>auto-shun</tt>" setting.
64
65 Note that the shunning list remains in the repository even after the
66 shunned artifact has been removed. This is to prevent the artifact
67 from being reintroduced into the repository the next time it syncs with
@@ -68,11 +68,11 @@
68 another repository that has not shunned the artifact.
69
70 <h3>Managing the shunning list</h3>
71
72 The complete shunning list for a repository can be viewed by a user
73 with "admin" privilege on the "/shun" URL of the web interface to Fossil.
74 That URL is accessible under the "Admin" button on the default menu
75 bar. Items can be added to or removed from the shunning list. "Sync"
76 operations are inhibited as soon as the artifact is added to the
77 shunning list, but the content of the artifact is not actually removed
78 from the repository until the next time the repository is rebuilt.
79
--- www/shunning.wiki
+++ www/shunning.wiki
@@ -2,11 +2,11 @@
2 <h1 align="center">Deleting Content From Fossil</h1>
3
4 Fossil is designed to keep all historical content forever. Users
5 of Fossil are discouraged from "deleting" content simply because it
6 has become obsolete. Old content is part of the historical record
7 (part of the "fossil record") and should be maintained indefinitely.
8 Such is the design intent of Fossil.
9
10 Nevertheless, there may occasionally arise legitimate reasons for
11 deleting content. Such reasons might include:
12
@@ -21,35 +21,35 @@
21 disrupting the operation of Fossil.
22
23 <h2>Shunning</h2>
24
25 Fossil provides a mechanism called "shunning" for removing content from
26 a repository.
27
28 Every Fossil repository maintains a list of the SHA1 hash names of
29 "shunned" artifacts.
30 Fossil will refuse to push or pull any shunned artifact.
31 Furthermore, all shunned artifacts (but not the shunning list
32 itself) are removed from the
33 repository whenever the repository is reconstructed using the
34 "rebuild" command.
35
36 <h3>Shunning lists are local state</h3>
37
38 The shunning list is part of the local state of a Fossil repository.
39 In other words, shunning does not propagate to a remote repository
40 using the normal "sync" mechanism. An artifact can be
41 shunned from one repository but be allowed to exist in another. The fact that
42 the shunning list does not propagate is a security feature. If the
43 shunning list propagated then a malicious user (or
44 a bug in the fossil code) might introduce a shun record that would
45 propagate through all repositories in a network and permanently
46 destroy vital information. By refusing to propagate the shunning list,
47 Fossil ensures that no remote user will ever be able to remove
48 information from your personal repositories without your permission.
49
50 The shunning list does not propagate to a remote repository
51 by the normal "sync" mechanism,
52 but it is still possible to copy shuns from one repository to another
53 using the "configuration" command:
54
55 <b>fossil configuration pull shun</b> <i>remote-url</i><br>
@@ -56,12 +56,12 @@
56 <b>fossil configuration push shun</b> <i>remote-url</i>
57
58 The two command above will pull or push shunning lists from or to
59 the <i>remote-url</i> indicated and merge the lists on the receiving
60 end. "Admin" privilege on the remote server is required in order to
61 push a shun list. In contrast, the shunning list will be automatically
62 received by default as part of a normal client "pull" operation unless
63 disabled by the "<tt>auto-shun</tt>" setting.
64
65 Note that the shunning list remains in the repository even after the
66 shunned artifact has been removed. This is to prevent the artifact
67 from being reintroduced into the repository the next time it syncs with
@@ -68,11 +68,11 @@
68 another repository that has not shunned the artifact.
69
70 <h3>Managing the shunning list</h3>
71
72 The complete shunning list for a repository can be viewed by a user
73 with "admin" privilege on the "/shun" URL of the web interface to Fossil.
74 That URL is accessible under the "Admin" button on the default menu
75 bar. Items can be added to or removed from the shunning list. "Sync"
76 operations are inhibited as soon as the artifact is added to the
77 shunning list, but the content of the artifact is not actually removed
78 from the repository until the next time the repository is rebuilt.
79
M www/stats.wiki
+3 -3
--- www/stats.wiki
+++ www/stats.wiki
@@ -1,9 +1,9 @@
11
 <title>Fossil Performance</title>
22
 <h1 align="center">Performance Statistics</h1>
33
4
-The questions will inevitably arise: How does Fossil perform?
4
+The questions will inevitably arise: How does Fossil perform?
55
 Does it use a lot of disk space or bandwidth? Is it scalable?
66
77
 In an attempt to answers these questions, this report looks at several
88
 projects that use fossil for configuration management and examines how
99
 well they are working. The following table is a summary of the results.
@@ -96,21 +96,21 @@
9696
 every ticket, and every check-in is a separate "artifact". One way to
9797
 think of a Fossil project is as a bag of artifacts. Of course, there is
9898
 a lot more than this going on in Fossil. Many of the artifacts have meaning
9999
 and are related to other artifacts. But at a low level (for example when
100100
 synchronizing two instances of the same project) the only thing that matters
101
-is the unordered collection of artifacts. In fact, one of the key
101
+is the unordered collection of artifacts. In fact, one of the key
102102
 characteristics of Fossil is that the entire project history can be
103103
 reconstructed simply by scanning the artifacts in an arbitrary order.
104104
105105
 The number of check-ins is the number of times that the "commit" command
106106
 has been run. A single check-in might change a 3 or 4 files, or it might
107107
 change dozens or hundreds of files. Regardless of the number of files
108108
 changed, it still only counts as one check-in.
109109
110110
 The "Uncompressed Size" is the total size of all the artifacts within
111
-the repository assuming they were all uncompressed and stored
111
+the repository assuming they were all uncompressed and stored
112112
 separately on the disk. Fossil makes use of delta compression between related
113113
 versions of the same file, and then uses zlib compression on the resulting
114114
 deltas. The total resulting repository size is shown after the uncompressed
115115
 size.
116116
117117
--- www/stats.wiki
+++ www/stats.wiki
@@ -1,9 +1,9 @@
1 <title>Fossil Performance</title>
2 <h1 align="center">Performance Statistics</h1>
3
4 The questions will inevitably arise: How does Fossil perform?
5 Does it use a lot of disk space or bandwidth? Is it scalable?
6
7 In an attempt to answers these questions, this report looks at several
8 projects that use fossil for configuration management and examines how
9 well they are working. The following table is a summary of the results.
@@ -96,21 +96,21 @@
96 every ticket, and every check-in is a separate "artifact". One way to
97 think of a Fossil project is as a bag of artifacts. Of course, there is
98 a lot more than this going on in Fossil. Many of the artifacts have meaning
99 and are related to other artifacts. But at a low level (for example when
100 synchronizing two instances of the same project) the only thing that matters
101 is the unordered collection of artifacts. In fact, one of the key
102 characteristics of Fossil is that the entire project history can be
103 reconstructed simply by scanning the artifacts in an arbitrary order.
104
105 The number of check-ins is the number of times that the "commit" command
106 has been run. A single check-in might change a 3 or 4 files, or it might
107 change dozens or hundreds of files. Regardless of the number of files
108 changed, it still only counts as one check-in.
109
110 The "Uncompressed Size" is the total size of all the artifacts within
111 the repository assuming they were all uncompressed and stored
112 separately on the disk. Fossil makes use of delta compression between related
113 versions of the same file, and then uses zlib compression on the resulting
114 deltas. The total resulting repository size is shown after the uncompressed
115 size.
116
117
--- www/stats.wiki
+++ www/stats.wiki
@@ -1,9 +1,9 @@
1 <title>Fossil Performance</title>
2 <h1 align="center">Performance Statistics</h1>
3
4 The questions will inevitably arise: How does Fossil perform?
5 Does it use a lot of disk space or bandwidth? Is it scalable?
6
7 In an attempt to answers these questions, this report looks at several
8 projects that use fossil for configuration management and examines how
9 well they are working. The following table is a summary of the results.
@@ -96,21 +96,21 @@
96 every ticket, and every check-in is a separate "artifact". One way to
97 think of a Fossil project is as a bag of artifacts. Of course, there is
98 a lot more than this going on in Fossil. Many of the artifacts have meaning
99 and are related to other artifacts. But at a low level (for example when
100 synchronizing two instances of the same project) the only thing that matters
101 is the unordered collection of artifacts. In fact, one of the key
102 characteristics of Fossil is that the entire project history can be
103 reconstructed simply by scanning the artifacts in an arbitrary order.
104
105 The number of check-ins is the number of times that the "commit" command
106 has been run. A single check-in might change a 3 or 4 files, or it might
107 change dozens or hundreds of files. Regardless of the number of files
108 changed, it still only counts as one check-in.
109
110 The "Uncompressed Size" is the total size of all the artifacts within
111 the repository assuming they were all uncompressed and stored
112 separately on the disk. Fossil makes use of delta compression between related
113 versions of the same file, and then uses zlib compression on the resulting
114 deltas. The total resulting repository size is shown after the uncompressed
115 size.
116
117
M www/sync.wiki
+6 -6
--- www/sync.wiki
+++ www/sync.wiki
@@ -1,8 +1,8 @@
11
 <title>The Fossil Sync Protocol</title>
22
3
-<p>This document describes the wire protocol used to synchronize
3
+<p>This document describes the wire protocol used to synchronize
44
 content between two Fossil repositories.</p>
55
66
 <h2>1.0 Overview</h2>
77
88
 <p>The global state of a fossil repository consists of an unordered
@@ -22,11 +22,11 @@
2222
 shared to a few hundred.</p>
2323
2424
 <p>Each repository also has local state. The local state determines
2525
 the web-page formatting preferences, authorized users, ticket formats,
2626
 and similar information that varies from one repository to another.
27
-The local state is not using transferred during a sync. Except,
27
+The local state is not using transferred during a sync. Except,
2828
 some local state is transferred during a [/help?cmd=clone|clone]
2929
 in order to initialize the local state of the new repository. And
3030
 the [/help?cmd=configuration|config push] and
3131
 [/help?cmd=configuration|config pull]
3232
 commands can be an administrator to sync local state.</p>
@@ -40,15 +40,15 @@
4040
 request.</p>
4141
4242
 <p>The server might be running as an independent server
4343
 using the <b>server</b> command, or it might be launched from
4444
 inetd or xinetd using the <b>http</b> command. Or the server might
45
-be launched from CGI.
45
+be launched from CGI.
4646
 (See "[./server.wiki|How To Configure A Fossil Server]" for details.)
4747
 The specifics of how the server listens
4848
 for incoming HTTP requests is immaterial to this protocol.
49
-The important point is that the server is listening for requests and
49
+The important point is that the server is listening for requests and
5050
 the client is the issuer of the requests.</p>
5151
5252
 <p>A single push, pull, or sync might involve multiple HTTP requests.
5353
 The client maintains state between all requests. But on the server
5454
 side, each request is independent. The server does not preserve
@@ -55,11 +55,11 @@
5555
 any information about the client from one request to the next.</p>
5656
5757
 <h4>2.0.1 Encrypted Transport</h4>
5858
5959
 <p>In the current implementation of Fossil, the server only
60
-understands HTTP requests. The client can send either
60
+understands HTTP requests. The client can send either
6161
 clear-text HTTP requests or encrypted HTTPS requests. But when
6262
 HTTPS requests are sent, they first must be decrypted by a webserver
6363
 or proxy before being passed to the Fossil server. This limitation
6464
 may be relaxed in a future release.</p>
6565
@@ -408,11 +408,11 @@
408408
 <b>uvigot</b> <i>name mtime hash size</i>
409409
 </blockquote>
410410
411411
 <p>The <i>name</i> argument is the name of an unversioned file.
412412
 The <i>mtime</i> is the last modification time of the unversioned file
413
-in seconds since 1970.
413
+in seconds since 1970.
414414
 The <i>hash</i> is the SHA1 hash of the unversioned file content, or
415415
 "<b>-</b>" if the file has been deleted.
416416
 The <i>size</i> is the uncompressed size of the file in bytes.
417417
418418
 <p>When the server sees a "pragma uv-hash" card for which the hash
419419
--- www/sync.wiki
+++ www/sync.wiki
@@ -1,8 +1,8 @@
1 <title>The Fossil Sync Protocol</title>
2
3 <p>This document describes the wire protocol used to synchronize
4 content between two Fossil repositories.</p>
5
6 <h2>1.0 Overview</h2>
7
8 <p>The global state of a fossil repository consists of an unordered
@@ -22,11 +22,11 @@
22 shared to a few hundred.</p>
23
24 <p>Each repository also has local state. The local state determines
25 the web-page formatting preferences, authorized users, ticket formats,
26 and similar information that varies from one repository to another.
27 The local state is not using transferred during a sync. Except,
28 some local state is transferred during a [/help?cmd=clone|clone]
29 in order to initialize the local state of the new repository. And
30 the [/help?cmd=configuration|config push] and
31 [/help?cmd=configuration|config pull]
32 commands can be an administrator to sync local state.</p>
@@ -40,15 +40,15 @@
40 request.</p>
41
42 <p>The server might be running as an independent server
43 using the <b>server</b> command, or it might be launched from
44 inetd or xinetd using the <b>http</b> command. Or the server might
45 be launched from CGI.
46 (See "[./server.wiki|How To Configure A Fossil Server]" for details.)
47 The specifics of how the server listens
48 for incoming HTTP requests is immaterial to this protocol.
49 The important point is that the server is listening for requests and
50 the client is the issuer of the requests.</p>
51
52 <p>A single push, pull, or sync might involve multiple HTTP requests.
53 The client maintains state between all requests. But on the server
54 side, each request is independent. The server does not preserve
@@ -55,11 +55,11 @@
55 any information about the client from one request to the next.</p>
56
57 <h4>2.0.1 Encrypted Transport</h4>
58
59 <p>In the current implementation of Fossil, the server only
60 understands HTTP requests. The client can send either
61 clear-text HTTP requests or encrypted HTTPS requests. But when
62 HTTPS requests are sent, they first must be decrypted by a webserver
63 or proxy before being passed to the Fossil server. This limitation
64 may be relaxed in a future release.</p>
65
@@ -408,11 +408,11 @@
408 <b>uvigot</b> <i>name mtime hash size</i>
409 </blockquote>
410
411 <p>The <i>name</i> argument is the name of an unversioned file.
412 The <i>mtime</i> is the last modification time of the unversioned file
413 in seconds since 1970.
414 The <i>hash</i> is the SHA1 hash of the unversioned file content, or
415 "<b>-</b>" if the file has been deleted.
416 The <i>size</i> is the uncompressed size of the file in bytes.
417
418 <p>When the server sees a "pragma uv-hash" card for which the hash
419
--- www/sync.wiki
+++ www/sync.wiki
@@ -1,8 +1,8 @@
1 <title>The Fossil Sync Protocol</title>
2
3 <p>This document describes the wire protocol used to synchronize
4 content between two Fossil repositories.</p>
5
6 <h2>1.0 Overview</h2>
7
8 <p>The global state of a fossil repository consists of an unordered
@@ -22,11 +22,11 @@
22 shared to a few hundred.</p>
23
24 <p>Each repository also has local state. The local state determines
25 the web-page formatting preferences, authorized users, ticket formats,
26 and similar information that varies from one repository to another.
27 The local state is not using transferred during a sync. Except,
28 some local state is transferred during a [/help?cmd=clone|clone]
29 in order to initialize the local state of the new repository. And
30 the [/help?cmd=configuration|config push] and
31 [/help?cmd=configuration|config pull]
32 commands can be an administrator to sync local state.</p>
@@ -40,15 +40,15 @@
40 request.</p>
41
42 <p>The server might be running as an independent server
43 using the <b>server</b> command, or it might be launched from
44 inetd or xinetd using the <b>http</b> command. Or the server might
45 be launched from CGI.
46 (See "[./server.wiki|How To Configure A Fossil Server]" for details.)
47 The specifics of how the server listens
48 for incoming HTTP requests is immaterial to this protocol.
49 The important point is that the server is listening for requests and
50 the client is the issuer of the requests.</p>
51
52 <p>A single push, pull, or sync might involve multiple HTTP requests.
53 The client maintains state between all requests. But on the server
54 side, each request is independent. The server does not preserve
@@ -55,11 +55,11 @@
55 any information about the client from one request to the next.</p>
56
57 <h4>2.0.1 Encrypted Transport</h4>
58
59 <p>In the current implementation of Fossil, the server only
60 understands HTTP requests. The client can send either
61 clear-text HTTP requests or encrypted HTTPS requests. But when
62 HTTPS requests are sent, they first must be decrypted by a webserver
63 or proxy before being passed to the Fossil server. This limitation
64 may be relaxed in a future release.</p>
65
@@ -408,11 +408,11 @@
408 <b>uvigot</b> <i>name mtime hash size</i>
409 </blockquote>
410
411 <p>The <i>name</i> argument is the name of an unversioned file.
412 The <i>mtime</i> is the last modification time of the unversioned file
413 in seconds since 1970.
414 The <i>hash</i> is the SHA1 hash of the unversioned file content, or
415 "<b>-</b>" if the file has been deleted.
416 The <i>size</i> is the uncompressed size of the file in bytes.
417
418 <p>When the server sees a "pragma uv-hash" card for which the hash
419
M www/theory1.wiki
+5 -5
--- www/theory1.wiki
+++ www/theory1.wiki
@@ -16,18 +16,18 @@
1616
1717
 <h2>Fossil Is A NoSQL Database</h2>
1818
1919
 We begin with the first question: Fossil is not based on a distributed
2020
 NoSQL database because Fossil <u><i>is</i></u> a distributed NoSQL database.
21
-Fossil is <u>not</u> based on SQLite.
21
+Fossil is <u>not</u> based on SQLite.
2222
 The current implementation of Fossil uses
2323
 SQLite as a local store for the content of the distributed database and as
2424
 a cache for meta-information about the distributed database that is precomputed
2525
 for quick and easy presentation. But the use of SQLite in this role is an
2626
 implementation detail and is not fundamental to the design. Some future
2727
 version of Fossil might do away with SQLite and substitute a pile-of-files or
28
-a key/value database in place of SQLite.
28
+a key/value database in place of SQLite.
2929
 (Actually, that is very unlikely
3030
 to happen since SQLite works amazingly well in its current role, but the point
3131
 is that omitting SQLite from Fossil is a theoretical possibility.)
3232
3333
 The underlying database that Fossil implements has nothing to do with
@@ -64,11 +64,11 @@
6464
 a NoSQL database) and there is the local relational database. The
6565
 bag-of-artifacts database has a fixed format and is what defines a Fossil
6666
 repository. Fossil will never modify the file format of the bag-of-artifacts
6767
 database in an incompatible way because to do so would be to make something
6868
 that is no longer "Fossil". The local relational database, on the other hand,
69
-is a cache that contains information derived from the bag-of-artifacts.
69
+is a cache that contains information derived from the bag-of-artifacts.
7070
 The schema of the local relational database changes from time to time as
7171
 the Fossil implementation is enhanced, and the content is recomputed from
7272
 the unchanging bag of artifacts. The local relational database is an
7373
 implementation detail which currently happens to use SQLite.
7474
@@ -89,11 +89,11 @@
8989
 the first question.
9090
9191
 <h2>SQL Is A High-Level Scripting Language</h2>
9292
9393
 The second concern states that Fossil does not use a high-level scripting
94
-language. But that is not true. Fossil uses SQL (as implemented by SQLite)
94
+language. But that is not true. Fossil uses SQL (as implemented by SQLite)
9595
 as its scripting language.
9696
9797
 This misunderstanding likely arises because people fail
9898
 to appreciate that SQL is a programming language. People are taught that SQL
9999
 is a "query language" as if that were somehow different from a
@@ -125,11 +125,11 @@
125125
 out using SQL statements. It is true that these SQL statements are glued
126126
 together with C code, but it turns out that C works surprisingly well in
127127
 that role. Several early prototypes of Fossil were written in a scripting
128128
 language (TCL). We normally find that TCL programs are shorter than the
129129
 equivalent C code by a factor of 10 or more. But in the case of Fossil,
130
-the use of TCL was actually making the code longer and more difficult to
130
+the use of TCL was actually making the code longer and more difficult to
131131
 understand.
132132
 And so in the final design, we switched from TCL to C in order to make
133133
 the code easier to implement and debug.
134134
135135
 Without the advantages of having SQLite built in, the design might well
136136
--- www/theory1.wiki
+++ www/theory1.wiki
@@ -16,18 +16,18 @@
16
17 <h2>Fossil Is A NoSQL Database</h2>
18
19 We begin with the first question: Fossil is not based on a distributed
20 NoSQL database because Fossil <u><i>is</i></u> a distributed NoSQL database.
21 Fossil is <u>not</u> based on SQLite.
22 The current implementation of Fossil uses
23 SQLite as a local store for the content of the distributed database and as
24 a cache for meta-information about the distributed database that is precomputed
25 for quick and easy presentation. But the use of SQLite in this role is an
26 implementation detail and is not fundamental to the design. Some future
27 version of Fossil might do away with SQLite and substitute a pile-of-files or
28 a key/value database in place of SQLite.
29 (Actually, that is very unlikely
30 to happen since SQLite works amazingly well in its current role, but the point
31 is that omitting SQLite from Fossil is a theoretical possibility.)
32
33 The underlying database that Fossil implements has nothing to do with
@@ -64,11 +64,11 @@
64 a NoSQL database) and there is the local relational database. The
65 bag-of-artifacts database has a fixed format and is what defines a Fossil
66 repository. Fossil will never modify the file format of the bag-of-artifacts
67 database in an incompatible way because to do so would be to make something
68 that is no longer "Fossil". The local relational database, on the other hand,
69 is a cache that contains information derived from the bag-of-artifacts.
70 The schema of the local relational database changes from time to time as
71 the Fossil implementation is enhanced, and the content is recomputed from
72 the unchanging bag of artifacts. The local relational database is an
73 implementation detail which currently happens to use SQLite.
74
@@ -89,11 +89,11 @@
89 the first question.
90
91 <h2>SQL Is A High-Level Scripting Language</h2>
92
93 The second concern states that Fossil does not use a high-level scripting
94 language. But that is not true. Fossil uses SQL (as implemented by SQLite)
95 as its scripting language.
96
97 This misunderstanding likely arises because people fail
98 to appreciate that SQL is a programming language. People are taught that SQL
99 is a "query language" as if that were somehow different from a
@@ -125,11 +125,11 @@
125 out using SQL statements. It is true that these SQL statements are glued
126 together with C code, but it turns out that C works surprisingly well in
127 that role. Several early prototypes of Fossil were written in a scripting
128 language (TCL). We normally find that TCL programs are shorter than the
129 equivalent C code by a factor of 10 or more. But in the case of Fossil,
130 the use of TCL was actually making the code longer and more difficult to
131 understand.
132 And so in the final design, we switched from TCL to C in order to make
133 the code easier to implement and debug.
134
135 Without the advantages of having SQLite built in, the design might well
136
--- www/theory1.wiki
+++ www/theory1.wiki
@@ -16,18 +16,18 @@
16
17 <h2>Fossil Is A NoSQL Database</h2>
18
19 We begin with the first question: Fossil is not based on a distributed
20 NoSQL database because Fossil <u><i>is</i></u> a distributed NoSQL database.
21 Fossil is <u>not</u> based on SQLite.
22 The current implementation of Fossil uses
23 SQLite as a local store for the content of the distributed database and as
24 a cache for meta-information about the distributed database that is precomputed
25 for quick and easy presentation. But the use of SQLite in this role is an
26 implementation detail and is not fundamental to the design. Some future
27 version of Fossil might do away with SQLite and substitute a pile-of-files or
28 a key/value database in place of SQLite.
29 (Actually, that is very unlikely
30 to happen since SQLite works amazingly well in its current role, but the point
31 is that omitting SQLite from Fossil is a theoretical possibility.)
32
33 The underlying database that Fossil implements has nothing to do with
@@ -64,11 +64,11 @@
64 a NoSQL database) and there is the local relational database. The
65 bag-of-artifacts database has a fixed format and is what defines a Fossil
66 repository. Fossil will never modify the file format of the bag-of-artifacts
67 database in an incompatible way because to do so would be to make something
68 that is no longer "Fossil". The local relational database, on the other hand,
69 is a cache that contains information derived from the bag-of-artifacts.
70 The schema of the local relational database changes from time to time as
71 the Fossil implementation is enhanced, and the content is recomputed from
72 the unchanging bag of artifacts. The local relational database is an
73 implementation detail which currently happens to use SQLite.
74
@@ -89,11 +89,11 @@
89 the first question.
90
91 <h2>SQL Is A High-Level Scripting Language</h2>
92
93 The second concern states that Fossil does not use a high-level scripting
94 language. But that is not true. Fossil uses SQL (as implemented by SQLite)
95 as its scripting language.
96
97 This misunderstanding likely arises because people fail
98 to appreciate that SQL is a programming language. People are taught that SQL
99 is a "query language" as if that were somehow different from a
@@ -125,11 +125,11 @@
125 out using SQL statements. It is true that these SQL statements are glued
126 together with C code, but it turns out that C works surprisingly well in
127 that role. Several early prototypes of Fossil were written in a scripting
128 language (TCL). We normally find that TCL programs are shorter than the
129 equivalent C code by a factor of 10 or more. But in the case of Fossil,
130 the use of TCL was actually making the code longer and more difficult to
131 understand.
132 And so in the final design, we switched from TCL to C in order to make
133 the code easier to implement and debug.
134
135 Without the advantages of having SQLite built in, the design might well
136
M www/wikitheory.wiki
+4 -4
--- www/wikitheory.wiki
+++ www/wikitheory.wiki
@@ -34,26 +34,26 @@
3434
 the wiki page will fork. The web interface will display whichever edit
3535
 was checked in last. The other edit can be found in the history. The
3636
 file format will support merging the branches back together, but there
3737
 is no mechanism in the user interface (yet) to perform the merge.
3838
39
-Every change to a wiki page is a separate
39
+Every change to a wiki page is a separate
4040
 [./fileformat.wiki | control artifact]
4141
 of type [./fileformat.wiki#wikichng | "Wiki Page"].
4242
4343
 <h2>Embedded Documentation</h2>
4444
4545
 Files in the source tree that use the ".wiki", ".md", or ".markdown" suffixes
46
-can be accessed and displayed using special URLs to the fossil server.
46
+can be accessed and displayed using special URLs to the fossil server.
4747
 This allows
48
-project documentation to be stored in the source tree and accessed
48
+project documentation to be stored in the source tree and accessed
4949
 online. (Details are described [./embeddeddoc.wiki | separately].)
5050
5151
 Some projects prefer to store their documentation in wiki. There is nothing
5252
 wrong with that. But other projects prefer to keep documentation as part
5353
 of the source tree, so that it is versioned along with the source tree and
54
-so that only developers with check-in privileges can change it.
54
+so that only developers with check-in privileges can change it.
5555
 Embedded documentation serves this latter purpose. Both forms of documentation
5656
 use the exact same markup. Some projects may choose to
5757
 use both forms of documentation at the same time. Because the same
5858
 format is used, it is trivial to move a file from wiki to embedded documentation
5959
 or back again as the project evolves.
6060
--- www/wikitheory.wiki
+++ www/wikitheory.wiki
@@ -34,26 +34,26 @@
34 the wiki page will fork. The web interface will display whichever edit
35 was checked in last. The other edit can be found in the history. The
36 file format will support merging the branches back together, but there
37 is no mechanism in the user interface (yet) to perform the merge.
38
39 Every change to a wiki page is a separate
40 [./fileformat.wiki | control artifact]
41 of type [./fileformat.wiki#wikichng | "Wiki Page"].
42
43 <h2>Embedded Documentation</h2>
44
45 Files in the source tree that use the ".wiki", ".md", or ".markdown" suffixes
46 can be accessed and displayed using special URLs to the fossil server.
47 This allows
48 project documentation to be stored in the source tree and accessed
49 online. (Details are described [./embeddeddoc.wiki | separately].)
50
51 Some projects prefer to store their documentation in wiki. There is nothing
52 wrong with that. But other projects prefer to keep documentation as part
53 of the source tree, so that it is versioned along with the source tree and
54 so that only developers with check-in privileges can change it.
55 Embedded documentation serves this latter purpose. Both forms of documentation
56 use the exact same markup. Some projects may choose to
57 use both forms of documentation at the same time. Because the same
58 format is used, it is trivial to move a file from wiki to embedded documentation
59 or back again as the project evolves.
60
--- www/wikitheory.wiki
+++ www/wikitheory.wiki
@@ -34,26 +34,26 @@
34 the wiki page will fork. The web interface will display whichever edit
35 was checked in last. The other edit can be found in the history. The
36 file format will support merging the branches back together, but there
37 is no mechanism in the user interface (yet) to perform the merge.
38
39 Every change to a wiki page is a separate
40 [./fileformat.wiki | control artifact]
41 of type [./fileformat.wiki#wikichng | "Wiki Page"].
42
43 <h2>Embedded Documentation</h2>
44
45 Files in the source tree that use the ".wiki", ".md", or ".markdown" suffixes
46 can be accessed and displayed using special URLs to the fossil server.
47 This allows
48 project documentation to be stored in the source tree and accessed
49 online. (Details are described [./embeddeddoc.wiki | separately].)
50
51 Some projects prefer to store their documentation in wiki. There is nothing
52 wrong with that. But other projects prefer to keep documentation as part
53 of the source tree, so that it is versioned along with the source tree and
54 so that only developers with check-in privileges can change it.
55 Embedded documentation serves this latter purpose. Both forms of documentation
56 use the exact same markup. Some projects may choose to
57 use both forms of documentation at the same time. Because the same
58 format is used, it is trivial to move a file from wiki to embedded documentation
59 or back again as the project evolves.
60

Keyboard Shortcuts

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