Fossil SCM
Re-fix several typos.
Commit
6e1072c5b567f3639860a0cf5cec41ccd527d5cc
Parent
f2ce2e41d573169…
1 file changed
+5
-5
+5
-5
| --- www/whyusefossil.wiki | ||
| +++ www/whyusefossil.wiki | ||
| @@ -34,11 +34,11 @@ | ||
| 34 | 34 | <li><p><b>Automatic replication and backup</b> |
| 35 | 35 | <ol type='i'> |
| 36 | 36 | <li>Everyone always has the latest code |
| 37 | 37 | <li>Failed disk-drives cause no loss of work |
| 38 | 38 | <li>Avoid wasting time doing manual file copying |
| 39 | - <li>Avoid human errors during manual backups. | |
| 39 | + <li>Avoid human errors during manual backups | |
| 40 | 40 | </ol> |
| 41 | 41 | </ol> |
| 42 | 42 | <li><p><b>Definitions</b></p> |
| 43 | 43 | <ul> |
| 44 | 44 | <li><p><b>Project</b> → |
| @@ -88,16 +88,16 @@ | ||
| 88 | 88 | But in that case there is no redundancy. If that one repository |
| 89 | 89 | file is lost due to a hardware malfunction, then there is no way |
| 90 | 90 | to recover the project. |
| 91 | 91 | <li><p>Best practice is to keep all repositories for a user in a single |
| 92 | 92 | folder. Folders such as "~/Fossils" or "%USERPROFILE%\Fossils" |
| 93 | - are recommanded. Fossil itself does not care where the repositories | |
| 93 | + are recommended. Fossil itself does not care where the repositories | |
| 94 | 94 | are stored. Nor does Fossil require repositories to be |
| 95 | 95 | kept in the same folder. But it is easier to organize your work |
| 96 | 96 | if all repositories are kept in the same place. |
| 97 | 97 | </ul> |
| 98 | - <li><p><b>Checkout</b> → | |
| 98 | + <li><p><b>Check-out</b> → | |
| 99 | 99 | a set of files that have been extracted from a |
| 100 | 100 | repository and that represent a particular version or snapshot of |
| 101 | 101 | the project. |
| 102 | 102 | <ul> |
| 103 | 103 | <li><p>Check-outs must be on the same computer as the repository from |
| @@ -118,11 +118,11 @@ | ||
| 118 | 118 | </ul> |
| 119 | 119 | <li><p><b>Check-in</b> → |
| 120 | 120 | another name for a particular version of the project. |
| 121 | 121 | A check-in is a collection of files inside of a repository that |
| 122 | 122 | represent a snapshot of the project for an instant in time. |
| 123 | - Check-ins exist only inside of the repository. This constrasts with | |
| 123 | + Check-ins exist only inside of the repository. This contrasts with | |
| 124 | 124 | a check-out which is a collection of files outside of the repository. |
| 125 | 125 | <ul> |
| 126 | 126 | <li><p>Every check-out knows the check-in from which it was derived. |
| 127 | 127 | But check-outs might have been edited and so might not exactly |
| 128 | 128 | match their associated check-in. |
| @@ -242,11 +242,11 @@ | ||
| 242 | 242 | and easily merge their changes together. External revisions to |
| 243 | 243 | the baseline can be easily incorporated into the latest changes. |
| 244 | 244 | <li><p>Developers can follow experimental lines of development, then |
| 245 | 245 | revert back to an earlier stable version if the experiment does |
| 246 | 246 | not work out. Creativity is enhanced by allowing crazy ideas to |
| 247 | - be investigated without destablizing the project. | |
| 247 | + be investigated without destabilizing the project. | |
| 248 | 248 | <li><p>Developers can work on several independent subprojects, flipping |
| 249 | 249 | back and forth from one subproject to another at will, and merge |
| 250 | 250 | patches together or back into the main line of development as they |
| 251 | 251 | mature. |
| 252 | 252 | <li><p>Older changes can be easily backed out of recent revisions, for |
| 253 | 253 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -34,11 +34,11 @@ | |
| 34 | <li><p><b>Automatic replication and backup</b> |
| 35 | <ol type='i'> |
| 36 | <li>Everyone always has the latest code |
| 37 | <li>Failed disk-drives cause no loss of work |
| 38 | <li>Avoid wasting time doing manual file copying |
| 39 | <li>Avoid human errors during manual backups. |
| 40 | </ol> |
| 41 | </ol> |
| 42 | <li><p><b>Definitions</b></p> |
| 43 | <ul> |
| 44 | <li><p><b>Project</b> → |
| @@ -88,16 +88,16 @@ | |
| 88 | But in that case there is no redundancy. If that one repository |
| 89 | file is lost due to a hardware malfunction, then there is no way |
| 90 | to recover the project. |
| 91 | <li><p>Best practice is to keep all repositories for a user in a single |
| 92 | folder. Folders such as "~/Fossils" or "%USERPROFILE%\Fossils" |
| 93 | are recommanded. Fossil itself does not care where the repositories |
| 94 | are stored. Nor does Fossil require repositories to be |
| 95 | kept in the same folder. But it is easier to organize your work |
| 96 | if all repositories are kept in the same place. |
| 97 | </ul> |
| 98 | <li><p><b>Checkout</b> → |
| 99 | a set of files that have been extracted from a |
| 100 | repository and that represent a particular version or snapshot of |
| 101 | the project. |
| 102 | <ul> |
| 103 | <li><p>Check-outs must be on the same computer as the repository from |
| @@ -118,11 +118,11 @@ | |
| 118 | </ul> |
| 119 | <li><p><b>Check-in</b> → |
| 120 | another name for a particular version of the project. |
| 121 | A check-in is a collection of files inside of a repository that |
| 122 | represent a snapshot of the project for an instant in time. |
| 123 | Check-ins exist only inside of the repository. This constrasts with |
| 124 | a check-out which is a collection of files outside of the repository. |
| 125 | <ul> |
| 126 | <li><p>Every check-out knows the check-in from which it was derived. |
| 127 | But check-outs might have been edited and so might not exactly |
| 128 | match their associated check-in. |
| @@ -242,11 +242,11 @@ | |
| 242 | and easily merge their changes together. External revisions to |
| 243 | the baseline can be easily incorporated into the latest changes. |
| 244 | <li><p>Developers can follow experimental lines of development, then |
| 245 | revert back to an earlier stable version if the experiment does |
| 246 | not work out. Creativity is enhanced by allowing crazy ideas to |
| 247 | be investigated without destablizing the project. |
| 248 | <li><p>Developers can work on several independent subprojects, flipping |
| 249 | back and forth from one subproject to another at will, and merge |
| 250 | patches together or back into the main line of development as they |
| 251 | mature. |
| 252 | <li><p>Older changes can be easily backed out of recent revisions, for |
| 253 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -34,11 +34,11 @@ | |
| 34 | <li><p><b>Automatic replication and backup</b> |
| 35 | <ol type='i'> |
| 36 | <li>Everyone always has the latest code |
| 37 | <li>Failed disk-drives cause no loss of work |
| 38 | <li>Avoid wasting time doing manual file copying |
| 39 | <li>Avoid human errors during manual backups |
| 40 | </ol> |
| 41 | </ol> |
| 42 | <li><p><b>Definitions</b></p> |
| 43 | <ul> |
| 44 | <li><p><b>Project</b> → |
| @@ -88,16 +88,16 @@ | |
| 88 | But in that case there is no redundancy. If that one repository |
| 89 | file is lost due to a hardware malfunction, then there is no way |
| 90 | to recover the project. |
| 91 | <li><p>Best practice is to keep all repositories for a user in a single |
| 92 | folder. Folders such as "~/Fossils" or "%USERPROFILE%\Fossils" |
| 93 | are recommended. Fossil itself does not care where the repositories |
| 94 | are stored. Nor does Fossil require repositories to be |
| 95 | kept in the same folder. But it is easier to organize your work |
| 96 | if all repositories are kept in the same place. |
| 97 | </ul> |
| 98 | <li><p><b>Check-out</b> → |
| 99 | a set of files that have been extracted from a |
| 100 | repository and that represent a particular version or snapshot of |
| 101 | the project. |
| 102 | <ul> |
| 103 | <li><p>Check-outs must be on the same computer as the repository from |
| @@ -118,11 +118,11 @@ | |
| 118 | </ul> |
| 119 | <li><p><b>Check-in</b> → |
| 120 | another name for a particular version of the project. |
| 121 | A check-in is a collection of files inside of a repository that |
| 122 | represent a snapshot of the project for an instant in time. |
| 123 | Check-ins exist only inside of the repository. This contrasts with |
| 124 | a check-out which is a collection of files outside of the repository. |
| 125 | <ul> |
| 126 | <li><p>Every check-out knows the check-in from which it was derived. |
| 127 | But check-outs might have been edited and so might not exactly |
| 128 | match their associated check-in. |
| @@ -242,11 +242,11 @@ | |
| 242 | and easily merge their changes together. External revisions to |
| 243 | the baseline can be easily incorporated into the latest changes. |
| 244 | <li><p>Developers can follow experimental lines of development, then |
| 245 | revert back to an earlier stable version if the experiment does |
| 246 | not work out. Creativity is enhanced by allowing crazy ideas to |
| 247 | be investigated without destabilizing the project. |
| 248 | <li><p>Developers can work on several independent subprojects, flipping |
| 249 | back and forth from one subproject to another at will, and merge |
| 250 | patches together or back into the main line of development as they |
| 251 | mature. |
| 252 | <li><p>Older changes can be easily backed out of recent revisions, for |
| 253 |