Fossil SCM
Fix typos in the whyusefossil.wiki document.
Commit
1335cf4135f5c6ead1fec823be69bf2dd6e20a79
Parent
8ac01fa676db045…
1 file changed
+5
-5
+5
-5
| --- www/whyusefossil.wiki | ||
| +++ www/whyusefossil.wiki | ||
| @@ -49,13 +49,13 @@ | ||
| 49 | 49 | manuals in which each chapter or section is held in a separate file. |
| 50 | 50 | <ul> |
| 51 | 51 | <li><p>Projects change and evolve. The whole purpose of version |
| 52 | 52 | control is to track and manage that evolution. |
| 53 | 53 | <li><p>Most projects consist of multiple files, but it is possible |
| 54 | - have a project consisting of just a single file. | |
| 54 | + to have a project consisting of just a single file. | |
| 55 | 55 | <li><p>Fossil (and most other version control systems) requires that |
| 56 | - all the files for a project be collected into a single | |
| 56 | + all the files for a project must be collected into a single | |
| 57 | 57 | directory hierarchy - a single folder possibly with layers |
| 58 | 58 | of subfolders. Fossil is not a good choice for managing a |
| 59 | 59 | project that has files scattered hither and yon all over |
| 60 | 60 | the disk. In other words, Fossil only works for projects |
| 61 | 61 | where the files are laid out such that they can be archived |
| @@ -85,15 +85,15 @@ | ||
| 85 | 85 | ok to have multiple copies of the same repository on the same |
| 86 | 86 | computer. |
| 87 | 87 | <li><p>Fossil works fine with just a single copy of the repository. |
| 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 | - to recovery the project. | |
| 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 | 93 | are recommended. Fossil itself does not care where the repositories |
| 94 | - are stored. Nor does Fossil require that repositories all be | |
| 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 | 98 | <li><p><b>Check-out</b> → |
| 99 | 99 | a set of files that have been extracted from a |
| @@ -168,11 +168,11 @@ | ||
| 168 | 168 | the "update" command will (often) automatically do a "pull" before |
| 169 | 169 | attempting to update the local check-out. |
| 170 | 170 | <li><p><b>sync</b> → |
| 171 | 171 | Do both a "push" and a "pull" at the same time. |
| 172 | 172 | <li><p><b>add</b> → |
| 173 | - Add a new file to the local check-out. The file must already | |
| 173 | + Add a new file to the local check-out. The file must already be | |
| 174 | 174 | on disk. This command tells Fossil to start tracking and managing |
| 175 | 175 | the file. This command affects only the local check-out and does |
| 176 | 176 | not modify any repository. The new file is inserted into the |
| 177 | 177 | repository at the next "commit" command. |
| 178 | 178 | <li><p><b>rm/mv</b> → |
| 179 | 179 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -49,13 +49,13 @@ | |
| 49 | manuals in which each chapter or section is held in a separate file. |
| 50 | <ul> |
| 51 | <li><p>Projects change and evolve. The whole purpose of version |
| 52 | control is to track and manage that evolution. |
| 53 | <li><p>Most projects consist of multiple files, but it is possible |
| 54 | have a project consisting of just a single file. |
| 55 | <li><p>Fossil (and most other version control systems) requires that |
| 56 | all the files for a project be collected into a single |
| 57 | directory hierarchy - a single folder possibly with layers |
| 58 | of subfolders. Fossil is not a good choice for managing a |
| 59 | project that has files scattered hither and yon all over |
| 60 | the disk. In other words, Fossil only works for projects |
| 61 | where the files are laid out such that they can be archived |
| @@ -85,15 +85,15 @@ | |
| 85 | ok to have multiple copies of the same repository on the same |
| 86 | computer. |
| 87 | <li><p>Fossil works fine with just a single copy of the repository. |
| 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 recovery 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 that repositories all 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 |
| @@ -168,11 +168,11 @@ | |
| 168 | the "update" command will (often) automatically do a "pull" before |
| 169 | attempting to update the local check-out. |
| 170 | <li><p><b>sync</b> → |
| 171 | Do both a "push" and a "pull" at the same time. |
| 172 | <li><p><b>add</b> → |
| 173 | Add a new file to the local check-out. The file must already |
| 174 | on disk. This command tells Fossil to start tracking and managing |
| 175 | the file. This command affects only the local check-out and does |
| 176 | not modify any repository. The new file is inserted into the |
| 177 | repository at the next "commit" command. |
| 178 | <li><p><b>rm/mv</b> → |
| 179 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -49,13 +49,13 @@ | |
| 49 | manuals in which each chapter or section is held in a separate file. |
| 50 | <ul> |
| 51 | <li><p>Projects change and evolve. The whole purpose of version |
| 52 | control is to track and manage that evolution. |
| 53 | <li><p>Most projects consist of multiple files, but it is possible |
| 54 | to have a project consisting of just a single file. |
| 55 | <li><p>Fossil (and most other version control systems) requires that |
| 56 | all the files for a project must be collected into a single |
| 57 | directory hierarchy - a single folder possibly with layers |
| 58 | of subfolders. Fossil is not a good choice for managing a |
| 59 | project that has files scattered hither and yon all over |
| 60 | the disk. In other words, Fossil only works for projects |
| 61 | where the files are laid out such that they can be archived |
| @@ -85,15 +85,15 @@ | |
| 85 | ok to have multiple copies of the same repository on the same |
| 86 | computer. |
| 87 | <li><p>Fossil works fine with just a single copy of the repository. |
| 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 |
| @@ -168,11 +168,11 @@ | |
| 168 | the "update" command will (often) automatically do a "pull" before |
| 169 | attempting to update the local check-out. |
| 170 | <li><p><b>sync</b> → |
| 171 | Do both a "push" and a "pull" at the same time. |
| 172 | <li><p><b>add</b> → |
| 173 | Add a new file to the local check-out. The file must already be |
| 174 | on disk. This command tells Fossil to start tracking and managing |
| 175 | the file. This command affects only the local check-out and does |
| 176 | not modify any repository. The new file is inserted into the |
| 177 | repository at the next "commit" command. |
| 178 | <li><p><b>rm/mv</b> → |
| 179 |