Fossil SCM
Fix a couple typos.
Commit
680f3c1d08394418cb80cd29fa78cb74f29ce3a0
Parent
d8b18eb9afd248e…
1 file changed
+9
-9
+9
-9
| --- www/whyusefossil.wiki | ||
| +++ www/whyusefossil.wiki | ||
| @@ -64,11 +64,11 @@ | ||
| 64 | 64 | <li><p><b>Repository</b> |
| 65 | 65 | (also called "repo") → a single file that contains |
| 66 | 66 | all historical versions of all files in a project. A repo is similar |
| 67 | 67 | to a ZIP archive in that it is a single file that stores compressed |
| 68 | 68 | versions of many other files. Files can be extracted from the |
| 69 | - repo and new files can be added to the repo, just as with a ZIP | |
| 69 | + repo and new files can be added to the repo, just as with a ZIP | |
| 70 | 70 | archive. But a repo has other capabilities above and beyond |
| 71 | 71 | what a ZIP archive can do. |
| 72 | 72 | <ul> |
| 73 | 73 | <li><p>Fossil does not care what you name your repository files, |
| 74 | 74 | though names ending with ".fossil" are recommended. |
| @@ -82,17 +82,17 @@ | ||
| 82 | 82 | <li><p>The usual arrangement is one repository per user. And since |
| 83 | 83 | most users these days have their own computer, that means one |
| 84 | 84 | repository per computer. But this is not a requirement. It is |
| 85 | 85 | ok to have multiple copies of the same repository on the same |
| 86 | 86 | computer. |
| 87 | - <li><p>Fossil works fine with just a single copy of the repository. | |
| 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 | 90 | to recovery 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 that repositories all 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>Checkout</b> → |
| @@ -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. |
| @@ -172,11 +172,11 @@ | ||
| 172 | 172 | <li><p><b>add</b> → |
| 173 | 173 | Add a new file to the local check-out. The file must already |
| 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 | - repository at the next "commit" command. | |
| 177 | + repository at the next "commit" command. | |
| 178 | 178 | <li><p><b>rm/mv</b> → |
| 179 | 179 | Short for 'remove' and 'move', these commands are like "add" |
| 180 | 180 | in that they specify pending changes to the structure of the check-out. |
| 181 | 181 | As with "add", no changes are made to the repository until the next |
| 182 | 182 | "commit". |
| @@ -192,12 +192,12 @@ | ||
| 192 | 192 | an arc in the graph from node X to node Y. |
| 193 | 193 | <li><p>The older check-in (X) is call the "parent" and the newer |
| 194 | 194 | check-in (Y) is the "child". The child is derived from |
| 195 | 195 | the parent. |
| 196 | 196 | </ul> |
| 197 | - <li><p>Two users (or the same user working in different check-outs) | |
| 198 | - might commit different changes against the same check-in. This | |
| 197 | + <li><p>Two users (or the same user working in different check-outs) | |
| 198 | + might commit different changes against the same check-in. This | |
| 199 | 199 | results in one parent node having two or more children. |
| 200 | 200 | <li><p>Command: <b>merge</b> → |
| 201 | 201 | combines the work of multiple check-ins into |
| 202 | 202 | a single check-out. That check-out can then be committed to create |
| 203 | 203 | a new that has two (or more) parents. |
| @@ -242,20 +242,20 @@ | ||
| 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 | example if bugs are found long after the code was committed. |
| 254 | 254 | <li><p>Enhancements in a branch can be easily copied into other branches, |
| 255 | 255 | or into the trunk. |
| 256 | - <li><p>The complete history of all changes is plainly visible to | |
| 256 | + <li><p>The complete history of all changes is plainly visible to | |
| 257 | 257 | all team members. Project leaders can easily keep track of what |
| 258 | 258 | all team members are doing. Check-in comments help everyone to |
| 259 | 259 | understand and/or remember the reason for each change. |
| 260 | 260 | <li><p>New team members can be brought up-to-date with all of the historical |
| 261 | 261 | code, quickly and easily. |
| 262 | 262 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -64,11 +64,11 @@ | |
| 64 | <li><p><b>Repository</b> |
| 65 | (also called "repo") → a single file that contains |
| 66 | all historical versions of all files in a project. A repo is similar |
| 67 | to a ZIP archive in that it is a single file that stores compressed |
| 68 | versions of many other files. Files can be extracted from the |
| 69 | repo and new files can be added to the repo, just as with a ZIP |
| 70 | archive. But a repo has other capabilities above and beyond |
| 71 | what a ZIP archive can do. |
| 72 | <ul> |
| 73 | <li><p>Fossil does not care what you name your repository files, |
| 74 | though names ending with ".fossil" are recommended. |
| @@ -82,17 +82,17 @@ | |
| 82 | <li><p>The usual arrangement is one repository per user. And since |
| 83 | most users these days have their own computer, that means one |
| 84 | repository per computer. But this is not a requirement. It is |
| 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 recommanded. 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>Checkout</b> → |
| @@ -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. |
| @@ -172,11 +172,11 @@ | |
| 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 | Short for 'remove' and 'move', these commands are like "add" |
| 180 | in that they specify pending changes to the structure of the check-out. |
| 181 | As with "add", no changes are made to the repository until the next |
| 182 | "commit". |
| @@ -192,12 +192,12 @@ | |
| 192 | an arc in the graph from node X to node Y. |
| 193 | <li><p>The older check-in (X) is call the "parent" and the newer |
| 194 | check-in (Y) is the "child". The child is derived from |
| 195 | the parent. |
| 196 | </ul> |
| 197 | <li><p>Two users (or the same user working in different check-outs) |
| 198 | might commit different changes against the same check-in. This |
| 199 | results in one parent node having two or more children. |
| 200 | <li><p>Command: <b>merge</b> → |
| 201 | combines the work of multiple check-ins into |
| 202 | a single check-out. That check-out can then be committed to create |
| 203 | a new that has two (or more) parents. |
| @@ -242,20 +242,20 @@ | |
| 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 | example if bugs are found long after the code was committed. |
| 254 | <li><p>Enhancements in a branch can be easily copied into other branches, |
| 255 | or into the trunk. |
| 256 | <li><p>The complete history of all changes is plainly visible to |
| 257 | all team members. Project leaders can easily keep track of what |
| 258 | all team members are doing. Check-in comments help everyone to |
| 259 | understand and/or remember the reason for each change. |
| 260 | <li><p>New team members can be brought up-to-date with all of the historical |
| 261 | code, quickly and easily. |
| 262 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -64,11 +64,11 @@ | |
| 64 | <li><p><b>Repository</b> |
| 65 | (also called "repo") → a single file that contains |
| 66 | all historical versions of all files in a project. A repo is similar |
| 67 | to a ZIP archive in that it is a single file that stores compressed |
| 68 | versions of many other files. Files can be extracted from the |
| 69 | repo and new files can be added to the repo, just as with a ZIP |
| 70 | archive. But a repo has other capabilities above and beyond |
| 71 | what a ZIP archive can do. |
| 72 | <ul> |
| 73 | <li><p>Fossil does not care what you name your repository files, |
| 74 | though names ending with ".fossil" are recommended. |
| @@ -82,17 +82,17 @@ | |
| 82 | <li><p>The usual arrangement is one repository per user. And since |
| 83 | most users these days have their own computer, that means one |
| 84 | repository per computer. But this is not a requirement. It is |
| 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>Checkout</b> → |
| @@ -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. |
| @@ -172,11 +172,11 @@ | |
| 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 | Short for 'remove' and 'move', these commands are like "add" |
| 180 | in that they specify pending changes to the structure of the check-out. |
| 181 | As with "add", no changes are made to the repository until the next |
| 182 | "commit". |
| @@ -192,12 +192,12 @@ | |
| 192 | an arc in the graph from node X to node Y. |
| 193 | <li><p>The older check-in (X) is call the "parent" and the newer |
| 194 | check-in (Y) is the "child". The child is derived from |
| 195 | the parent. |
| 196 | </ul> |
| 197 | <li><p>Two users (or the same user working in different check-outs) |
| 198 | might commit different changes against the same check-in. This |
| 199 | results in one parent node having two or more children. |
| 200 | <li><p>Command: <b>merge</b> → |
| 201 | combines the work of multiple check-ins into |
| 202 | a single check-out. That check-out can then be committed to create |
| 203 | a new that has two (or more) parents. |
| @@ -242,20 +242,20 @@ | |
| 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 | example if bugs are found long after the code was committed. |
| 254 | <li><p>Enhancements in a branch can be easily copied into other branches, |
| 255 | or into the trunk. |
| 256 | <li><p>The complete history of all changes is plainly visible to |
| 257 | all team members. Project leaders can easily keep track of what |
| 258 | all team members are doing. Check-in comments help everyone to |
| 259 | understand and/or remember the reason for each change. |
| 260 | <li><p>New team members can be brought up-to-date with all of the historical |
| 261 | code, quickly and easily. |
| 262 |