Fossil SCM
[Grammar] concepts.wiki changes.
Commit
0ae6ba539cb3f23011f3ef449be54cda14a68fa977758ee3d0b4ea7c38982d97
Parent
42e3cf5aaf49157…
1 file changed
+4
-4
+4
-4
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -163,11 +163,11 @@ | ||
| 163 | 163 | The manifest file is not normally a real file on disk. Instead, |
| 164 | 164 | the manifest is computed in memory by Fossil whenever it needs it. |
| 165 | 165 | However, the "fossil setting manifest on" command will cause the |
| 166 | 166 | manifest file to be materialized to disk, if desired. Both Fossil |
| 167 | 167 | itself, and SQLite cause the manifest file to be materialized to disk |
| 168 | -so that the makefiles for these project can read the manifest and | |
| 168 | +so that the makefiles for these projects can read the manifest and | |
| 169 | 169 | embed version information in generated binaries. |
| 170 | 170 | |
| 171 | 171 | Fossil automatically generates a manifest whenever you "commit" |
| 172 | 172 | a new check-in. So this is not something that you, the developer, |
| 173 | 173 | need to worry with. The format of a manifest is intentionally |
| @@ -178,11 +178,11 @@ | ||
| 178 | 178 | |
| 179 | 179 | In addition to identifying all files in the check-in, a |
| 180 | 180 | manifest also contains a check-in comment, the date and time |
| 181 | 181 | when the check-in was established, who created the check-in, |
| 182 | 182 | and links to other check-ins from which the current check-in |
| 183 | -is derived. There is also a couple of checksums used to verify | |
| 183 | +is derived. There are also a couple of checksums used to verify | |
| 184 | 184 | the integrity of the check-in. And the whole manifest might |
| 185 | 185 | be PGP clearsigned. |
| 186 | 186 | |
| 187 | 187 | <h3 id="keyconc">2.3 Key concepts</h3> |
| 188 | 188 | |
| @@ -217,11 +217,11 @@ | ||
| 217 | 217 | SQLite, patch, or any similar software on your system in order to use |
| 218 | 218 | Fossil effectively. You will want to have some kind of text editor |
| 219 | 219 | for entering check-in comments. Fossil will use whatever text editor |
| 220 | 220 | is identified by your VISUAL environment variable. Fossil will also |
| 221 | 221 | use GPG to clearsign your manifests if you happen to have it installed, |
| 222 | -but Fossil will skip that step if GPG missing from your system. | |
| 222 | +but Fossil will skip that step if GPG is missing from your system. | |
| 223 | 223 | You can optionally set up Fossil to use external "diff" programs, |
| 224 | 224 | though Fossil has an excellent built-in "diff" algorithm that works |
| 225 | 225 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 226 | 226 | system, Fossil will use it to generate a graphical "diff" display when |
| 227 | 227 | you use the --tk option to the "diff" command, but this too is entirely |
| @@ -286,11 +286,11 @@ | ||
| 286 | 286 | fossil setting autosync off |
| 287 | 287 | fossil settings |
| 288 | 288 | </pre> |
| 289 | 289 | |
| 290 | 290 | By default, Fossil runs with autosync mode turned on. The |
| 291 | -authors finds that projects run more smoothly in autosync mode since | |
| 291 | +authors find that projects run more smoothly in autosync mode since | |
| 292 | 292 | autosync helps to prevent pointless forking and merging and helps keeps |
| 293 | 293 | all collaborators working on exactly the same code rather than on their |
| 294 | 294 | own personal forks of the code. In the author's view, manual-merge mode |
| 295 | 295 | should be reserved for disconnected operation. |
| 296 | 296 | |
| 297 | 297 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -163,11 +163,11 @@ | |
| 163 | The manifest file is not normally a real file on disk. Instead, |
| 164 | the manifest is computed in memory by Fossil whenever it needs it. |
| 165 | However, the "fossil setting manifest on" command will cause the |
| 166 | manifest file to be materialized to disk, if desired. Both Fossil |
| 167 | itself, and SQLite cause the manifest file to be materialized to disk |
| 168 | so that the makefiles for these project can read the manifest and |
| 169 | embed version information in generated binaries. |
| 170 | |
| 171 | Fossil automatically generates a manifest whenever you "commit" |
| 172 | a new check-in. So this is not something that you, the developer, |
| 173 | need to worry with. The format of a manifest is intentionally |
| @@ -178,11 +178,11 @@ | |
| 178 | |
| 179 | In addition to identifying all files in the check-in, a |
| 180 | manifest also contains a check-in comment, the date and time |
| 181 | when the check-in was established, who created the check-in, |
| 182 | and links to other check-ins from which the current check-in |
| 183 | is derived. There is also a couple of checksums used to verify |
| 184 | the integrity of the check-in. And the whole manifest might |
| 185 | be PGP clearsigned. |
| 186 | |
| 187 | <h3 id="keyconc">2.3 Key concepts</h3> |
| 188 | |
| @@ -217,11 +217,11 @@ | |
| 217 | SQLite, patch, or any similar software on your system in order to use |
| 218 | Fossil effectively. You will want to have some kind of text editor |
| 219 | for entering check-in comments. Fossil will use whatever text editor |
| 220 | is identified by your VISUAL environment variable. Fossil will also |
| 221 | use GPG to clearsign your manifests if you happen to have it installed, |
| 222 | but Fossil will skip that step if GPG missing from your system. |
| 223 | You can optionally set up Fossil to use external "diff" programs, |
| 224 | though Fossil has an excellent built-in "diff" algorithm that works |
| 225 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 226 | system, Fossil will use it to generate a graphical "diff" display when |
| 227 | you use the --tk option to the "diff" command, but this too is entirely |
| @@ -286,11 +286,11 @@ | |
| 286 | fossil setting autosync off |
| 287 | fossil settings |
| 288 | </pre> |
| 289 | |
| 290 | By default, Fossil runs with autosync mode turned on. The |
| 291 | authors finds that projects run more smoothly in autosync mode since |
| 292 | autosync helps to prevent pointless forking and merging and helps keeps |
| 293 | all collaborators working on exactly the same code rather than on their |
| 294 | own personal forks of the code. In the author's view, manual-merge mode |
| 295 | should be reserved for disconnected operation. |
| 296 | |
| 297 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -163,11 +163,11 @@ | |
| 163 | The manifest file is not normally a real file on disk. Instead, |
| 164 | the manifest is computed in memory by Fossil whenever it needs it. |
| 165 | However, the "fossil setting manifest on" command will cause the |
| 166 | manifest file to be materialized to disk, if desired. Both Fossil |
| 167 | itself, and SQLite cause the manifest file to be materialized to disk |
| 168 | so that the makefiles for these projects can read the manifest and |
| 169 | embed version information in generated binaries. |
| 170 | |
| 171 | Fossil automatically generates a manifest whenever you "commit" |
| 172 | a new check-in. So this is not something that you, the developer, |
| 173 | need to worry with. The format of a manifest is intentionally |
| @@ -178,11 +178,11 @@ | |
| 178 | |
| 179 | In addition to identifying all files in the check-in, a |
| 180 | manifest also contains a check-in comment, the date and time |
| 181 | when the check-in was established, who created the check-in, |
| 182 | and links to other check-ins from which the current check-in |
| 183 | is derived. There are also a couple of checksums used to verify |
| 184 | the integrity of the check-in. And the whole manifest might |
| 185 | be PGP clearsigned. |
| 186 | |
| 187 | <h3 id="keyconc">2.3 Key concepts</h3> |
| 188 | |
| @@ -217,11 +217,11 @@ | |
| 217 | SQLite, patch, or any similar software on your system in order to use |
| 218 | Fossil effectively. You will want to have some kind of text editor |
| 219 | for entering check-in comments. Fossil will use whatever text editor |
| 220 | is identified by your VISUAL environment variable. Fossil will also |
| 221 | use GPG to clearsign your manifests if you happen to have it installed, |
| 222 | but Fossil will skip that step if GPG is missing from your system. |
| 223 | You can optionally set up Fossil to use external "diff" programs, |
| 224 | though Fossil has an excellent built-in "diff" algorithm that works |
| 225 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 226 | system, Fossil will use it to generate a graphical "diff" display when |
| 227 | you use the --tk option to the "diff" command, but this too is entirely |
| @@ -286,11 +286,11 @@ | |
| 286 | fossil setting autosync off |
| 287 | fossil settings |
| 288 | </pre> |
| 289 | |
| 290 | By default, Fossil runs with autosync mode turned on. The |
| 291 | authors find that projects run more smoothly in autosync mode since |
| 292 | autosync helps to prevent pointless forking and merging and helps keeps |
| 293 | all collaborators working on exactly the same code rather than on their |
| 294 | own personal forks of the code. In the author's view, manual-merge mode |
| 295 | should be reserved for disconnected operation. |
| 296 | |
| 297 |