Fossil SCM
Fix documentation typos.
Commit
b16b4337b9f5736afc279cbcdd53fb60d667c1c9
Parent
15b293259de5484…
11 files changed
+4
-4
+1
-1
+1
-1
+1
-1
+3
-3
+3
-3
+1
-1
+3
-3
+4
-4
+2
-2
+3
-3
+4
-4
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -51,20 +51,20 @@ | ||
| 51 | 51 | editing check-in 2 are named Alice and Bob. Suppose Alice finished her |
| 52 | 52 | edits first and did a commit, resulting in check-in 3. Later, when Bob |
| 53 | 53 | tried to commit his changes, fossil would try to verify that check-in 2 |
| 54 | 54 | was still a leaf. Fossil would see that check-in 3 had occurred and would |
| 55 | 55 | abort Bob's commit attempt with a message "would fork". This allows Bob |
| 56 | -to do a "fossil update" which would pull in Alices changes and merge them | |
| 56 | +to do a "fossil update" which would pull in Alice's changes and merge them | |
| 57 | 57 | together with his own changes. After merging, Bob could then commit |
| 58 | 58 | check-in 4 as a child of check-in 3 and the result would be a linear graph |
| 59 | 59 | as shown in figure 1. This is how CVS works. This is also how fossil |
| 60 | 60 | works in "autosync" mode. |
| 61 | 61 | |
| 62 | 62 | But it might be that Bob is off-network when he does his commit, so he |
| 63 | 63 | has no way of knowing that Alice has already committed her changes. |
| 64 | 64 | Or, it could be that Bob has turned off "autosync" mode in SQLite. Or, |
| 65 | -maybe Bob just doesn't want to merge in Alices changes before he has | |
| 65 | +maybe Bob just doesn't want to merge in Alice's changes before he has | |
| 66 | 66 | saved his own, so he forces the commit to occur using the "--force" option |
| 67 | 67 | to the fossil <b>commit</b> command. For whatever reason, two commits against |
| 68 | 68 | check-in 2 have occurred and now the tree has two leaves. |
| 69 | 69 | |
| 70 | 70 | So which version of the project is the "latest" in the sense of having |
| @@ -194,11 +194,11 @@ | ||
| 194 | 194 | are symbolic name tags. When a symbolic name tag is attached to a |
| 195 | 195 | check-in, that allows you to refer to that check-in by its symbolic |
| 196 | 196 | name rather than by its 40-character SHA1 hash name. When a symbolic name |
| 197 | 197 | tag propagates (as does the <b>sym-trunk</b> tag) then referring to that |
| 198 | 198 | name is the same as referring to the most recent check-in with that name. |
| 199 | -Thus the two tags on check-in one cause all decendents to be in the | |
| 199 | +Thus the two tags on check-in one cause all descendants to be in the | |
| 200 | 200 | "trunk" branch and to have the symbolic name "trunk". |
| 201 | 201 | |
| 202 | 202 | Check-in 4 has a <b>branch</b> tag which changes the name of the branch |
| 203 | 203 | to "test". The branch tag on check-in 4 propagates to check-ins 6 and 9. |
| 204 | 204 | But because tag propagation does not follow merge links, the <b>branch=test</b> |
| @@ -238,11 +238,11 @@ | ||
| 238 | 238 | branch property.</p></dd> |
| 239 | 239 | <dt><b>Leaf</b></dt> |
| 240 | 240 | <dd><p>A leaf is a check-in that has no children in the same branch.</p></dd> |
| 241 | 241 | <dt><b>Closed Leaf</b></dt> |
| 242 | 242 | <dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves |
| 243 | -are intented to never be extended with descendents and hence are omitted | |
| 243 | +are intented to never be extended with descendants and hence are omitted | |
| 244 | 244 | from lists of leaves in the command-line and web interface.</p></dd> |
| 245 | 245 | <dt><b>Open Leaf</b></dt> |
| 246 | 246 | <dd><p>A open leaf is a leaf that is not closed.</p></dd> |
| 247 | 247 | <dt><b>Fork</b></dt> |
| 248 | 248 | <dd><p>A fork occurs when a check-in has two or more direct (non-merge) |
| 249 | 249 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -51,20 +51,20 @@ | |
| 51 | editing check-in 2 are named Alice and Bob. Suppose Alice finished her |
| 52 | edits first and did a commit, resulting in check-in 3. Later, when Bob |
| 53 | tried to commit his changes, fossil would try to verify that check-in 2 |
| 54 | was still a leaf. Fossil would see that check-in 3 had occurred and would |
| 55 | abort Bob's commit attempt with a message "would fork". This allows Bob |
| 56 | to do a "fossil update" which would pull in Alices changes and merge them |
| 57 | together with his own changes. After merging, Bob could then commit |
| 58 | check-in 4 as a child of check-in 3 and the result would be a linear graph |
| 59 | as shown in figure 1. This is how CVS works. This is also how fossil |
| 60 | works in "autosync" mode. |
| 61 | |
| 62 | But it might be that Bob is off-network when he does his commit, so he |
| 63 | has no way of knowing that Alice has already committed her changes. |
| 64 | Or, it could be that Bob has turned off "autosync" mode in SQLite. Or, |
| 65 | maybe Bob just doesn't want to merge in Alices changes before he has |
| 66 | saved his own, so he forces the commit to occur using the "--force" option |
| 67 | to the fossil <b>commit</b> command. For whatever reason, two commits against |
| 68 | check-in 2 have occurred and now the tree has two leaves. |
| 69 | |
| 70 | So which version of the project is the "latest" in the sense of having |
| @@ -194,11 +194,11 @@ | |
| 194 | are symbolic name tags. When a symbolic name tag is attached to a |
| 195 | check-in, that allows you to refer to that check-in by its symbolic |
| 196 | name rather than by its 40-character SHA1 hash name. When a symbolic name |
| 197 | tag propagates (as does the <b>sym-trunk</b> tag) then referring to that |
| 198 | name is the same as referring to the most recent check-in with that name. |
| 199 | Thus the two tags on check-in one cause all decendents to be in the |
| 200 | "trunk" branch and to have the symbolic name "trunk". |
| 201 | |
| 202 | Check-in 4 has a <b>branch</b> tag which changes the name of the branch |
| 203 | to "test". The branch tag on check-in 4 propagates to check-ins 6 and 9. |
| 204 | But because tag propagation does not follow merge links, the <b>branch=test</b> |
| @@ -238,11 +238,11 @@ | |
| 238 | branch property.</p></dd> |
| 239 | <dt><b>Leaf</b></dt> |
| 240 | <dd><p>A leaf is a check-in that has no children in the same branch.</p></dd> |
| 241 | <dt><b>Closed Leaf</b></dt> |
| 242 | <dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves |
| 243 | are intented to never be extended with descendents and hence are omitted |
| 244 | from lists of leaves in the command-line and web interface.</p></dd> |
| 245 | <dt><b>Open Leaf</b></dt> |
| 246 | <dd><p>A open leaf is a leaf that is not closed.</p></dd> |
| 247 | <dt><b>Fork</b></dt> |
| 248 | <dd><p>A fork occurs when a check-in has two or more direct (non-merge) |
| 249 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -51,20 +51,20 @@ | |
| 51 | editing check-in 2 are named Alice and Bob. Suppose Alice finished her |
| 52 | edits first and did a commit, resulting in check-in 3. Later, when Bob |
| 53 | tried to commit his changes, fossil would try to verify that check-in 2 |
| 54 | was still a leaf. Fossil would see that check-in 3 had occurred and would |
| 55 | abort Bob's commit attempt with a message "would fork". This allows Bob |
| 56 | to do a "fossil update" which would pull in Alice's changes and merge them |
| 57 | together with his own changes. After merging, Bob could then commit |
| 58 | check-in 4 as a child of check-in 3 and the result would be a linear graph |
| 59 | as shown in figure 1. This is how CVS works. This is also how fossil |
| 60 | works in "autosync" mode. |
| 61 | |
| 62 | But it might be that Bob is off-network when he does his commit, so he |
| 63 | has no way of knowing that Alice has already committed her changes. |
| 64 | Or, it could be that Bob has turned off "autosync" mode in SQLite. Or, |
| 65 | maybe Bob just doesn't want to merge in Alice's changes before he has |
| 66 | saved his own, so he forces the commit to occur using the "--force" option |
| 67 | to the fossil <b>commit</b> command. For whatever reason, two commits against |
| 68 | check-in 2 have occurred and now the tree has two leaves. |
| 69 | |
| 70 | So which version of the project is the "latest" in the sense of having |
| @@ -194,11 +194,11 @@ | |
| 194 | are symbolic name tags. When a symbolic name tag is attached to a |
| 195 | check-in, that allows you to refer to that check-in by its symbolic |
| 196 | name rather than by its 40-character SHA1 hash name. When a symbolic name |
| 197 | tag propagates (as does the <b>sym-trunk</b> tag) then referring to that |
| 198 | name is the same as referring to the most recent check-in with that name. |
| 199 | Thus the two tags on check-in one cause all descendants to be in the |
| 200 | "trunk" branch and to have the symbolic name "trunk". |
| 201 | |
| 202 | Check-in 4 has a <b>branch</b> tag which changes the name of the branch |
| 203 | to "test". The branch tag on check-in 4 propagates to check-ins 6 and 9. |
| 204 | But because tag propagation does not follow merge links, the <b>branch=test</b> |
| @@ -238,11 +238,11 @@ | |
| 238 | branch property.</p></dd> |
| 239 | <dt><b>Leaf</b></dt> |
| 240 | <dd><p>A leaf is a check-in that has no children in the same branch.</p></dd> |
| 241 | <dt><b>Closed Leaf</b></dt> |
| 242 | <dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves |
| 243 | are intented to never be extended with descendants and hence are omitted |
| 244 | from lists of leaves in the command-line and web interface.</p></dd> |
| 245 | <dt><b>Open Leaf</b></dt> |
| 246 | <dd><p>A open leaf is a leaf that is not closed.</p></dd> |
| 247 | <dt><b>Fork</b></dt> |
| 248 | <dd><p>A fork occurs when a check-in has two or more direct (non-merge) |
| 249 |
+1
-1
| --- www/faq.wiki | ||
| +++ www/faq.wiki | ||
| @@ -70,11 +70,11 @@ | ||
| 70 | 70 | main repository.</b></p> |
| 71 | 71 | |
| 72 | 72 | <blockquote>Use the <b>--private</b> command-line option on the |
| 73 | 73 | <b>commit</b> command. The result will be a check-in which exists on |
| 74 | 74 | your local repository only and is never pushed to other repositories. |
| 75 | -All descendents of a private check-in are also private. | |
| 75 | +All descendants of a private check-in are also private. | |
| 76 | 76 | |
| 77 | 77 | Unless you specify something different using the <b>--branch</b> and/or |
| 78 | 78 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 79 | 79 | named "private" with an orange background color. |
| 80 | 80 | |
| 81 | 81 |
| --- www/faq.wiki | |
| +++ www/faq.wiki | |
| @@ -70,11 +70,11 @@ | |
| 70 | main repository.</b></p> |
| 71 | |
| 72 | <blockquote>Use the <b>--private</b> command-line option on the |
| 73 | <b>commit</b> command. The result will be a check-in which exists on |
| 74 | your local repository only and is never pushed to other repositories. |
| 75 | All descendents of a private check-in are also private. |
| 76 | |
| 77 | Unless you specify something different using the <b>--branch</b> and/or |
| 78 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 79 | named "private" with an orange background color. |
| 80 | |
| 81 |
| --- www/faq.wiki | |
| +++ www/faq.wiki | |
| @@ -70,11 +70,11 @@ | |
| 70 | main repository.</b></p> |
| 71 | |
| 72 | <blockquote>Use the <b>--private</b> command-line option on the |
| 73 | <b>commit</b> command. The result will be a check-in which exists on |
| 74 | your local repository only and is never pushed to other repositories. |
| 75 | All descendants of a private check-in are also private. |
| 76 | |
| 77 | Unless you specify something different using the <b>--branch</b> and/or |
| 78 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 79 | named "private" with an orange background color. |
| 80 | |
| 81 |
+1
-1
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -243,11 +243,11 @@ | ||
| 243 | 243 | within the repository. The basic format of a control artifact is |
| 244 | 244 | the same as a manifest or cluster. A control artifact is a text |
| 245 | 245 | files divided into cards by newline characters. Each card has a |
| 246 | 246 | single-character card type followed by arguments. Spaces separate |
| 247 | 247 | the card type and the arguments. No surplus whitespace is allowed. |
| 248 | -All cards must occur in strict lexigraphical order. | |
| 248 | +All cards must occur in strict lexicographical order. | |
| 249 | 249 | |
| 250 | 250 | Allowed cards in a control artifact are as follows: |
| 251 | 251 | |
| 252 | 252 | <blockquote> |
| 253 | 253 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 254 | 254 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -243,11 +243,11 @@ | |
| 243 | within the repository. The basic format of a control artifact is |
| 244 | the same as a manifest or cluster. A control artifact is a text |
| 245 | files divided into cards by newline characters. Each card has a |
| 246 | single-character card type followed by arguments. Spaces separate |
| 247 | the card type and the arguments. No surplus whitespace is allowed. |
| 248 | All cards must occur in strict lexigraphical order. |
| 249 | |
| 250 | Allowed cards in a control artifact are as follows: |
| 251 | |
| 252 | <blockquote> |
| 253 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 254 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -243,11 +243,11 @@ | |
| 243 | within the repository. The basic format of a control artifact is |
| 244 | the same as a manifest or cluster. A control artifact is a text |
| 245 | files divided into cards by newline characters. Each card has a |
| 246 | single-character card type followed by arguments. Spaces separate |
| 247 | the card type and the arguments. No surplus whitespace is allowed. |
| 248 | All cards must occur in strict lexicographical order. |
| 249 | |
| 250 | Allowed cards in a control artifact are as follows: |
| 251 | |
| 252 | <blockquote> |
| 253 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 254 |
+1
-1
| --- www/index.wiki | ||
| +++ www/index.wiki | ||
| @@ -112,11 +112,11 @@ | ||
| 112 | 112 | to do it using fossil. |
| 113 | 113 | * The [./selfcheck.wiki | automatic self-check] mechanism |
| 114 | 114 | helps insure project integrity. |
| 115 | 115 | * Fossil contains a [./wikitheory.wiki | built-in wiki]. |
| 116 | 116 | * There is a |
| 117 | - [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] (with publically readable | |
| 117 | + [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] (with publicly readable | |
| 118 | 118 | [http://www.mail-archive.com/[email protected] | archives] |
| 119 | 119 | available for discussing fossil issues. |
| 120 | 120 | * [./stats.wiki | Performance statistics] taken from real-world projects |
| 121 | 121 | hosted on fossil. |
| 122 | 122 | * How to [./shunning.wiki | delete content] from a fossil repository. |
| 123 | 123 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -112,11 +112,11 @@ | |
| 112 | to do it using fossil. |
| 113 | * The [./selfcheck.wiki | automatic self-check] mechanism |
| 114 | helps insure project integrity. |
| 115 | * Fossil contains a [./wikitheory.wiki | built-in wiki]. |
| 116 | * There is a |
| 117 | [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] (with publically readable |
| 118 | [http://www.mail-archive.com/[email protected] | archives] |
| 119 | available for discussing fossil issues. |
| 120 | * [./stats.wiki | Performance statistics] taken from real-world projects |
| 121 | hosted on fossil. |
| 122 | * How to [./shunning.wiki | delete content] from a fossil repository. |
| 123 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -112,11 +112,11 @@ | |
| 112 | to do it using fossil. |
| 113 | * The [./selfcheck.wiki | automatic self-check] mechanism |
| 114 | helps insure project integrity. |
| 115 | * Fossil contains a [./wikitheory.wiki | built-in wiki]. |
| 116 | * There is a |
| 117 | [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] (with publicly readable |
| 118 | [http://www.mail-archive.com/[email protected] | archives] |
| 119 | available for discussing fossil issues. |
| 120 | * [./stats.wiki | Performance statistics] taken from real-world projects |
| 121 | hosted on fossil. |
| 122 | * How to [./shunning.wiki | delete content] from a fossil repository. |
| 123 |
+3
-3
| --- www/newrepo.wiki | ||
| +++ www/newrepo.wiki | ||
| @@ -32,11 +32,11 @@ | ||
| 32 | 32 | The <tt>ui</tt> command starts up a server (with an optional <tt>-port |
| 33 | 33 | NUMBER</tt> argument) and launches a web browser pointing at the |
| 34 | 34 | fossil server. From there it takes just a few moments to configure the |
| 35 | 35 | repo. Most importantly, go to the Admin menu, then the Users link, and |
| 36 | 36 | set your account name and password, and grant your account all access |
| 37 | -priviledges. (I also like to grant Clone access to the anonymous user, | |
| 37 | +privileges. (I also like to grant Clone access to the anonymous user, | |
| 38 | 38 | but that's personal preference.) |
| 39 | 39 | |
| 40 | 40 | Once you are done, kill the fossil server (with Ctrl-C or equivalent) |
| 41 | 41 | and close the browser window. |
| 42 | 42 | |
| @@ -63,11 +63,11 @@ | ||
| 63 | 63 | information about your local repository. You can ignore it |
| 64 | 64 | for all purposes, but be sure not to accidentally remove it |
| 65 | 65 | or otherwise damage it - it belongs to fossil, not you. |
| 66 | 66 | |
| 67 | 67 | The next thing we need to do is add files to our repository. As it |
| 68 | -happens, we have a few C source files laying around, which we'll | |
| 68 | +happens, we have a few C source files lying around, which we'll | |
| 69 | 69 | simply copy into our working directory. |
| 70 | 70 | |
| 71 | 71 | <verbatim> |
| 72 | 72 | stephan@ludo:~/fossil/demo$ cp ../csnip/*.{c,h} . |
| 73 | 73 | stephan@ludo:~/fossil/demo$ ls |
| @@ -75,11 +75,11 @@ | ||
| 75 | 75 | tokenize_path.c tokenize_path.h vappendf.c vappendf.h |
| 76 | 76 | </verbatim> |
| 77 | 77 | |
| 78 | 78 | Fossil doesn't know about those files yet. Telling fossil about |
| 79 | 79 | a new file is a two-step process. First we <em>add</em> the file |
| 80 | -to the repo, then we <em>commit</em> the file. This is a familiar | |
| 80 | +to the repository, then we <em>commit</em> the file. This is a familiar | |
| 81 | 81 | process for anyone who's worked with SCM systems before: |
| 82 | 82 | |
| 83 | 83 | <verbatim> |
| 84 | 84 | stephan@ludo:~/fossil/demo$ fossil add *.{c,h} |
| 85 | 85 | stephan@ludo:~/fossil/demo$ fossil commit -m "egg" |
| 86 | 86 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | The <tt>ui</tt> command starts up a server (with an optional <tt>-port |
| 33 | NUMBER</tt> argument) and launches a web browser pointing at the |
| 34 | fossil server. From there it takes just a few moments to configure the |
| 35 | repo. Most importantly, go to the Admin menu, then the Users link, and |
| 36 | set your account name and password, and grant your account all access |
| 37 | priviledges. (I also like to grant Clone access to the anonymous user, |
| 38 | but that's personal preference.) |
| 39 | |
| 40 | Once you are done, kill the fossil server (with Ctrl-C or equivalent) |
| 41 | and close the browser window. |
| 42 | |
| @@ -63,11 +63,11 @@ | |
| 63 | information about your local repository. You can ignore it |
| 64 | for all purposes, but be sure not to accidentally remove it |
| 65 | or otherwise damage it - it belongs to fossil, not you. |
| 66 | |
| 67 | The next thing we need to do is add files to our repository. As it |
| 68 | happens, we have a few C source files laying around, which we'll |
| 69 | simply copy into our working directory. |
| 70 | |
| 71 | <verbatim> |
| 72 | stephan@ludo:~/fossil/demo$ cp ../csnip/*.{c,h} . |
| 73 | stephan@ludo:~/fossil/demo$ ls |
| @@ -75,11 +75,11 @@ | |
| 75 | tokenize_path.c tokenize_path.h vappendf.c vappendf.h |
| 76 | </verbatim> |
| 77 | |
| 78 | Fossil doesn't know about those files yet. Telling fossil about |
| 79 | a new file is a two-step process. First we <em>add</em> the file |
| 80 | to the repo, then we <em>commit</em> the file. This is a familiar |
| 81 | process for anyone who's worked with SCM systems before: |
| 82 | |
| 83 | <verbatim> |
| 84 | stephan@ludo:~/fossil/demo$ fossil add *.{c,h} |
| 85 | stephan@ludo:~/fossil/demo$ fossil commit -m "egg" |
| 86 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | The <tt>ui</tt> command starts up a server (with an optional <tt>-port |
| 33 | NUMBER</tt> argument) and launches a web browser pointing at the |
| 34 | fossil server. From there it takes just a few moments to configure the |
| 35 | repo. Most importantly, go to the Admin menu, then the Users link, and |
| 36 | set your account name and password, and grant your account all access |
| 37 | privileges. (I also like to grant Clone access to the anonymous user, |
| 38 | but that's personal preference.) |
| 39 | |
| 40 | Once you are done, kill the fossil server (with Ctrl-C or equivalent) |
| 41 | and close the browser window. |
| 42 | |
| @@ -63,11 +63,11 @@ | |
| 63 | information about your local repository. You can ignore it |
| 64 | for all purposes, but be sure not to accidentally remove it |
| 65 | or otherwise damage it - it belongs to fossil, not you. |
| 66 | |
| 67 | The next thing we need to do is add files to our repository. As it |
| 68 | happens, we have a few C source files lying around, which we'll |
| 69 | simply copy into our working directory. |
| 70 | |
| 71 | <verbatim> |
| 72 | stephan@ludo:~/fossil/demo$ cp ../csnip/*.{c,h} . |
| 73 | stephan@ludo:~/fossil/demo$ ls |
| @@ -75,11 +75,11 @@ | |
| 75 | tokenize_path.c tokenize_path.h vappendf.c vappendf.h |
| 76 | </verbatim> |
| 77 | |
| 78 | Fossil doesn't know about those files yet. Telling fossil about |
| 79 | a new file is a two-step process. First we <em>add</em> the file |
| 80 | to the repository, then we <em>commit</em> the file. This is a familiar |
| 81 | process for anyone who's worked with SCM systems before: |
| 82 | |
| 83 | <verbatim> |
| 84 | stephan@ludo:~/fossil/demo$ fossil add *.{c,h} |
| 85 | stephan@ludo:~/fossil/demo$ fossil commit -m "egg" |
| 86 |
+3
-3
| --- www/qandc.wiki | ||
| +++ www/qandc.wiki | ||
| @@ -38,11 +38,11 @@ | ||
| 38 | 38 | code while off network, then sync your changes later. With Trac, you |
| 39 | 39 | can only view and edit tickets and wiki while you are connected to |
| 40 | 40 | the server. </li> |
| 41 | 41 | <li> Fossil is lightweight and fully self-contained. It is very easy |
| 42 | 42 | to setup on a low-resource machine. Fossil does not require an |
| 43 | - administator.</li> | |
| 43 | + administrator.</li> | |
| 44 | 44 | <li> Fossil integrates code versioning into the same repository with |
| 45 | 45 | wiki and tickets. There is nothing extra to add or install. |
| 46 | 46 | Fossil is an all-in-one turnkey solution. </li> |
| 47 | 47 | </ol> |
| 48 | 48 | </blockquote> |
| @@ -70,12 +70,12 @@ | ||
| 70 | 70 | <blockquote> |
| 71 | 71 | <p>I take a pragmatic approach to software: form follows function. |
| 72 | 72 | To me, it is more important to have a reliable, fast, efficient, |
| 73 | 73 | enduring, and simple DVCS than one that looks pretty.</p> |
| 74 | 74 | |
| 75 | -<p>On the other hand, if you have patches that improve the apparance | |
| 76 | -of Fossil without seriously compromising its reliablity, performance, | |
| 75 | +<p>On the other hand, if you have patches that improve the appearance | |
| 76 | +of Fossil without seriously compromising its reliability, performance, | |
| 77 | 77 | and/or maintainability, I will be happy to accept them. Fossil is |
| 78 | 78 | self-hosting. Send email to request a password that will let |
| 79 | 79 | you push to the main fossil repository.</p> |
| 80 | 80 | </blockquote> |
| 81 | 81 | |
| 82 | 82 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -38,11 +38,11 @@ | |
| 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 | administator.</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> |
| 47 | </ol> |
| 48 | </blockquote> |
| @@ -70,12 +70,12 @@ | |
| 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, |
| 73 | enduring, and simple DVCS than one that looks pretty.</p> |
| 74 | |
| 75 | <p>On the other hand, if you have patches that improve the apparance |
| 76 | of Fossil without seriously compromising its reliablity, performance, |
| 77 | and/or maintainability, I will be happy to accept them. Fossil is |
| 78 | self-hosting. Send email to request a password that will let |
| 79 | you push to the main fossil repository.</p> |
| 80 | </blockquote> |
| 81 | |
| 82 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -38,11 +38,11 @@ | |
| 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> |
| 47 | </ol> |
| 48 | </blockquote> |
| @@ -70,12 +70,12 @@ | |
| 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, |
| 73 | enduring, and simple DVCS than one that looks pretty.</p> |
| 74 | |
| 75 | <p>On the other hand, if you have patches that improve the appearance |
| 76 | of Fossil without seriously compromising its reliability, performance, |
| 77 | and/or maintainability, I will be happy to accept them. Fossil is |
| 78 | self-hosting. Send email to request a password that will let |
| 79 | you push to the main fossil repository.</p> |
| 80 | </blockquote> |
| 81 | |
| 82 |
+1
-1
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -39,11 +39,11 @@ | ||
| 39 | 39 | |
| 40 | 40 | <blockquote> |
| 41 | 41 | <b>fossil clone http://www.fossil-scm.org/ myclone.fossil</b> |
| 42 | 42 | </blockquote> |
| 43 | 43 | |
| 44 | - <p>The new local copy of the respository is stored in a single file, | |
| 44 | + <p>The new local copy of the repository is stored in a single file, | |
| 45 | 45 | which in the example above is named "myclone.fossil". |
| 46 | 46 | You can name your repositories anything you want. The ".fossil" suffix |
| 47 | 47 | is not required.</p> |
| 48 | 48 | |
| 49 | 49 | <p>Note: If you are behind a restrictive firewall, you might need |
| 50 | 50 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -39,11 +39,11 @@ | |
| 39 | |
| 40 | <blockquote> |
| 41 | <b>fossil clone http://www.fossil-scm.org/ myclone.fossil</b> |
| 42 | </blockquote> |
| 43 | |
| 44 | <p>The new local copy of the respository is stored in a single file, |
| 45 | which in the example above is named "myclone.fossil". |
| 46 | You can name your repositories anything you want. The ".fossil" suffix |
| 47 | is not required.</p> |
| 48 | |
| 49 | <p>Note: If you are behind a restrictive firewall, you might need |
| 50 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -39,11 +39,11 @@ | |
| 39 | |
| 40 | <blockquote> |
| 41 | <b>fossil clone http://www.fossil-scm.org/ myclone.fossil</b> |
| 42 | </blockquote> |
| 43 | |
| 44 | <p>The new local copy of the repository is stored in a single file, |
| 45 | which in the example above is named "myclone.fossil". |
| 46 | You can name your repositories anything you want. The ".fossil" suffix |
| 47 | is not required.</p> |
| 48 | |
| 49 | <p>Note: If you are behind a restrictive firewall, you might need |
| 50 |
+3
-3
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -30,14 +30,14 @@ | ||
| 30 | 30 | If something goes wrong in the middle of the commit, then the transaction |
| 31 | 31 | is rolled back and the database is unchanged. |
| 32 | 32 | |
| 33 | 33 | <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> |
| 34 | 34 | |
| 35 | -The content files that comprise the global state of a fossil respository | |
| 35 | +The content files that comprise the global state of a fossil repository | |
| 36 | 36 | are stored in the repository as a tree. The leaves of the tree are |
| 37 | 37 | stored as zlib-compressed BLOBs. Interior nodes are deltas from their |
| 38 | -decendants. A lot of encoding is going on. There is | |
| 38 | +descendants. A lot of encoding is going on. There is | |
| 39 | 39 | zlib-compression which is relatively well-tested but still might |
| 40 | 40 | cause corruption if used improperly. And there is the relatively |
| 41 | 41 | new delta-encoding mechanism designed expressly for fossil. We want |
| 42 | 42 | to make sure that bugs in these encoding mechanisms do not lead to |
| 43 | 43 | loss of data. |
| @@ -64,11 +64,11 @@ | ||
| 64 | 64 | files. |
| 65 | 65 | |
| 66 | 66 | <h2>Checksum Over All Files In A Check-in</h2> |
| 67 | 67 | |
| 68 | 68 | Manifest artifacts that define a check-in have two fields (the |
| 69 | -R-card and Z-card) that record MD5 hashs of the manifest itself | |
| 69 | +R-card and Z-card) that record MD5 hashes of the manifest itself | |
| 70 | 70 | and of all other files in the manifest. Prior to any check-in |
| 71 | 71 | commit, these checksums are verified to ensure that the check-in |
| 72 | 72 | checked in agrees exactly with what is on disk. Similarly, |
| 73 | 73 | the repository checksum is verified after a checkout to make |
| 74 | 74 | sure that the entire repository was checked out correctly. |
| 75 | 75 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -30,14 +30,14 @@ | |
| 30 | If something goes wrong in the middle of the commit, then the transaction |
| 31 | is rolled back and the database is unchanged. |
| 32 | |
| 33 | <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> |
| 34 | |
| 35 | The content files that comprise the global state of a fossil respository |
| 36 | are stored in the repository as a tree. The leaves of the tree are |
| 37 | stored as zlib-compressed BLOBs. Interior nodes are deltas from their |
| 38 | decendants. A lot of encoding is going on. There is |
| 39 | zlib-compression which is relatively well-tested but still might |
| 40 | cause corruption if used improperly. And there is the relatively |
| 41 | new delta-encoding mechanism designed expressly for fossil. We want |
| 42 | to make sure that bugs in these encoding mechanisms do not lead to |
| 43 | loss of data. |
| @@ -64,11 +64,11 @@ | |
| 64 | files. |
| 65 | |
| 66 | <h2>Checksum Over All Files In A Check-in</h2> |
| 67 | |
| 68 | Manifest artifacts that define a check-in have two fields (the |
| 69 | R-card and Z-card) that record MD5 hashs of the manifest itself |
| 70 | and of all other files in the manifest. Prior to any check-in |
| 71 | commit, these checksums are verified to ensure that the check-in |
| 72 | checked in agrees exactly with what is on disk. Similarly, |
| 73 | the repository checksum is verified after a checkout to make |
| 74 | sure that the entire repository was checked out correctly. |
| 75 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -30,14 +30,14 @@ | |
| 30 | If something goes wrong in the middle of the commit, then the transaction |
| 31 | is rolled back and the database is unchanged. |
| 32 | |
| 33 | <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> |
| 34 | |
| 35 | The content files that comprise the global state of a fossil repository |
| 36 | are stored in the repository as a tree. The leaves of the tree are |
| 37 | stored as zlib-compressed BLOBs. Interior nodes are deltas from their |
| 38 | descendants. A lot of encoding is going on. There is |
| 39 | zlib-compression which is relatively well-tested but still might |
| 40 | cause corruption if used improperly. And there is the relatively |
| 41 | new delta-encoding mechanism designed expressly for fossil. We want |
| 42 | to make sure that bugs in these encoding mechanisms do not lead to |
| 43 | loss of data. |
| @@ -64,11 +64,11 @@ | |
| 64 | files. |
| 65 | |
| 66 | <h2>Checksum Over All Files In A Check-in</h2> |
| 67 | |
| 68 | Manifest artifacts that define a check-in have two fields (the |
| 69 | R-card and Z-card) that record MD5 hashes of the manifest itself |
| 70 | and of all other files in the manifest. Prior to any check-in |
| 71 | commit, these checksums are verified to ensure that the check-in |
| 72 | checked in agrees exactly with what is on disk. Similarly, |
| 73 | the repository checksum is verified after a checkout to make |
| 74 | sure that the entire repository was checked out correctly. |
| 75 |
+4
-4
| --- www/shunning.wiki | ||
| +++ www/shunning.wiki | ||
| @@ -38,13 +38,13 @@ | ||
| 38 | 38 | The shunning list is part of the local state of a Fossil repository. |
| 39 | 39 | In other words, shunning does not propagate using the normal "sync" |
| 40 | 40 | mechanism. An artifact can be |
| 41 | 41 | shunned from one repository but be allowed to exist in another. The fact that |
| 42 | 42 | the shunning list does not propagate is a security feature. If the |
| 43 | -shunning list propagated then a malecious user (or | |
| 43 | +shunning list propagated then a malicious user (or | |
| 44 | 44 | a bug in the fossil code) might introduce a shun record that would |
| 45 | -propagate through all respositories in a network and permanently | |
| 45 | +propagate through all repositories in a network and permanently | |
| 46 | 46 | destroy vital information. By refusing to propagate the shunning list, |
| 47 | 47 | Fossil insures that no remote user will ever be able to remove |
| 48 | 48 | information from your personal repositories without your permission. |
| 49 | 49 | |
| 50 | 50 | The shunning list does not propagate by the normal "sync" mechanism, |
| @@ -57,11 +57,11 @@ | ||
| 57 | 57 | The two command above will pull or push shunning lists from or to |
| 58 | 58 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 59 | 59 | end. "Admin" privilege on the remote server is required in order to |
| 60 | 60 | push a shun list. |
| 61 | 61 | |
| 62 | -Note that the shunning list remains in the respository even after the | |
| 62 | +Note that the shunning list remains in the repository even after the | |
| 63 | 63 | shunned artifact has been removed. This is to prevent the artifact |
| 64 | 64 | from being reintroduced into the repository the next time it syncs with |
| 65 | 65 | another repository that has not shunned the artifact. |
| 66 | 66 | |
| 67 | 67 | <h3>Managing the shunning list</h3> |
| @@ -70,11 +70,11 @@ | ||
| 70 | 70 | with "admin" privilege on the "/shunned" URL of the web interface to Fossil. |
| 71 | 71 | That URL is accessible under the "Admin" button on the default menu |
| 72 | 72 | bar. Items can be added to or removed from the shunning list. "Sync" |
| 73 | 73 | operations are inhibited as soon as the artifact is added to the |
| 74 | 74 | shunning list, but the content of the artifact is not actually removed |
| 75 | -from the responstory until the next time the repository is rebuilt. | |
| 75 | +from the repository until the next time the repository is rebuilt. | |
| 76 | 76 | |
| 77 | 77 | When viewing individual artifacts with the web interface, "admin" |
| 78 | 78 | users will usually see a "Shun" option in the submenu that will take |
| 79 | 79 | them directly to the shunning page and enable that artifact to be |
| 80 | 80 | shunned with a single additional mouse click. |
| 81 | 81 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -38,13 +38,13 @@ | |
| 38 | The shunning list is part of the local state of a Fossil repository. |
| 39 | In other words, shunning does not propagate using the normal "sync" |
| 40 | 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 malecious user (or |
| 44 | a bug in the fossil code) might introduce a shun record that would |
| 45 | propagate through all respositories in a network and permanently |
| 46 | destroy vital information. By refusing to propagate the shunning list, |
| 47 | Fossil insures 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 by the normal "sync" mechanism, |
| @@ -57,11 +57,11 @@ | |
| 57 | The two command above will pull or push shunning lists from or to |
| 58 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 59 | end. "Admin" privilege on the remote server is required in order to |
| 60 | push a shun list. |
| 61 | |
| 62 | Note that the shunning list remains in the respository even after the |
| 63 | shunned artifact has been removed. This is to prevent the artifact |
| 64 | from being reintroduced into the repository the next time it syncs with |
| 65 | another repository that has not shunned the artifact. |
| 66 | |
| 67 | <h3>Managing the shunning list</h3> |
| @@ -70,11 +70,11 @@ | |
| 70 | with "admin" privilege on the "/shunned" URL of the web interface to Fossil. |
| 71 | That URL is accessible under the "Admin" button on the default menu |
| 72 | bar. Items can be added to or removed from the shunning list. "Sync" |
| 73 | operations are inhibited as soon as the artifact is added to the |
| 74 | shunning list, but the content of the artifact is not actually removed |
| 75 | from the responstory until the next time the repository is rebuilt. |
| 76 | |
| 77 | When viewing individual artifacts with the web interface, "admin" |
| 78 | users will usually see a "Shun" option in the submenu that will take |
| 79 | them directly to the shunning page and enable that artifact to be |
| 80 | shunned with a single additional mouse click. |
| 81 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -38,13 +38,13 @@ | |
| 38 | The shunning list is part of the local state of a Fossil repository. |
| 39 | In other words, shunning does not propagate using the normal "sync" |
| 40 | 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 insures 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 by the normal "sync" mechanism, |
| @@ -57,11 +57,11 @@ | |
| 57 | The two command above will pull or push shunning lists from or to |
| 58 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 59 | end. "Admin" privilege on the remote server is required in order to |
| 60 | push a shun list. |
| 61 | |
| 62 | Note that the shunning list remains in the repository even after the |
| 63 | shunned artifact has been removed. This is to prevent the artifact |
| 64 | from being reintroduced into the repository the next time it syncs with |
| 65 | another repository that has not shunned the artifact. |
| 66 | |
| 67 | <h3>Managing the shunning list</h3> |
| @@ -70,11 +70,11 @@ | |
| 70 | with "admin" privilege on the "/shunned" URL of the web interface to Fossil. |
| 71 | That URL is accessible under the "Admin" button on the default menu |
| 72 | bar. Items can be added to or removed from the shunning list. "Sync" |
| 73 | operations are inhibited as soon as the artifact is added to the |
| 74 | shunning list, but the content of the artifact is not actually removed |
| 75 | from the repository until the next time the repository is rebuilt. |
| 76 | |
| 77 | When viewing individual artifacts with the web interface, "admin" |
| 78 | users will usually see a "Shun" option in the submenu that will take |
| 79 | them directly to the shunning page and enable that artifact to be |
| 80 | shunned with a single additional mouse click. |
| 81 |
+2
-2
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -26,12 +26,12 @@ | ||
| 26 | 26 | shared to a few hundred.</p> |
| 27 | 27 | |
| 28 | 28 | <p>Each repository also has local state. The local state determines |
| 29 | 29 | the web-page formatting preferences, authorized users, ticket formats, |
| 30 | 30 | and similar information that varies from one repository to another. |
| 31 | -The local state is not transfered by the <b>push</b>, <b>pull</b>, | |
| 32 | -and <b>sync</b> command, though some local state is transfered during | |
| 31 | +The local state is not transferred by the <b>push</b>, <b>pull</b>, | |
| 32 | +and <b>sync</b> command, though some local state is transferred during | |
| 33 | 33 | a <b>clone</b> in order to initialize the local state of the new |
| 34 | 34 | repository. The <b>configuration push</b> and <b>configuration pull</b> |
| 35 | 35 | commands can be used to send or receive local state.</p> |
| 36 | 36 | |
| 37 | 37 | |
| 38 | 38 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -26,12 +26,12 @@ | |
| 26 | shared to a few hundred.</p> |
| 27 | |
| 28 | <p>Each repository also has local state. The local state determines |
| 29 | the web-page formatting preferences, authorized users, ticket formats, |
| 30 | and similar information that varies from one repository to another. |
| 31 | The local state is not transfered by the <b>push</b>, <b>pull</b>, |
| 32 | and <b>sync</b> command, though some local state is transfered during |
| 33 | a <b>clone</b> in order to initialize the local state of the new |
| 34 | repository. The <b>configuration push</b> and <b>configuration pull</b> |
| 35 | commands can be used to send or receive local state.</p> |
| 36 | |
| 37 | |
| 38 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -26,12 +26,12 @@ | |
| 26 | shared to a few hundred.</p> |
| 27 | |
| 28 | <p>Each repository also has local state. The local state determines |
| 29 | the web-page formatting preferences, authorized users, ticket formats, |
| 30 | and similar information that varies from one repository to another. |
| 31 | The local state is not transferred by the <b>push</b>, <b>pull</b>, |
| 32 | and <b>sync</b> command, though some local state is transferred during |
| 33 | a <b>clone</b> in order to initialize the local state of the new |
| 34 | repository. The <b>configuration push</b> and <b>configuration pull</b> |
| 35 | commands can be used to send or receive local state.</p> |
| 36 | |
| 37 | |
| 38 |
+3
-3
| --- www/wikitheory.wiki | ||
| +++ www/wikitheory.wiki | ||
| @@ -8,11 +8,11 @@ | ||
| 8 | 8 | * [./embeddeddoc.wiki | Embedded documentation] files whose |
| 9 | 9 | name ends in "wiki". |
| 10 | 10 | |
| 11 | 11 | The [/wiki_rules | formatting rules] for fossil wiki |
| 12 | 12 | are designed to be simple and intuitive. The idea is that wiki provides |
| 13 | -paragraph breaks, numbered and bulletted lists, and hyperlinking for | |
| 13 | +paragraph breaks, numbered and bulleted lists, and hyperlinking for | |
| 14 | 14 | simple documents together with a safe subset of HTML for more complex |
| 15 | 15 | formatting tasks. |
| 16 | 16 | |
| 17 | 17 | Some commentators feel that the use of HTML is a mistake and that |
| 18 | 18 | fossil should use the markup language of the |
| @@ -55,23 +55,23 @@ | ||
| 55 | 55 | <h2>Embedded Documentation</h2> |
| 56 | 56 | |
| 57 | 57 | Files in the source tree that use the ".wiki" suffix can be accessed |
| 58 | 58 | and displayed using special URLs to the fossil server. This allows |
| 59 | 59 | project documentation to be stored in the source tree and accessed |
| 60 | -online. (Details are descripted [./embeddeddoc.wiki | separately].) | |
| 60 | +online. (Details are described [./embeddeddoc.wiki | separately].) | |
| 61 | 61 | |
| 62 | 62 | Some project prefer to store their documentation in wiki. There is nothing |
| 63 | 63 | wrong with that. But other projects prefer to keep documentation as part |
| 64 | 64 | of the source tree, so that it is versioned along with the source tree and |
| 65 | 65 | so that only developers with check-in privileges can change it. |
| 66 | 66 | Embedded documentation serves this latter purpose. Both forms of documentation |
| 67 | 67 | use the exact same wiki markup language. Some projects may choose to |
| 68 | 68 | use both forms of documentation at the same time. Because the same |
| 69 | -format is used, it is trival to move file from wiki to embedded documentation | |
| 69 | +format is used, it is trivial to move file from wiki to embedded documentation | |
| 70 | 70 | or back again as the project evolves. |
| 71 | 71 | |
| 72 | 72 | <h2>Bug-reports and check-in comments</h2> |
| 73 | 73 | |
| 74 | 74 | The comments on check-ins and the text in the descriptions of bug reports |
| 75 | 75 | both use wiki formatting. Exactly the same set of formatting rules apply. |
| 76 | 76 | There is never a need to learn one formatting language for documentation |
| 77 | 77 | and a different markup for bugs or for check-in comments. |
| 78 | 78 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -8,11 +8,11 @@ | |
| 8 | * [./embeddeddoc.wiki | Embedded documentation] files whose |
| 9 | name ends in "wiki". |
| 10 | |
| 11 | The [/wiki_rules | formatting rules] for fossil wiki |
| 12 | are designed to be simple and intuitive. The idea is that wiki provides |
| 13 | paragraph breaks, numbered and bulletted lists, and hyperlinking for |
| 14 | simple documents together with a safe subset of HTML for more complex |
| 15 | formatting tasks. |
| 16 | |
| 17 | Some commentators feel that the use of HTML is a mistake and that |
| 18 | fossil should use the markup language of the |
| @@ -55,23 +55,23 @@ | |
| 55 | <h2>Embedded Documentation</h2> |
| 56 | |
| 57 | Files in the source tree that use the ".wiki" suffix can be accessed |
| 58 | and displayed using special URLs to the fossil server. This allows |
| 59 | project documentation to be stored in the source tree and accessed |
| 60 | online. (Details are descripted [./embeddeddoc.wiki | separately].) |
| 61 | |
| 62 | Some project prefer to store their documentation in wiki. There is nothing |
| 63 | wrong with that. But other projects prefer to keep documentation as part |
| 64 | of the source tree, so that it is versioned along with the source tree and |
| 65 | so that only developers with check-in privileges can change it. |
| 66 | Embedded documentation serves this latter purpose. Both forms of documentation |
| 67 | use the exact same wiki markup language. Some projects may choose to |
| 68 | use both forms of documentation at the same time. Because the same |
| 69 | format is used, it is trival to move file from wiki to embedded documentation |
| 70 | or back again as the project evolves. |
| 71 | |
| 72 | <h2>Bug-reports and check-in comments</h2> |
| 73 | |
| 74 | The comments on check-ins and the text in the descriptions of bug reports |
| 75 | both use wiki formatting. Exactly the same set of formatting rules apply. |
| 76 | There is never a need to learn one formatting language for documentation |
| 77 | and a different markup for bugs or for check-in comments. |
| 78 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -8,11 +8,11 @@ | |
| 8 | * [./embeddeddoc.wiki | Embedded documentation] files whose |
| 9 | name ends in "wiki". |
| 10 | |
| 11 | The [/wiki_rules | formatting rules] for fossil wiki |
| 12 | are designed to be simple and intuitive. The idea is that wiki provides |
| 13 | paragraph breaks, numbered and bulleted lists, and hyperlinking for |
| 14 | simple documents together with a safe subset of HTML for more complex |
| 15 | formatting tasks. |
| 16 | |
| 17 | Some commentators feel that the use of HTML is a mistake and that |
| 18 | fossil should use the markup language of the |
| @@ -55,23 +55,23 @@ | |
| 55 | <h2>Embedded Documentation</h2> |
| 56 | |
| 57 | Files in the source tree that use the ".wiki" suffix can be accessed |
| 58 | and displayed using special URLs to the fossil server. This allows |
| 59 | project documentation to be stored in the source tree and accessed |
| 60 | online. (Details are described [./embeddeddoc.wiki | separately].) |
| 61 | |
| 62 | Some project prefer to store their documentation in wiki. There is nothing |
| 63 | wrong with that. But other projects prefer to keep documentation as part |
| 64 | of the source tree, so that it is versioned along with the source tree and |
| 65 | so that only developers with check-in privileges can change it. |
| 66 | Embedded documentation serves this latter purpose. Both forms of documentation |
| 67 | use the exact same wiki markup language. Some projects may choose to |
| 68 | use both forms of documentation at the same time. Because the same |
| 69 | format is used, it is trivial to move file from wiki to embedded documentation |
| 70 | or back again as the project evolves. |
| 71 | |
| 72 | <h2>Bug-reports and check-in comments</h2> |
| 73 | |
| 74 | The comments on check-ins and the text in the descriptions of bug reports |
| 75 | both use wiki formatting. Exactly the same set of formatting rules apply. |
| 76 | There is never a need to learn one formatting language for documentation |
| 77 | and a different markup for bugs or for check-in comments. |
| 78 |