Fossil SCM
Change "baseline" to "check-in" in the on-line documentation.
Commit
904ee40b938df48e574959815b2f331bb99acbbb
Parent
e8d3e327f1432a0…
12 files changed
-1
+2
-2
+1
-1
+29
-29
+5
-5
+13
-13
+1
-2
+3
-3
+1
-1
+22
-22
+3
-3
+2
-2
M
src/db.c
-1
| --- src/db.c | ||
| +++ src/db.c | ||
| @@ -975,11 +975,10 @@ | ||
| 975 | 975 | db_end_transaction(0); |
| 976 | 976 | printf("project-id: %s\n", db_get("project-code", 0)); |
| 977 | 977 | printf("server-id: %s\n", db_get("server-code", 0)); |
| 978 | 978 | zPassword = db_text(0, "SELECT pw FROM user WHERE login=%Q", g.zLogin); |
| 979 | 979 | printf("admin-user: %s (initial password is \"%s\")\n", g.zLogin, zPassword); |
| 980 | - printf("baseline: %s\n", db_text(0, "SELECT uuid FROM blob")); | |
| 981 | 980 | } |
| 982 | 981 | |
| 983 | 982 | /* |
| 984 | 983 | ** SQL functions for debugging. |
| 985 | 984 | ** |
| 986 | 985 |
| --- src/db.c | |
| +++ src/db.c | |
| @@ -975,11 +975,10 @@ | |
| 975 | db_end_transaction(0); |
| 976 | printf("project-id: %s\n", db_get("project-code", 0)); |
| 977 | printf("server-id: %s\n", db_get("server-code", 0)); |
| 978 | zPassword = db_text(0, "SELECT pw FROM user WHERE login=%Q", g.zLogin); |
| 979 | printf("admin-user: %s (initial password is \"%s\")\n", g.zLogin, zPassword); |
| 980 | printf("baseline: %s\n", db_text(0, "SELECT uuid FROM blob")); |
| 981 | } |
| 982 | |
| 983 | /* |
| 984 | ** SQL functions for debugging. |
| 985 | ** |
| 986 |
| --- src/db.c | |
| +++ src/db.c | |
| @@ -975,11 +975,10 @@ | |
| 975 | db_end_transaction(0); |
| 976 | printf("project-id: %s\n", db_get("project-code", 0)); |
| 977 | printf("server-id: %s\n", db_get("server-code", 0)); |
| 978 | zPassword = db_text(0, "SELECT pw FROM user WHERE login=%Q", g.zLogin); |
| 979 | printf("admin-user: %s (initial password is \"%s\")\n", g.zLogin, zPassword); |
| 980 | } |
| 981 | |
| 982 | /* |
| 983 | ** SQL functions for debugging. |
| 984 | ** |
| 985 |
+2
-2
| --- www/bugtheory.wiki | ||
| +++ www/bugtheory.wiki | ||
| @@ -1,16 +1,16 @@ | ||
| 1 | 1 | <h1>Bug-Tracking In <a href="index.wiki">Fossil</a></h1> |
| 2 | 2 | |
| 3 | 3 | A bug-report in fossil is called a "ticket". Tickets are tracked |
| 4 | -separately from code check-ins (baselines). | |
| 4 | +separately from code check-ins. | |
| 5 | 5 | |
| 6 | 6 | Some other distributed bug-tracking systems store tickets as files within |
| 7 | 7 | the source tree and thereby leverage the syncing and merging capabilities |
| 8 | 8 | of the versioning system to sync and merge tickets. This approach is |
| 9 | 9 | rejected in fossil for three reasons: |
| 10 | 10 | |
| 11 | - 1. Check-ins (a.k.a. "baselines") in fossil are immutable. So if | |
| 11 | + 1. Check-ins in fossil are immutable. So if | |
| 12 | 12 | tickets were part of the check-in, then there would be no way to add |
| 13 | 13 | new tickets to a check-in as new bugs are discovered. |
| 14 | 14 | |
| 15 | 15 | 2. Any project of reasonable size and complexity will generate thousands |
| 16 | 16 | and thousands of tickets, and we do not want all those ticket files |
| 17 | 17 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -1,16 +1,16 @@ | |
| 1 | <h1>Bug-Tracking In <a href="index.wiki">Fossil</a></h1> |
| 2 | |
| 3 | A bug-report in fossil is called a "ticket". Tickets are tracked |
| 4 | separately from code check-ins (baselines). |
| 5 | |
| 6 | Some other distributed bug-tracking systems store tickets as files within |
| 7 | the source tree and thereby leverage the syncing and merging capabilities |
| 8 | of the versioning system to sync and merge tickets. This approach is |
| 9 | rejected in fossil for three reasons: |
| 10 | |
| 11 | 1. Check-ins (a.k.a. "baselines") in fossil are immutable. So if |
| 12 | tickets were part of the check-in, then there would be no way to add |
| 13 | new tickets to a check-in as new bugs are discovered. |
| 14 | |
| 15 | 2. Any project of reasonable size and complexity will generate thousands |
| 16 | and thousands of tickets, and we do not want all those ticket files |
| 17 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -1,16 +1,16 @@ | |
| 1 | <h1>Bug-Tracking In <a href="index.wiki">Fossil</a></h1> |
| 2 | |
| 3 | A bug-report in fossil is called a "ticket". Tickets are tracked |
| 4 | separately from code check-ins. |
| 5 | |
| 6 | Some other distributed bug-tracking systems store tickets as files within |
| 7 | the source tree and thereby leverage the syncing and merging capabilities |
| 8 | of the versioning system to sync and merge tickets. This approach is |
| 9 | rejected in fossil for three reasons: |
| 10 | |
| 11 | 1. Check-ins in fossil are immutable. So if |
| 12 | tickets were part of the check-in, then there would be no way to add |
| 13 | new tickets to a check-in as new bugs are discovered. |
| 14 | |
| 15 | 2. Any project of reasonable size and complexity will generate thousands |
| 16 | and thousands of tickets, and we do not want all those ticket files |
| 17 |
+1
-1
| --- www/cmd_checkout.wiki | ||
| +++ www/cmd_checkout.wiki | ||
| @@ -32,11 +32,11 @@ | ||
| 32 | 32 | |
| 33 | 33 | Since a version is required, and <b>fossil</b>'s artifact IDs are |
| 34 | 34 | fairly long, there are two good ways to refer to the version. You can |
| 35 | 35 | use a unique proper prefix of the version (six or eight characters is |
| 36 | 36 | more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki | |
| 37 | -tag] your baselines and use the tags for checkouts, reverting, | |
| 37 | +tag] your check-ins and use the tags for checkouts, reverting, | |
| 38 | 38 | branching (tags are the best way to branch) and so forth. Both |
| 39 | 39 | methods work throughout fossil. |
| 40 | 40 | |
| 41 | 41 | See also [./cmd_tag.wiki | fossil tag], |
| 42 | 42 | [./cmd_revert.wiki | fossil revert], |
| 43 | 43 |
| --- www/cmd_checkout.wiki | |
| +++ www/cmd_checkout.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | |
| 33 | Since a version is required, and <b>fossil</b>'s artifact IDs are |
| 34 | fairly long, there are two good ways to refer to the version. You can |
| 35 | use a unique proper prefix of the version (six or eight characters is |
| 36 | more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki | |
| 37 | tag] your baselines and use the tags for checkouts, reverting, |
| 38 | branching (tags are the best way to branch) and so forth. Both |
| 39 | methods work throughout fossil. |
| 40 | |
| 41 | See also [./cmd_tag.wiki | fossil tag], |
| 42 | [./cmd_revert.wiki | fossil revert], |
| 43 |
| --- www/cmd_checkout.wiki | |
| +++ www/cmd_checkout.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | |
| 33 | Since a version is required, and <b>fossil</b>'s artifact IDs are |
| 34 | fairly long, there are two good ways to refer to the version. You can |
| 35 | use a unique proper prefix of the version (six or eight characters is |
| 36 | more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki | |
| 37 | tag] your check-ins and use the tags for checkouts, reverting, |
| 38 | branching (tags are the best way to branch) and so forth. Both |
| 39 | methods work throughout fossil. |
| 40 | |
| 41 | See also [./cmd_tag.wiki | fossil tag], |
| 42 | [./cmd_revert.wiki | fossil revert], |
| 43 |
+29
-29
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -25,17 +25,17 @@ | ||
| 25 | 25 | A source tree is a hierarchy of files that are used to generate |
| 26 | 26 | the end product. The source tree changes over time as the |
| 27 | 27 | software grows and expands and as features are added and bugs |
| 28 | 28 | are fixed. A snapshot of the source tree at any point in time |
| 29 | 29 | is called a "version" or "revision" or a "baseline" of the product. |
| 30 | -In fossil, we use the name "baseline".</p> | |
| 30 | +In fossil, we use the name "check-in".</p> | |
| 31 | 31 | |
| 32 | 32 | <p>A "repository" is a database that contains copies of all historical |
| 33 | -versions or baselines for a project. Baselines are normally stored in the | |
| 33 | +check-ins for a project. Check-ins are normally stored in the | |
| 34 | 34 | repository in a highly space-efficient compressed format (delta encoding). |
| 35 | 35 | But that is an implementation detail that you the user need not worry over. |
| 36 | -Think of the repository as a safe place where all your old baselines are | |
| 36 | +Think of the repository as a safe place where all your old check-ins are | |
| 37 | 37 | securely stored away and available for retrieval whenever you need |
| 38 | 38 | them.</p> |
| 39 | 39 | |
| 40 | 40 | <p>A repository in fossil is a single file on your disk. This file |
| 41 | 41 | might be rather large (dozens or hundreds of megabytes for a large |
| @@ -127,45 +127,45 @@ | ||
| 127 | 127 | <p>At the root of a source tree is a special file called the |
| 128 | 128 | "manifest". The manifest is a listing of all other files in |
| 129 | 129 | that source tree. The manifest contains the (complete) artifact ID |
| 130 | 130 | of the file and the name of the file as it appears on disk, |
| 131 | 131 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 132 | -of the manifest is the identifier for the entire baseline. When | |
| 132 | +of the manifest is the identifier for the entire check-in. When | |
| 133 | 133 | you look at a "timeline" of changes in fossil, the ID associated |
| 134 | 134 | with each check-in or commit is really just the artifact ID of the |
| 135 | -manifest for that baseline.</p> | |
| 135 | +manifest for that check-in.</p> | |
| 136 | 136 | |
| 137 | 137 | <p>Fossil automatically generates a manifest whenever you "commit" |
| 138 | -a new baseline. So this is not something that you, the developer, | |
| 138 | +a new check-in. So this is not something that you, the developer, | |
| 139 | 139 | need to worry with. The format of a manifest is intentionally |
| 140 | 140 | designed to be simple to parse, so that if |
| 141 | 141 | you want to read and interpret a manifest, either by hand or |
| 142 | 142 | with a script, that is easy to do. But you will probably never |
| 143 | 143 | need to do so.</p> |
| 144 | 144 | |
| 145 | -<p>In addition to identifying all files in the baseline, a | |
| 145 | +<p>In addition to identifying all files in the check-in, a | |
| 146 | 146 | manifest also contains a check-in comment, the date and time |
| 147 | -when the baseline was established, who created the baseline, | |
| 148 | -and links to other baselines from which the current baseline | |
| 147 | +when the check-in was established, who created the check-in, | |
| 148 | +and links to other check-ins from which the current check-in | |
| 149 | 149 | is derived. There is also a couple of checksums used to verify |
| 150 | -the integrity of the baseline. And the whole manifest might | |
| 150 | +the integrity of the check-in. And the whole manifest might | |
| 151 | 151 | be PGP clearsigned.</p> |
| 152 | 152 | |
| 153 | 153 | <h3>2.3 Key concepts</h3> |
| 154 | 154 | |
| 155 | 155 | <ul> |
| 156 | -<li>A <b>baseline</b> is a set of files arranged | |
| 156 | +<li>A <b>check-in</b> is a set of files arranged | |
| 157 | 157 | in a hierarchy.</li> |
| 158 | -<li>A <b>repository</b> keeps a record of historical baselines.</li> | |
| 158 | +<li>A <b>repository</b> keeps a record of historical check-ins.</li> | |
| 159 | 159 | <li>Repositories share their changes using <b>push</b>, <b>pull</b>, |
| 160 | 160 | <b>sync</b>, and <b>clone</b>.</li> |
| 161 | 161 | <li>A particular version of a particular file is an <b>artifact</b> |
| 162 | 162 | that is identified by an <b>artifact ID</b>.</li> |
| 163 | 163 | <li>Artifacts tracked by fossil are inherently immutable.</li> |
| 164 | 164 | <li>Fossil automatically generates a <b>manifest</b> file that identifies |
| 165 | - every artifact in a baseline.</li> | |
| 166 | -<li>The artifact ID of the manifest is the identifier of the baseline.</li> | |
| 165 | + every artifact in a check-in.</li> | |
| 166 | +<li>The artifact ID of the manifest is the identifier of the check-in.</li> | |
| 167 | 167 | </ul> |
| 168 | 168 | |
| 169 | 169 | <h2>3.0 Fossil - The Program</h2> |
| 170 | 170 | |
| 171 | 171 | <p>Fossil is software. The implementation of fossil is in the form |
| @@ -249,25 +249,25 @@ | ||
| 249 | 249 | argument. |
| 250 | 250 | </p></li> |
| 251 | 251 | |
| 252 | 252 | <li><p> |
| 253 | 253 | The <b>open</b> command in the previous step populates your local source |
| 254 | -tree with a copy of the latest baseline. Usually this is what you want. | |
| 254 | +tree with a copy of the latest check-in. Usually this is what you want. | |
| 255 | 255 | In the rare cases where it is not, use the <b>update</b> command to |
| 256 | -switch to a new baseline. Use the <b>timeline</b> or <b>leaves</b> commands | |
| 257 | -to identify alternative baselines to switch to. | |
| 256 | +switch to a new check-in. Use the <b>timeline</b> or <b>leaves</b> commands | |
| 257 | +to identify alternative check-ins to switch to. | |
| 258 | 258 | </p></li> |
| 259 | 259 | |
| 260 | 260 | <li><p> |
| 261 | 261 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 262 | -command. Omit files from future baselines using the <b>rm</b> command. | |
| 263 | -(Even when you remove files from future baselines, those files continue | |
| 264 | -to exist in historical baselines.) Test your changes. | |
| 262 | +command. Omit files from future check-ins using the <b>rm</b> command. | |
| 263 | +(Even when you remove files from future check-ins, those files continue | |
| 264 | +to exist in historical check-ins.) Test your changes. | |
| 265 | 265 | </p></li> |
| 266 | 266 | |
| 267 | 267 | <li><p> |
| 268 | -Create a new baseline using the <b>commit</b> command. You will be prompted | |
| 268 | +Create a new check-in using the <b>commit</b> command. You will be prompted | |
| 269 | 269 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 270 | 270 | The commit copies the edits you have made in your local source |
| 271 | 271 | tree into your local repository. After your commit completes, fossil will |
| 272 | 272 | automatically <b>push</b> your changes back to the server |
| 273 | 273 | you cloned from or whatever server you most recently synced with. |
| @@ -314,25 +314,25 @@ | ||
| 314 | 314 | argument. |
| 315 | 315 | </p></li> |
| 316 | 316 | |
| 317 | 317 | <li><p> |
| 318 | 318 | The <b>open</b> command in the previous step populates your local source |
| 319 | -tree with a copy of the latest baseline. Usually this is what you want. | |
| 319 | +tree with a copy of the latest check-in. Usually this is what you want. | |
| 320 | 320 | In the rare cases where it is not, use the <b>update</b> command to |
| 321 | -switch to a new baseline. Use the <b>timeline</b> or <b>leaves</b> commands | |
| 322 | -to identify alternative baselines to switch to. | |
| 321 | +switch to a new check-in. Use the <b>timeline</b> or <b>leaves</b> commands | |
| 322 | +to identify alternative check-ins to switch to. | |
| 323 | 323 | </p></li> |
| 324 | 324 | |
| 325 | 325 | <li><p> |
| 326 | 326 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 327 | -command. Omit files from future baselines using the <b>rm</b> command. | |
| 328 | -(Even when you remove files from future baselines, those files continue | |
| 329 | -to exist in historical baselines.) Test your changes. | |
| 327 | +command. Omit files from future check-ins using the <b>rm</b> command. | |
| 328 | +(Even when you remove files from future check-ins, those files continue | |
| 329 | +to exist in historical check-ins.) Test your changes. | |
| 330 | 330 | </p></li> |
| 331 | 331 | |
| 332 | 332 | <li><p> |
| 333 | -Create a new baseline using the <b>commit</b> command. You will be prompted | |
| 333 | +Create a new check-in using the <b>commit</b> command. You will be prompted | |
| 334 | 334 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 335 | 335 | The commit copies the edits you have made in your local source |
| 336 | 336 | tree into your local repository. |
| 337 | 337 | </p></li> |
| 338 | 338 | |
| @@ -431,11 +431,11 @@ | ||
| 431 | 431 | Just put it somewhere on your PATH to install it.</li> |
| 432 | 432 | <li>Use the <b>clone</b> or <b>new</b> commands to create a new repository.</li> |
| 433 | 433 | <li>Use the <b>open</b> command to create a new source tree.</li> |
| 434 | 434 | <li>Use the <b>add</b> and <b>rm</b> or <b>delete</b> commands to add and |
| 435 | 435 | remove files from the local source tree.</li> |
| 436 | -<li>Use the <b>commit</b> command to create a new baseline.</li> | |
| 436 | +<li>Use the <b>commit</b> command to create a new check-in.</li> | |
| 437 | 437 | <li>Use the <b>update</b> command to merge in changes from others.</li> |
| 438 | 438 | <li>The <b>push</b> and <b>pull</b> commands can be used to share changes |
| 439 | 439 | manually, but these things happen automatically in the default |
| 440 | 440 | autosync mode.</li> |
| 441 | 441 | </ul> |
| 442 | 442 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -25,17 +25,17 @@ | |
| 25 | A source tree is a hierarchy of files that are used to generate |
| 26 | the end product. The source tree changes over time as the |
| 27 | software grows and expands and as features are added and bugs |
| 28 | are fixed. A snapshot of the source tree at any point in time |
| 29 | is called a "version" or "revision" or a "baseline" of the product. |
| 30 | In fossil, we use the name "baseline".</p> |
| 31 | |
| 32 | <p>A "repository" is a database that contains copies of all historical |
| 33 | versions or baselines for a project. Baselines are normally stored in the |
| 34 | repository in a highly space-efficient compressed format (delta encoding). |
| 35 | But that is an implementation detail that you the user need not worry over. |
| 36 | Think of the repository as a safe place where all your old baselines are |
| 37 | securely stored away and available for retrieval whenever you need |
| 38 | them.</p> |
| 39 | |
| 40 | <p>A repository in fossil is a single file on your disk. This file |
| 41 | might be rather large (dozens or hundreds of megabytes for a large |
| @@ -127,45 +127,45 @@ | |
| 127 | <p>At the root of a source tree is a special file called the |
| 128 | "manifest". The manifest is a listing of all other files in |
| 129 | that source tree. The manifest contains the (complete) artifact ID |
| 130 | of the file and the name of the file as it appears on disk, |
| 131 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 132 | of the manifest is the identifier for the entire baseline. When |
| 133 | you look at a "timeline" of changes in fossil, the ID associated |
| 134 | with each check-in or commit is really just the artifact ID of the |
| 135 | manifest for that baseline.</p> |
| 136 | |
| 137 | <p>Fossil automatically generates a manifest whenever you "commit" |
| 138 | a new baseline. So this is not something that you, the developer, |
| 139 | need to worry with. The format of a manifest is intentionally |
| 140 | designed to be simple to parse, so that if |
| 141 | you want to read and interpret a manifest, either by hand or |
| 142 | with a script, that is easy to do. But you will probably never |
| 143 | need to do so.</p> |
| 144 | |
| 145 | <p>In addition to identifying all files in the baseline, a |
| 146 | manifest also contains a check-in comment, the date and time |
| 147 | when the baseline was established, who created the baseline, |
| 148 | and links to other baselines from which the current baseline |
| 149 | is derived. There is also a couple of checksums used to verify |
| 150 | the integrity of the baseline. And the whole manifest might |
| 151 | be PGP clearsigned.</p> |
| 152 | |
| 153 | <h3>2.3 Key concepts</h3> |
| 154 | |
| 155 | <ul> |
| 156 | <li>A <b>baseline</b> is a set of files arranged |
| 157 | in a hierarchy.</li> |
| 158 | <li>A <b>repository</b> keeps a record of historical baselines.</li> |
| 159 | <li>Repositories share their changes using <b>push</b>, <b>pull</b>, |
| 160 | <b>sync</b>, and <b>clone</b>.</li> |
| 161 | <li>A particular version of a particular file is an <b>artifact</b> |
| 162 | that is identified by an <b>artifact ID</b>.</li> |
| 163 | <li>Artifacts tracked by fossil are inherently immutable.</li> |
| 164 | <li>Fossil automatically generates a <b>manifest</b> file that identifies |
| 165 | every artifact in a baseline.</li> |
| 166 | <li>The artifact ID of the manifest is the identifier of the baseline.</li> |
| 167 | </ul> |
| 168 | |
| 169 | <h2>3.0 Fossil - The Program</h2> |
| 170 | |
| 171 | <p>Fossil is software. The implementation of fossil is in the form |
| @@ -249,25 +249,25 @@ | |
| 249 | argument. |
| 250 | </p></li> |
| 251 | |
| 252 | <li><p> |
| 253 | The <b>open</b> command in the previous step populates your local source |
| 254 | tree with a copy of the latest baseline. Usually this is what you want. |
| 255 | In the rare cases where it is not, use the <b>update</b> command to |
| 256 | switch to a new baseline. Use the <b>timeline</b> or <b>leaves</b> commands |
| 257 | to identify alternative baselines to switch to. |
| 258 | </p></li> |
| 259 | |
| 260 | <li><p> |
| 261 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 262 | command. Omit files from future baselines using the <b>rm</b> command. |
| 263 | (Even when you remove files from future baselines, those files continue |
| 264 | to exist in historical baselines.) Test your changes. |
| 265 | </p></li> |
| 266 | |
| 267 | <li><p> |
| 268 | Create a new baseline using the <b>commit</b> command. You will be prompted |
| 269 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 270 | The commit copies the edits you have made in your local source |
| 271 | tree into your local repository. After your commit completes, fossil will |
| 272 | automatically <b>push</b> your changes back to the server |
| 273 | you cloned from or whatever server you most recently synced with. |
| @@ -314,25 +314,25 @@ | |
| 314 | argument. |
| 315 | </p></li> |
| 316 | |
| 317 | <li><p> |
| 318 | The <b>open</b> command in the previous step populates your local source |
| 319 | tree with a copy of the latest baseline. Usually this is what you want. |
| 320 | In the rare cases where it is not, use the <b>update</b> command to |
| 321 | switch to a new baseline. Use the <b>timeline</b> or <b>leaves</b> commands |
| 322 | to identify alternative baselines to switch to. |
| 323 | </p></li> |
| 324 | |
| 325 | <li><p> |
| 326 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 327 | command. Omit files from future baselines using the <b>rm</b> command. |
| 328 | (Even when you remove files from future baselines, those files continue |
| 329 | to exist in historical baselines.) Test your changes. |
| 330 | </p></li> |
| 331 | |
| 332 | <li><p> |
| 333 | Create a new baseline using the <b>commit</b> command. You will be prompted |
| 334 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 335 | The commit copies the edits you have made in your local source |
| 336 | tree into your local repository. |
| 337 | </p></li> |
| 338 | |
| @@ -431,11 +431,11 @@ | |
| 431 | Just put it somewhere on your PATH to install it.</li> |
| 432 | <li>Use the <b>clone</b> or <b>new</b> commands to create a new repository.</li> |
| 433 | <li>Use the <b>open</b> command to create a new source tree.</li> |
| 434 | <li>Use the <b>add</b> and <b>rm</b> or <b>delete</b> commands to add and |
| 435 | remove files from the local source tree.</li> |
| 436 | <li>Use the <b>commit</b> command to create a new baseline.</li> |
| 437 | <li>Use the <b>update</b> command to merge in changes from others.</li> |
| 438 | <li>The <b>push</b> and <b>pull</b> commands can be used to share changes |
| 439 | manually, but these things happen automatically in the default |
| 440 | autosync mode.</li> |
| 441 | </ul> |
| 442 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -25,17 +25,17 @@ | |
| 25 | A source tree is a hierarchy of files that are used to generate |
| 26 | the end product. The source tree changes over time as the |
| 27 | software grows and expands and as features are added and bugs |
| 28 | are fixed. A snapshot of the source tree at any point in time |
| 29 | is called a "version" or "revision" or a "baseline" of the product. |
| 30 | In fossil, we use the name "check-in".</p> |
| 31 | |
| 32 | <p>A "repository" is a database that contains copies of all historical |
| 33 | check-ins for a project. Check-ins are normally stored in the |
| 34 | repository in a highly space-efficient compressed format (delta encoding). |
| 35 | But that is an implementation detail that you the user need not worry over. |
| 36 | Think of the repository as a safe place where all your old check-ins are |
| 37 | securely stored away and available for retrieval whenever you need |
| 38 | them.</p> |
| 39 | |
| 40 | <p>A repository in fossil is a single file on your disk. This file |
| 41 | might be rather large (dozens or hundreds of megabytes for a large |
| @@ -127,45 +127,45 @@ | |
| 127 | <p>At the root of a source tree is a special file called the |
| 128 | "manifest". The manifest is a listing of all other files in |
| 129 | that source tree. The manifest contains the (complete) artifact ID |
| 130 | of the file and the name of the file as it appears on disk, |
| 131 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 132 | of the manifest is the identifier for the entire check-in. When |
| 133 | you look at a "timeline" of changes in fossil, the ID associated |
| 134 | with each check-in or commit is really just the artifact ID of the |
| 135 | manifest for that check-in.</p> |
| 136 | |
| 137 | <p>Fossil automatically generates a manifest whenever you "commit" |
| 138 | a new check-in. So this is not something that you, the developer, |
| 139 | need to worry with. The format of a manifest is intentionally |
| 140 | designed to be simple to parse, so that if |
| 141 | you want to read and interpret a manifest, either by hand or |
| 142 | with a script, that is easy to do. But you will probably never |
| 143 | need to do so.</p> |
| 144 | |
| 145 | <p>In addition to identifying all files in the check-in, a |
| 146 | manifest also contains a check-in comment, the date and time |
| 147 | when the check-in was established, who created the check-in, |
| 148 | and links to other check-ins from which the current check-in |
| 149 | is derived. There is also a couple of checksums used to verify |
| 150 | the integrity of the check-in. And the whole manifest might |
| 151 | be PGP clearsigned.</p> |
| 152 | |
| 153 | <h3>2.3 Key concepts</h3> |
| 154 | |
| 155 | <ul> |
| 156 | <li>A <b>check-in</b> is a set of files arranged |
| 157 | in a hierarchy.</li> |
| 158 | <li>A <b>repository</b> keeps a record of historical check-ins.</li> |
| 159 | <li>Repositories share their changes using <b>push</b>, <b>pull</b>, |
| 160 | <b>sync</b>, and <b>clone</b>.</li> |
| 161 | <li>A particular version of a particular file is an <b>artifact</b> |
| 162 | that is identified by an <b>artifact ID</b>.</li> |
| 163 | <li>Artifacts tracked by fossil are inherently immutable.</li> |
| 164 | <li>Fossil automatically generates a <b>manifest</b> file that identifies |
| 165 | every artifact in a check-in.</li> |
| 166 | <li>The artifact ID of the manifest is the identifier of the check-in.</li> |
| 167 | </ul> |
| 168 | |
| 169 | <h2>3.0 Fossil - The Program</h2> |
| 170 | |
| 171 | <p>Fossil is software. The implementation of fossil is in the form |
| @@ -249,25 +249,25 @@ | |
| 249 | argument. |
| 250 | </p></li> |
| 251 | |
| 252 | <li><p> |
| 253 | The <b>open</b> command in the previous step populates your local source |
| 254 | tree with a copy of the latest check-in. Usually this is what you want. |
| 255 | In the rare cases where it is not, use the <b>update</b> command to |
| 256 | switch to a new check-in. Use the <b>timeline</b> or <b>leaves</b> commands |
| 257 | to identify alternative check-ins to switch to. |
| 258 | </p></li> |
| 259 | |
| 260 | <li><p> |
| 261 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 262 | command. Omit files from future check-ins using the <b>rm</b> command. |
| 263 | (Even when you remove files from future check-ins, those files continue |
| 264 | to exist in historical check-ins.) Test your changes. |
| 265 | </p></li> |
| 266 | |
| 267 | <li><p> |
| 268 | Create a new check-in using the <b>commit</b> command. You will be prompted |
| 269 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 270 | The commit copies the edits you have made in your local source |
| 271 | tree into your local repository. After your commit completes, fossil will |
| 272 | automatically <b>push</b> your changes back to the server |
| 273 | you cloned from or whatever server you most recently synced with. |
| @@ -314,25 +314,25 @@ | |
| 314 | argument. |
| 315 | </p></li> |
| 316 | |
| 317 | <li><p> |
| 318 | The <b>open</b> command in the previous step populates your local source |
| 319 | tree with a copy of the latest check-in. Usually this is what you want. |
| 320 | In the rare cases where it is not, use the <b>update</b> command to |
| 321 | switch to a new check-in. Use the <b>timeline</b> or <b>leaves</b> commands |
| 322 | to identify alternative check-ins to switch to. |
| 323 | </p></li> |
| 324 | |
| 325 | <li><p> |
| 326 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 327 | command. Omit files from future check-ins using the <b>rm</b> command. |
| 328 | (Even when you remove files from future check-ins, those files continue |
| 329 | to exist in historical check-ins.) Test your changes. |
| 330 | </p></li> |
| 331 | |
| 332 | <li><p> |
| 333 | Create a new check-in using the <b>commit</b> command. You will be prompted |
| 334 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 335 | The commit copies the edits you have made in your local source |
| 336 | tree into your local repository. |
| 337 | </p></li> |
| 338 | |
| @@ -431,11 +431,11 @@ | |
| 431 | Just put it somewhere on your PATH to install it.</li> |
| 432 | <li>Use the <b>clone</b> or <b>new</b> commands to create a new repository.</li> |
| 433 | <li>Use the <b>open</b> command to create a new source tree.</li> |
| 434 | <li>Use the <b>add</b> and <b>rm</b> or <b>delete</b> commands to add and |
| 435 | remove files from the local source tree.</li> |
| 436 | <li>Use the <b>commit</b> command to create a new check-in.</li> |
| 437 | <li>Use the <b>update</b> command to merge in changes from others.</li> |
| 438 | <li>The <b>push</b> and <b>pull</b> commands can be used to share changes |
| 439 | manually, but these things happen automatically in the default |
| 440 | autosync mode.</li> |
| 441 | </ul> |
| 442 |
+5
-5
| --- www/embeddeddoc.wiki | ||
| +++ www/embeddeddoc.wiki | ||
| @@ -41,18 +41,18 @@ | ||
| 41 | 41 | <b>http://www.hwaci.com/cgi-bin/fossil</b>. |
| 42 | 42 | If you launch the web server using the "<b>fossil server</b>" command line, |
| 43 | 43 | then the <i><baseurl></i> is usually |
| 44 | 44 | <b>http://localhost:8080/</b>. |
| 45 | 45 | |
| 46 | -The <i><version></i> is any unique prefix of the baseline ID for | |
| 47 | -the baseline containing the documentation you want to access. | |
| 46 | +The <i><version></i> is any unique prefix of the check-in ID for | |
| 47 | +the check-in containing the documentation you want to access. | |
| 48 | 48 | Or <i><version></i> can be one of the keywords "<b>tip</b>" or |
| 49 | 49 | "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently |
| 50 | -checked-in baseline. This is useful if you want to see the very latest | |
| 50 | +checked-in. This is useful if you want to see the very latest | |
| 51 | 51 | version of the documentation. The "<b>ckout</b>" keywords means to |
| 52 | 52 | pull the documentation file from the local source tree on disk, not |
| 53 | -from the any versioned baseline. The "<b>ckout</b>" keyword normally | |
| 53 | +from the any check-in. The "<b>ckout</b>" keyword normally | |
| 54 | 54 | only works when you start your server using the "<b>fossil server</b>" |
| 55 | 55 | or "<b>fossil ui</b>" |
| 56 | 56 | command line and is indented to show what the documentation you are currently |
| 57 | 57 | editing looks like before you check it in. |
| 58 | 58 | |
| @@ -98,11 +98,11 @@ | ||
| 98 | 98 | |
| 99 | 99 | This is one of three ways to set up a |
| 100 | 100 | <a href="quickstart.wiki#serversetup">fossil web server</a>. |
| 101 | 101 | |
| 102 | 102 | The "<b>/tip/</b>" part of the URL tells fossil to use |
| 103 | -the documentation files from the baseline that was checked in most | |
| 103 | +the documentation files from the check-in that was checked in most | |
| 104 | 104 | recently. This file is stored in the fossil source tree under |
| 105 | 105 | the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the |
| 106 | 106 | last part of the URL. |
| 107 | 107 | |
| 108 | 108 | As I sit writing this documentation file, I am testing my work by |
| 109 | 109 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -41,18 +41,18 @@ | |
| 41 | <b>http://www.hwaci.com/cgi-bin/fossil</b>. |
| 42 | If you launch the web server using the "<b>fossil server</b>" command line, |
| 43 | then the <i><baseurl></i> is usually |
| 44 | <b>http://localhost:8080/</b>. |
| 45 | |
| 46 | The <i><version></i> is any unique prefix of the baseline ID for |
| 47 | the baseline containing the documentation you want to access. |
| 48 | Or <i><version></i> can be one of the keywords "<b>tip</b>" or |
| 49 | "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently |
| 50 | checked-in baseline. This is useful if you want to see the very latest |
| 51 | version of the documentation. The "<b>ckout</b>" keywords means to |
| 52 | pull the documentation file from the local source tree on disk, not |
| 53 | from the any versioned baseline. The "<b>ckout</b>" keyword normally |
| 54 | only works when you start your server using the "<b>fossil server</b>" |
| 55 | or "<b>fossil ui</b>" |
| 56 | command line and is indented to show what the documentation you are currently |
| 57 | editing looks like before you check it in. |
| 58 | |
| @@ -98,11 +98,11 @@ | |
| 98 | |
| 99 | This is one of three ways to set up a |
| 100 | <a href="quickstart.wiki#serversetup">fossil web server</a>. |
| 101 | |
| 102 | The "<b>/tip/</b>" part of the URL tells fossil to use |
| 103 | the documentation files from the baseline that was checked in most |
| 104 | recently. This file is stored in the fossil source tree under |
| 105 | the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the |
| 106 | last part of the URL. |
| 107 | |
| 108 | As I sit writing this documentation file, I am testing my work by |
| 109 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -41,18 +41,18 @@ | |
| 41 | <b>http://www.hwaci.com/cgi-bin/fossil</b>. |
| 42 | If you launch the web server using the "<b>fossil server</b>" command line, |
| 43 | then the <i><baseurl></i> is usually |
| 44 | <b>http://localhost:8080/</b>. |
| 45 | |
| 46 | The <i><version></i> is any unique prefix of the check-in ID for |
| 47 | the check-in containing the documentation you want to access. |
| 48 | Or <i><version></i> can be one of the keywords "<b>tip</b>" or |
| 49 | "<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently |
| 50 | checked-in. This is useful if you want to see the very latest |
| 51 | version of the documentation. The "<b>ckout</b>" keywords means to |
| 52 | pull the documentation file from the local source tree on disk, not |
| 53 | from the any check-in. The "<b>ckout</b>" keyword normally |
| 54 | only works when you start your server using the "<b>fossil server</b>" |
| 55 | or "<b>fossil ui</b>" |
| 56 | command line and is indented to show what the documentation you are currently |
| 57 | editing looks like before you check it in. |
| 58 | |
| @@ -98,11 +98,11 @@ | |
| 98 | |
| 99 | This is one of three ways to set up a |
| 100 | <a href="quickstart.wiki#serversetup">fossil web server</a>. |
| 101 | |
| 102 | The "<b>/tip/</b>" part of the URL tells fossil to use |
| 103 | the documentation files from the check-in that was checked in most |
| 104 | recently. This file is stored in the fossil source tree under |
| 105 | the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the |
| 106 | last part of the URL. |
| 107 | |
| 108 | As I sit writing this documentation file, I am testing my work by |
| 109 |
+13
-13
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -63,17 +63,17 @@ | ||
| 63 | 63 | disk, though stable, is not intended to have as long a lifespan as the |
| 64 | 64 | artifact format.</p> |
| 65 | 65 | |
| 66 | 66 | <h2>1.0 The Manifest</h2> |
| 67 | 67 | |
| 68 | -<p>A manifest defines a baseline or version of the project | |
| 68 | +<p>A manifest defines a check-in or version of the project | |
| 69 | 69 | source tree. The manifest contains a list of artifacts for |
| 70 | 70 | each file in the project and the corresponding filenames, as |
| 71 | -well as information such as parent baselines, the name of the | |
| 72 | -programmer who created the baseline, the date and time when | |
| 73 | -the baseline was created, and any check-in comments associated | |
| 74 | -with the baseline.</p> | |
| 71 | +well as information such as parent check-ins, the name of the | |
| 72 | +programmer who created the check-in, the date and time when | |
| 73 | +the check-in was created, and any check-in comments associated | |
| 74 | +with the check-in.</p> | |
| 75 | 75 | |
| 76 | 76 | <p> |
| 77 | 77 | Any artifact in the repository that follows the syntactic rules |
| 78 | 78 | of a manifest is a manifest. Note that a manifest can |
| 79 | 79 | be both a real manifest and also a content file, though this |
| @@ -137,14 +137,14 @@ | ||
| 137 | 137 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i> |
| 138 | 138 | </blockquote> |
| 139 | 139 | |
| 140 | 140 | <p> |
| 141 | 141 | A manifest has zero or more F-cards. Each F-card defines a file |
| 142 | -(other than the manifest itself) which is part of the baseline that | |
| 142 | +(other than the manifest itself) which is part of the check-in that | |
| 143 | 143 | the manifest defines. There are two, three, or three arguments. |
| 144 | 144 | The first argument |
| 145 | -is the pathname of the file in the baseline relative to the root | |
| 145 | +is the pathname of the file in the check-in relative to the root | |
| 146 | 146 | of the project file hierarchy. No ".." or "." directories are allowed |
| 147 | 147 | within the filename. Space characters are escaped as in C-card |
| 148 | 148 | comment text. Backslash characters and newlines are not allowed |
| 149 | 149 | within filenames. The directory separator character is a forward |
| 150 | 150 | slash (ASCII 0x2F). The second argument to the F-card is the |
| @@ -153,19 +153,19 @@ | ||
| 153 | 153 | permissions associated with the file. The only special code currently |
| 154 | 154 | defined is "x" which means that the file is executable. All files are |
| 155 | 155 | always readable and writable. This can be expressed by "w" permission |
| 156 | 156 | if desired but is optional. |
| 157 | 157 | The optional 4th argument is the name of the same file as it existed in |
| 158 | -the parent baseline. If the name of the file is unchanged from its | |
| 158 | +the parent check-in. If the name of the file is unchanged from its | |
| 159 | 159 | parent, then the 4th argument is omitted. |
| 160 | 160 | </p> |
| 161 | 161 | |
| 162 | 162 | <p> |
| 163 | 163 | A manifest has zero or more N-cards. Each N card records a name changes |
| 164 | 164 | to one of the files in the manifest. The first argument to the N code is |
| 165 | -the name of the file in the parent baseline. The second argument is the | |
| 166 | -name of the file in the baseline defined by the manifest. | |
| 165 | +the name of the file in the parent check-in. The second argument is the | |
| 166 | +name of the file in the check-in defined by the manifest. | |
| 167 | 167 | </p> |
| 168 | 168 | |
| 169 | 169 | <p> |
| 170 | 170 | A manifest has zero or one P-cards. Most manifests have one P-card. |
| 171 | 171 | The P-card has a varying number of arguments that |
| @@ -181,13 +181,13 @@ | ||
| 181 | 181 | </p> |
| 182 | 182 | |
| 183 | 183 | <p> |
| 184 | 184 | A manifest may optionally have a single R-card. The R-card has |
| 185 | 185 | a single argument which is the MD5 checksum of all files in |
| 186 | -the baseline except the manifest itself. The checksum is expressed | |
| 186 | +the check-in except the manifest itself. The checksum is expressed | |
| 187 | 187 | as 32-characters of lowercase hexadecimal. The checksum is |
| 188 | -computed as follows: For each file in the baseline (except for | |
| 188 | +computed as follows: For each file in the check-in (except for | |
| 189 | 189 | the manifest itself) in strict sorted lexicographical order, |
| 190 | 190 | take the pathname of the file relative to the root of the |
| 191 | 191 | repository, append a single space (ASCII 0x20), the |
| 192 | 192 | size of the file in ASCII decimal, a single newline |
| 193 | 193 | character (ASCII 0x0A), and the complete text of the file. |
| @@ -305,11 +305,11 @@ | ||
| 305 | 305 | <p>When two or more tags with the same name are applied to the |
| 306 | 306 | same artifact, the tag with the latest (most recent) date is |
| 307 | 307 | used.</p> |
| 308 | 308 | |
| 309 | 309 | <p>Some tags have special meaning. The "comment" tag when applied |
| 310 | -to a baseline will override the check-in comment of that baseline | |
| 310 | +to a check-in will override the check-in comment of that check-in | |
| 311 | 311 | for display purposes.</p> |
| 312 | 312 | |
| 313 | 313 | <a name="wikichng"></a> |
| 314 | 314 | <h2>4.0 Wiki Pages</h2> |
| 315 | 315 | |
| 316 | 316 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -63,17 +63,17 @@ | |
| 63 | disk, though stable, is not intended to have as long a lifespan as the |
| 64 | artifact format.</p> |
| 65 | |
| 66 | <h2>1.0 The Manifest</h2> |
| 67 | |
| 68 | <p>A manifest defines a baseline or version of the project |
| 69 | source tree. The manifest contains a list of artifacts for |
| 70 | each file in the project and the corresponding filenames, as |
| 71 | well as information such as parent baselines, the name of the |
| 72 | programmer who created the baseline, the date and time when |
| 73 | the baseline was created, and any check-in comments associated |
| 74 | with the baseline.</p> |
| 75 | |
| 76 | <p> |
| 77 | Any artifact in the repository that follows the syntactic rules |
| 78 | of a manifest is a manifest. Note that a manifest can |
| 79 | be both a real manifest and also a content file, though this |
| @@ -137,14 +137,14 @@ | |
| 137 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i> |
| 138 | </blockquote> |
| 139 | |
| 140 | <p> |
| 141 | A manifest has zero or more F-cards. Each F-card defines a file |
| 142 | (other than the manifest itself) which is part of the baseline that |
| 143 | the manifest defines. There are two, three, or three arguments. |
| 144 | The first argument |
| 145 | is the pathname of the file in the baseline relative to the root |
| 146 | of the project file hierarchy. No ".." or "." directories are allowed |
| 147 | within the filename. Space characters are escaped as in C-card |
| 148 | comment text. Backslash characters and newlines are not allowed |
| 149 | within filenames. The directory separator character is a forward |
| 150 | slash (ASCII 0x2F). The second argument to the F-card is the |
| @@ -153,19 +153,19 @@ | |
| 153 | permissions associated with the file. The only special code currently |
| 154 | defined is "x" which means that the file is executable. All files are |
| 155 | always readable and writable. This can be expressed by "w" permission |
| 156 | if desired but is optional. |
| 157 | The optional 4th argument is the name of the same file as it existed in |
| 158 | the parent baseline. If the name of the file is unchanged from its |
| 159 | parent, then the 4th argument is omitted. |
| 160 | </p> |
| 161 | |
| 162 | <p> |
| 163 | A manifest has zero or more N-cards. Each N card records a name changes |
| 164 | to one of the files in the manifest. The first argument to the N code is |
| 165 | the name of the file in the parent baseline. The second argument is the |
| 166 | name of the file in the baseline defined by the manifest. |
| 167 | </p> |
| 168 | |
| 169 | <p> |
| 170 | A manifest has zero or one P-cards. Most manifests have one P-card. |
| 171 | The P-card has a varying number of arguments that |
| @@ -181,13 +181,13 @@ | |
| 181 | </p> |
| 182 | |
| 183 | <p> |
| 184 | A manifest may optionally have a single R-card. The R-card has |
| 185 | a single argument which is the MD5 checksum of all files in |
| 186 | the baseline except the manifest itself. The checksum is expressed |
| 187 | as 32-characters of lowercase hexadecimal. The checksum is |
| 188 | computed as follows: For each file in the baseline (except for |
| 189 | the manifest itself) in strict sorted lexicographical order, |
| 190 | take the pathname of the file relative to the root of the |
| 191 | repository, append a single space (ASCII 0x20), the |
| 192 | size of the file in ASCII decimal, a single newline |
| 193 | character (ASCII 0x0A), and the complete text of the file. |
| @@ -305,11 +305,11 @@ | |
| 305 | <p>When two or more tags with the same name are applied to the |
| 306 | same artifact, the tag with the latest (most recent) date is |
| 307 | used.</p> |
| 308 | |
| 309 | <p>Some tags have special meaning. The "comment" tag when applied |
| 310 | to a baseline will override the check-in comment of that baseline |
| 311 | for display purposes.</p> |
| 312 | |
| 313 | <a name="wikichng"></a> |
| 314 | <h2>4.0 Wiki Pages</h2> |
| 315 | |
| 316 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -63,17 +63,17 @@ | |
| 63 | disk, though stable, is not intended to have as long a lifespan as the |
| 64 | artifact format.</p> |
| 65 | |
| 66 | <h2>1.0 The Manifest</h2> |
| 67 | |
| 68 | <p>A manifest defines a check-in or version of the project |
| 69 | source tree. The manifest contains a list of artifacts for |
| 70 | each file in the project and the corresponding filenames, as |
| 71 | well as information such as parent check-ins, the name of the |
| 72 | programmer who created the check-in, the date and time when |
| 73 | the check-in was created, and any check-in comments associated |
| 74 | with the check-in.</p> |
| 75 | |
| 76 | <p> |
| 77 | Any artifact in the repository that follows the syntactic rules |
| 78 | of a manifest is a manifest. Note that a manifest can |
| 79 | be both a real manifest and also a content file, though this |
| @@ -137,14 +137,14 @@ | |
| 137 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i> |
| 138 | </blockquote> |
| 139 | |
| 140 | <p> |
| 141 | A manifest has zero or more F-cards. Each F-card defines a file |
| 142 | (other than the manifest itself) which is part of the check-in that |
| 143 | the manifest defines. There are two, three, or three arguments. |
| 144 | The first argument |
| 145 | is the pathname of the file in the check-in relative to the root |
| 146 | of the project file hierarchy. No ".." or "." directories are allowed |
| 147 | within the filename. Space characters are escaped as in C-card |
| 148 | comment text. Backslash characters and newlines are not allowed |
| 149 | within filenames. The directory separator character is a forward |
| 150 | slash (ASCII 0x2F). The second argument to the F-card is the |
| @@ -153,19 +153,19 @@ | |
| 153 | permissions associated with the file. The only special code currently |
| 154 | defined is "x" which means that the file is executable. All files are |
| 155 | always readable and writable. This can be expressed by "w" permission |
| 156 | if desired but is optional. |
| 157 | The optional 4th argument is the name of the same file as it existed in |
| 158 | the parent check-in. If the name of the file is unchanged from its |
| 159 | parent, then the 4th argument is omitted. |
| 160 | </p> |
| 161 | |
| 162 | <p> |
| 163 | A manifest has zero or more N-cards. Each N card records a name changes |
| 164 | to one of the files in the manifest. The first argument to the N code is |
| 165 | the name of the file in the parent check-in. The second argument is the |
| 166 | name of the file in the check-in defined by the manifest. |
| 167 | </p> |
| 168 | |
| 169 | <p> |
| 170 | A manifest has zero or one P-cards. Most manifests have one P-card. |
| 171 | The P-card has a varying number of arguments that |
| @@ -181,13 +181,13 @@ | |
| 181 | </p> |
| 182 | |
| 183 | <p> |
| 184 | A manifest may optionally have a single R-card. The R-card has |
| 185 | a single argument which is the MD5 checksum of all files in |
| 186 | the check-in except the manifest itself. The checksum is expressed |
| 187 | as 32-characters of lowercase hexadecimal. The checksum is |
| 188 | computed as follows: For each file in the check-in (except for |
| 189 | the manifest itself) in strict sorted lexicographical order, |
| 190 | take the pathname of the file relative to the root of the |
| 191 | repository, append a single space (ASCII 0x20), the |
| 192 | size of the file in ASCII decimal, a single newline |
| 193 | character (ASCII 0x0A), and the complete text of the file. |
| @@ -305,11 +305,11 @@ | |
| 305 | <p>When two or more tags with the same name are applied to the |
| 306 | same artifact, the tag with the latest (most recent) date is |
| 307 | used.</p> |
| 308 | |
| 309 | <p>Some tags have special meaning. The "comment" tag when applied |
| 310 | to a check-in will override the check-in comment of that check-in |
| 311 | for display purposes.</p> |
| 312 | |
| 313 | <a name="wikichng"></a> |
| 314 | <h2>4.0 Wiki Pages</h2> |
| 315 | |
| 316 |
+1
-2
| --- www/newrepo.wiki | ||
| +++ www/newrepo.wiki | ||
| @@ -10,12 +10,11 @@ | ||
| 10 | 10 | |
| 11 | 11 | <verbatim> |
| 12 | 12 | stephan@ludo:~/fossil$ fossil new demo.fossil |
| 13 | 13 | project-id: 9d8ccff5671796ee04e60af6932aa7788f0a990a |
| 14 | 14 | server-id: 145fe7d71e3b513ac37ac283979d73e12ca04bfe |
| 15 | -admin-user: stephan (no password set yet!) | |
| 16 | -baseline: 84e81a150535f031722f815d59c0c5e96ab7f122 | |
| 15 | +admin-user: stephan (initial password is ******) | |
| 17 | 16 | </verbatim> |
| 18 | 17 | |
| 19 | 18 | The numbers it spits out are unimportant (they are version |
| 20 | 19 | numbers). |
| 21 | 20 | |
| 22 | 21 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -10,12 +10,11 @@ | |
| 10 | |
| 11 | <verbatim> |
| 12 | stephan@ludo:~/fossil$ fossil new demo.fossil |
| 13 | project-id: 9d8ccff5671796ee04e60af6932aa7788f0a990a |
| 14 | server-id: 145fe7d71e3b513ac37ac283979d73e12ca04bfe |
| 15 | admin-user: stephan (no password set yet!) |
| 16 | baseline: 84e81a150535f031722f815d59c0c5e96ab7f122 |
| 17 | </verbatim> |
| 18 | |
| 19 | The numbers it spits out are unimportant (they are version |
| 20 | numbers). |
| 21 | |
| 22 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -10,12 +10,11 @@ | |
| 10 | |
| 11 | <verbatim> |
| 12 | stephan@ludo:~/fossil$ fossil new demo.fossil |
| 13 | project-id: 9d8ccff5671796ee04e60af6932aa7788f0a990a |
| 14 | server-id: 145fe7d71e3b513ac37ac283979d73e12ca04bfe |
| 15 | admin-user: stephan (initial password is ******) |
| 16 | </verbatim> |
| 17 | |
| 18 | The numbers it spits out are unimportant (they are version |
| 19 | numbers). |
| 20 | |
| 21 |
+3
-3
| --- www/pop.wiki | ||
| +++ www/pop.wiki | ||
| @@ -60,15 +60,15 @@ | ||
| 60 | 60 | <li><p>Two repositories for the same project can synchronize |
| 61 | 61 | their global states simply by sharing artifacts. The local |
| 62 | 62 | state of repositories is not normally synchronized or |
| 63 | 63 | shared.</p></li> |
| 64 | 64 | |
| 65 | -<li><p>Every baseline has a special file at the top-level | |
| 65 | +<li><p>Every check-in has a special file at the top-level | |
| 66 | 66 | named "manifest" which is an index of all other files in |
| 67 | -that baseline. The manifest is automatically created and | |
| 67 | +that check-in. The manifest is automatically created and | |
| 68 | 68 | maintained by the system.</p></li> |
| 69 | 69 | |
| 70 | 70 | <li><p>The <a href="fileformat.wiki">file formats</a> |
| 71 | 71 | used by Fossil are all very simple so that with access |
| 72 | 72 | to the original content files, one can easily reconstruct |
| 73 | -the content of a baseline without the need for any | |
| 73 | +the content of a check-in without the need for any | |
| 74 | 74 | special tools or software.</p></li> |
| 75 | 75 |
| --- www/pop.wiki | |
| +++ www/pop.wiki | |
| @@ -60,15 +60,15 @@ | |
| 60 | <li><p>Two repositories for the same project can synchronize |
| 61 | their global states simply by sharing artifacts. The local |
| 62 | state of repositories is not normally synchronized or |
| 63 | shared.</p></li> |
| 64 | |
| 65 | <li><p>Every baseline has a special file at the top-level |
| 66 | named "manifest" which is an index of all other files in |
| 67 | that baseline. The manifest is automatically created and |
| 68 | maintained by the system.</p></li> |
| 69 | |
| 70 | <li><p>The <a href="fileformat.wiki">file formats</a> |
| 71 | used by Fossil are all very simple so that with access |
| 72 | to the original content files, one can easily reconstruct |
| 73 | the content of a baseline without the need for any |
| 74 | special tools or software.</p></li> |
| 75 |
| --- www/pop.wiki | |
| +++ www/pop.wiki | |
| @@ -60,15 +60,15 @@ | |
| 60 | <li><p>Two repositories for the same project can synchronize |
| 61 | their global states simply by sharing artifacts. The local |
| 62 | state of repositories is not normally synchronized or |
| 63 | shared.</p></li> |
| 64 | |
| 65 | <li><p>Every check-in has a special file at the top-level |
| 66 | named "manifest" which is an index of all other files in |
| 67 | that check-in. The manifest is automatically created and |
| 68 | maintained by the system.</p></li> |
| 69 | |
| 70 | <li><p>The <a href="fileformat.wiki">file formats</a> |
| 71 | used by Fossil are all very simple so that with access |
| 72 | to the original content files, one can easily reconstruct |
| 73 | the content of a check-in without the need for any |
| 74 | special tools or software.</p></li> |
| 75 |
+1
-1
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -163,11 +163,11 @@ | ||
| 163 | 163 | <blockquote> |
| 164 | 164 | <b>fossil update</b> <i>AID</i> |
| 165 | 165 | </blockquote> |
| 166 | 166 | |
| 167 | 167 | <p>The <i>AID</i> is some unique abbreviation to the 40-character |
| 168 | - artifact identifier (AID) for a particular baseline. If you omit | |
| 168 | + artifact identifier (AID) for a particular check-in. If you omit | |
| 169 | 169 | the <i>AID</i> fossil moves you to the |
| 170 | 170 | leaf version of the branch your are currently on. If your branch |
| 171 | 171 | has multiple leaves, you get an error - you'll have to specify the |
| 172 | 172 | leaf you want using a <i>AID</i> argument.</p> |
| 173 | 173 | |
| 174 | 174 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -163,11 +163,11 @@ | |
| 163 | <blockquote> |
| 164 | <b>fossil update</b> <i>AID</i> |
| 165 | </blockquote> |
| 166 | |
| 167 | <p>The <i>AID</i> is some unique abbreviation to the 40-character |
| 168 | artifact identifier (AID) for a particular baseline. If you omit |
| 169 | the <i>AID</i> fossil moves you to the |
| 170 | leaf version of the branch your are currently on. If your branch |
| 171 | has multiple leaves, you get an error - you'll have to specify the |
| 172 | leaf you want using a <i>AID</i> argument.</p> |
| 173 | |
| 174 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -163,11 +163,11 @@ | |
| 163 | <blockquote> |
| 164 | <b>fossil update</b> <i>AID</i> |
| 165 | </blockquote> |
| 166 | |
| 167 | <p>The <i>AID</i> is some unique abbreviation to the 40-character |
| 168 | artifact identifier (AID) for a particular check-in. If you omit |
| 169 | the <i>AID</i> fossil moves you to the |
| 170 | leaf version of the branch your are currently on. If your branch |
| 171 | has multiple leaves, you get an error - you'll have to specify the |
| 172 | leaf you want using a <i>AID</i> argument.</p> |
| 173 | |
| 174 |
+22
-22
| --- www/reference.wiki | ||
| +++ www/reference.wiki | ||
| @@ -253,13 +253,13 @@ | ||
| 253 | 253 | <hr><a href="#tof">ˆ</a> |
| 254 | 254 | <a name="rm">Usage: </a><a href="cmd_rm.wiki">fossil rm</a> FILE... or: fossil del FILE... |
| 255 | 255 | Remove one or more files from the tree. |
| 256 | 256 | |
| 257 | 257 | <hr><a href="#tof">ˆ</a> |
| 258 | - <a name="descendants">Usage: </a><a href="cmd_descendants.wiki">fossil descendants</a> ?BASELINE-ID? | |
| 259 | - Find all leaf descendants of the baseline specified or if the argument | |
| 260 | - is omitted, of the baseline currently checked out. | |
| 258 | + <a name="descendants">Usage: </a><a href="cmd_descendants.wiki">fossil descendants</a> ?CHECKIN-ID? | |
| 259 | + Find all leaf descendants of the check-in specified or if the argument | |
| 260 | + is omitted, of the check-in currently checked out. | |
| 261 | 261 | |
| 262 | 262 | <hr><a href="#tof">ˆ</a> |
| 263 | 263 | <a name="diff">Usage: </a><a href="cmd_diff.wiki">fossil diff</a>|gdiff ?-i? ?-r REVISION? FILE... |
| 264 | 264 | Show the difference between the current version of a file (as it |
| 265 | 265 | exists on disk) and that same file as it was checked out. |
| @@ -395,13 +395,13 @@ | ||
| 395 | 395 | |
| 396 | 396 | A single level of undo/redo is supported. The undo/redo stack |
| 397 | 397 | is cleared by the commit and checkout commands. |
| 398 | 398 | |
| 399 | 399 | <hr><a href="#tof">ˆ</a> |
| 400 | - <a name="revert">Usage: </a><a href="cmd_revert.wiki">fossil revert</a> ?--yes? ?-r REVISION? FILE | |
| 400 | + <a name="revert">Usage: </a><a href="cmd_revert.wiki">fossil revert</a> ?--yes? ?-r CHECKIN? FILE | |
| 401 | 401 | Revert to the current repository version of FILE, or to |
| 402 | - the version associated with baseline REVISION if the -r flag | |
| 402 | + the version associated with check-in CHECKIN if the -r flag | |
| 403 | 403 | appears. This command will confirm your operation unless the |
| 404 | 404 | file is missing or the --yes option is used. |
| 405 | 405 | |
| 406 | 406 | <hr><a href="#tof">ˆ</a> |
| 407 | 407 | <a name="server">Usage: </a><a href="cmd_server.wiki">fossil server</a> ?-P|--port TCPPORT? ?REPOSITORY? Or: fossil ui ?-P|--port TCPPORT? ?REPOSITORY? |
| @@ -479,64 +479,64 @@ | ||
| 479 | 479 | |
| 480 | 480 | <hr><a href="#tof">ˆ</a> |
| 481 | 481 | <a name="tag">Usage: </a><a href="cmd_tag.wiki">fossil tag</a> SUBCOMMAND ... |
| 482 | 482 | Run various subcommands to control tags and properties |
| 483 | 483 | |
| 484 | - fossil tag add ?--raw? TAGNAME BASELINE ?VALUE? | |
| 484 | + fossil tag add ?--raw? TAGNAME CHECK-IN ?VALUE? | |
| 485 | 485 | |
| 486 | - Add a new tag or property to BASELINE. The tag will | |
| 487 | - be usable instead of a BASELINE in commands such as | |
| 486 | + Add a new tag or property to CHECK-IN. The tag will | |
| 487 | + be usable instead of a CHECK-IN in commands such as | |
| 488 | 488 | update and merge. |
| 489 | 489 | |
| 490 | - fossil tag branch ?--raw? ?--nofork? TAGNAME BASELINE ?VALUE? | |
| 490 | + fossil tag branch ?--raw? ?--nofork? TAGNAME CHECK-IN ?VALUE? | |
| 491 | 491 | |
| 492 | 492 | A fork will be created so that the new checkin |
| 493 | - is a sibling of BASELINE and identical to it except | |
| 493 | + is a sibling of CHECK-IN and identical to it except | |
| 494 | 494 | for a generated comment. Then the new tag will |
| 495 | 495 | be added to the new checkin and propagated to |
| 496 | 496 | all direct children. Additionally all symbolic |
| 497 | - tags of that checkin inherited from BASELINE will | |
| 497 | + tags of that checkin inherited from CHECK-IN will | |
| 498 | 498 | be cancelled. |
| 499 | 499 | |
| 500 | 500 | However, if the option --nofork is given, no |
| 501 | 501 | fork will be created and the tag/property will be |
| 502 | - added to BASELINE directly. No tags will be canceled. | |
| 502 | + added to CHECK-IN directly. No tags will be canceled. | |
| 503 | 503 | |
| 504 | - fossil tag cancel ?--raw? TAGNAME BASELINE | |
| 504 | + fossil tag cancel ?--raw? TAGNAME CHECK-IN | |
| 505 | 505 | |
| 506 | - Remove the tag TAGNAME from BASELINE, and also remove | |
| 506 | + Remove the tag TAGNAME from CHECK-IN, and also remove | |
| 507 | 507 | the propagation of the tag to any descendants. |
| 508 | 508 | |
| 509 | 509 | fossil tag find ?--raw? TAGNAME |
| 510 | 510 | |
| 511 | - List all baselines that use TAGNAME | |
| 511 | + List all check-ins that use TAGNAME | |
| 512 | 512 | |
| 513 | - fossil tag list ?--raw? ?BASELINE? | |
| 513 | + fossil tag list ?--raw? ?CHECK-IN? | |
| 514 | 514 | |
| 515 | - List all tags, or if BASELINE is supplied, list | |
| 516 | - all tags and their values for BASELINE. | |
| 515 | + List all tags, or if CHECK-IN is supplied, list | |
| 516 | + all tags and their values for CHECK-IN. | |
| 517 | 517 | |
| 518 | 518 | The option --raw allows the manipulation of all types of |
| 519 | 519 | tags used for various internal purposes in fossil. You |
| 520 | 520 | should not use this option to make changes unless you are |
| 521 | 521 | sure what you are doing. |
| 522 | 522 | |
| 523 | 523 | If you need to use a tagname that might be confused with |
| 524 | - a hexadecimal baseline or artifact ID, you can explicitly | |
| 524 | + a hexadecimal check-in or artifact ID, you can explicitly | |
| 525 | 525 | disambiguate it by prefixing it with "tag:". For instance: |
| 526 | 526 | |
| 527 | 527 | fossil update decaf |
| 528 | 528 | |
| 529 | - will be taken as an artifact or baseline ID and fossil will | |
| 529 | + will be taken as an artifact or check-in ID and fossil will | |
| 530 | 530 | probably complain that no such revision was found. However |
| 531 | 531 | |
| 532 | 532 | fossil update tag:decaf |
| 533 | 533 | |
| 534 | 534 | will assume that "decaf" is a tag/branch name. |
| 535 | 535 | |
| 536 | 536 | <hr><a href="#tof">ˆ</a> |
| 537 | - <a name="timeline">Usage: </a><a href="cmd_timeline.wiki">fossil timeline</a> ?WHEN? ?BASELINE|DATETIME? ?-n|--count N? | |
| 537 | + <a name="timeline">Usage: </a><a href="cmd_timeline.wiki">fossil timeline</a> ?WHEN? ?CHECK-IN|DATETIME? ?-n|--count N? | |
| 538 | 538 | Print a summary of activity going backwards in date and time |
| 539 | 539 | specified or from the current date and time if no arguments |
| 540 | 540 | are given. Show as many as N (default 20) check-ins. The |
| 541 | 541 | WHEN argument can be any unique abbreviation of one of these |
| 542 | 542 | keywords: |
| @@ -544,11 +544,11 @@ | ||
| 544 | 544 | before |
| 545 | 545 | after |
| 546 | 546 | descendants | children |
| 547 | 547 | ancestors | parents |
| 548 | 548 | |
| 549 | - The BASELINE can be any unique prefix of 4 characters or more. | |
| 549 | + The CHECK-IN can be any unique prefix of 4 characters or more. | |
| 550 | 550 | The DATETIME should be in the ISO8601 format. For |
| 551 | 551 | examples: "2007-08-18 07:21:21". You can also say "current" |
| 552 | 552 | for the current version or "now" for the current time. |
| 553 | 553 | |
| 554 | 554 | <hr><a href="#tof">ˆ</a> |
| 555 | 555 |
| --- www/reference.wiki | |
| +++ www/reference.wiki | |
| @@ -253,13 +253,13 @@ | |
| 253 | <hr><a href="#tof">ˆ</a> |
| 254 | <a name="rm">Usage: </a><a href="cmd_rm.wiki">fossil rm</a> FILE... or: fossil del FILE... |
| 255 | Remove one or more files from the tree. |
| 256 | |
| 257 | <hr><a href="#tof">ˆ</a> |
| 258 | <a name="descendants">Usage: </a><a href="cmd_descendants.wiki">fossil descendants</a> ?BASELINE-ID? |
| 259 | Find all leaf descendants of the baseline specified or if the argument |
| 260 | is omitted, of the baseline currently checked out. |
| 261 | |
| 262 | <hr><a href="#tof">ˆ</a> |
| 263 | <a name="diff">Usage: </a><a href="cmd_diff.wiki">fossil diff</a>|gdiff ?-i? ?-r REVISION? FILE... |
| 264 | Show the difference between the current version of a file (as it |
| 265 | exists on disk) and that same file as it was checked out. |
| @@ -395,13 +395,13 @@ | |
| 395 | |
| 396 | A single level of undo/redo is supported. The undo/redo stack |
| 397 | is cleared by the commit and checkout commands. |
| 398 | |
| 399 | <hr><a href="#tof">ˆ</a> |
| 400 | <a name="revert">Usage: </a><a href="cmd_revert.wiki">fossil revert</a> ?--yes? ?-r REVISION? FILE |
| 401 | Revert to the current repository version of FILE, or to |
| 402 | the version associated with baseline REVISION if the -r flag |
| 403 | appears. This command will confirm your operation unless the |
| 404 | file is missing or the --yes option is used. |
| 405 | |
| 406 | <hr><a href="#tof">ˆ</a> |
| 407 | <a name="server">Usage: </a><a href="cmd_server.wiki">fossil server</a> ?-P|--port TCPPORT? ?REPOSITORY? Or: fossil ui ?-P|--port TCPPORT? ?REPOSITORY? |
| @@ -479,64 +479,64 @@ | |
| 479 | |
| 480 | <hr><a href="#tof">ˆ</a> |
| 481 | <a name="tag">Usage: </a><a href="cmd_tag.wiki">fossil tag</a> SUBCOMMAND ... |
| 482 | Run various subcommands to control tags and properties |
| 483 | |
| 484 | fossil tag add ?--raw? TAGNAME BASELINE ?VALUE? |
| 485 | |
| 486 | Add a new tag or property to BASELINE. The tag will |
| 487 | be usable instead of a BASELINE in commands such as |
| 488 | update and merge. |
| 489 | |
| 490 | fossil tag branch ?--raw? ?--nofork? TAGNAME BASELINE ?VALUE? |
| 491 | |
| 492 | A fork will be created so that the new checkin |
| 493 | is a sibling of BASELINE and identical to it except |
| 494 | for a generated comment. Then the new tag will |
| 495 | be added to the new checkin and propagated to |
| 496 | all direct children. Additionally all symbolic |
| 497 | tags of that checkin inherited from BASELINE will |
| 498 | be cancelled. |
| 499 | |
| 500 | However, if the option --nofork is given, no |
| 501 | fork will be created and the tag/property will be |
| 502 | added to BASELINE directly. No tags will be canceled. |
| 503 | |
| 504 | fossil tag cancel ?--raw? TAGNAME BASELINE |
| 505 | |
| 506 | Remove the tag TAGNAME from BASELINE, and also remove |
| 507 | the propagation of the tag to any descendants. |
| 508 | |
| 509 | fossil tag find ?--raw? TAGNAME |
| 510 | |
| 511 | List all baselines that use TAGNAME |
| 512 | |
| 513 | fossil tag list ?--raw? ?BASELINE? |
| 514 | |
| 515 | List all tags, or if BASELINE is supplied, list |
| 516 | all tags and their values for BASELINE. |
| 517 | |
| 518 | The option --raw allows the manipulation of all types of |
| 519 | tags used for various internal purposes in fossil. You |
| 520 | should not use this option to make changes unless you are |
| 521 | sure what you are doing. |
| 522 | |
| 523 | If you need to use a tagname that might be confused with |
| 524 | a hexadecimal baseline or artifact ID, you can explicitly |
| 525 | disambiguate it by prefixing it with "tag:". For instance: |
| 526 | |
| 527 | fossil update decaf |
| 528 | |
| 529 | will be taken as an artifact or baseline ID and fossil will |
| 530 | probably complain that no such revision was found. However |
| 531 | |
| 532 | fossil update tag:decaf |
| 533 | |
| 534 | will assume that "decaf" is a tag/branch name. |
| 535 | |
| 536 | <hr><a href="#tof">ˆ</a> |
| 537 | <a name="timeline">Usage: </a><a href="cmd_timeline.wiki">fossil timeline</a> ?WHEN? ?BASELINE|DATETIME? ?-n|--count N? |
| 538 | Print a summary of activity going backwards in date and time |
| 539 | specified or from the current date and time if no arguments |
| 540 | are given. Show as many as N (default 20) check-ins. The |
| 541 | WHEN argument can be any unique abbreviation of one of these |
| 542 | keywords: |
| @@ -544,11 +544,11 @@ | |
| 544 | before |
| 545 | after |
| 546 | descendants | children |
| 547 | ancestors | parents |
| 548 | |
| 549 | The BASELINE can be any unique prefix of 4 characters or more. |
| 550 | The DATETIME should be in the ISO8601 format. For |
| 551 | examples: "2007-08-18 07:21:21". You can also say "current" |
| 552 | for the current version or "now" for the current time. |
| 553 | |
| 554 | <hr><a href="#tof">ˆ</a> |
| 555 |
| --- www/reference.wiki | |
| +++ www/reference.wiki | |
| @@ -253,13 +253,13 @@ | |
| 253 | <hr><a href="#tof">ˆ</a> |
| 254 | <a name="rm">Usage: </a><a href="cmd_rm.wiki">fossil rm</a> FILE... or: fossil del FILE... |
| 255 | Remove one or more files from the tree. |
| 256 | |
| 257 | <hr><a href="#tof">ˆ</a> |
| 258 | <a name="descendants">Usage: </a><a href="cmd_descendants.wiki">fossil descendants</a> ?CHECKIN-ID? |
| 259 | Find all leaf descendants of the check-in specified or if the argument |
| 260 | is omitted, of the check-in currently checked out. |
| 261 | |
| 262 | <hr><a href="#tof">ˆ</a> |
| 263 | <a name="diff">Usage: </a><a href="cmd_diff.wiki">fossil diff</a>|gdiff ?-i? ?-r REVISION? FILE... |
| 264 | Show the difference between the current version of a file (as it |
| 265 | exists on disk) and that same file as it was checked out. |
| @@ -395,13 +395,13 @@ | |
| 395 | |
| 396 | A single level of undo/redo is supported. The undo/redo stack |
| 397 | is cleared by the commit and checkout commands. |
| 398 | |
| 399 | <hr><a href="#tof">ˆ</a> |
| 400 | <a name="revert">Usage: </a><a href="cmd_revert.wiki">fossil revert</a> ?--yes? ?-r CHECKIN? FILE |
| 401 | Revert to the current repository version of FILE, or to |
| 402 | the version associated with check-in CHECKIN if the -r flag |
| 403 | appears. This command will confirm your operation unless the |
| 404 | file is missing or the --yes option is used. |
| 405 | |
| 406 | <hr><a href="#tof">ˆ</a> |
| 407 | <a name="server">Usage: </a><a href="cmd_server.wiki">fossil server</a> ?-P|--port TCPPORT? ?REPOSITORY? Or: fossil ui ?-P|--port TCPPORT? ?REPOSITORY? |
| @@ -479,64 +479,64 @@ | |
| 479 | |
| 480 | <hr><a href="#tof">ˆ</a> |
| 481 | <a name="tag">Usage: </a><a href="cmd_tag.wiki">fossil tag</a> SUBCOMMAND ... |
| 482 | Run various subcommands to control tags and properties |
| 483 | |
| 484 | fossil tag add ?--raw? TAGNAME CHECK-IN ?VALUE? |
| 485 | |
| 486 | Add a new tag or property to CHECK-IN. The tag will |
| 487 | be usable instead of a CHECK-IN in commands such as |
| 488 | update and merge. |
| 489 | |
| 490 | fossil tag branch ?--raw? ?--nofork? TAGNAME CHECK-IN ?VALUE? |
| 491 | |
| 492 | A fork will be created so that the new checkin |
| 493 | is a sibling of CHECK-IN and identical to it except |
| 494 | for a generated comment. Then the new tag will |
| 495 | be added to the new checkin and propagated to |
| 496 | all direct children. Additionally all symbolic |
| 497 | tags of that checkin inherited from CHECK-IN will |
| 498 | be cancelled. |
| 499 | |
| 500 | However, if the option --nofork is given, no |
| 501 | fork will be created and the tag/property will be |
| 502 | added to CHECK-IN directly. No tags will be canceled. |
| 503 | |
| 504 | fossil tag cancel ?--raw? TAGNAME CHECK-IN |
| 505 | |
| 506 | Remove the tag TAGNAME from CHECK-IN, and also remove |
| 507 | the propagation of the tag to any descendants. |
| 508 | |
| 509 | fossil tag find ?--raw? TAGNAME |
| 510 | |
| 511 | List all check-ins that use TAGNAME |
| 512 | |
| 513 | fossil tag list ?--raw? ?CHECK-IN? |
| 514 | |
| 515 | List all tags, or if CHECK-IN is supplied, list |
| 516 | all tags and their values for CHECK-IN. |
| 517 | |
| 518 | The option --raw allows the manipulation of all types of |
| 519 | tags used for various internal purposes in fossil. You |
| 520 | should not use this option to make changes unless you are |
| 521 | sure what you are doing. |
| 522 | |
| 523 | If you need to use a tagname that might be confused with |
| 524 | a hexadecimal check-in or artifact ID, you can explicitly |
| 525 | disambiguate it by prefixing it with "tag:". For instance: |
| 526 | |
| 527 | fossil update decaf |
| 528 | |
| 529 | will be taken as an artifact or check-in ID and fossil will |
| 530 | probably complain that no such revision was found. However |
| 531 | |
| 532 | fossil update tag:decaf |
| 533 | |
| 534 | will assume that "decaf" is a tag/branch name. |
| 535 | |
| 536 | <hr><a href="#tof">ˆ</a> |
| 537 | <a name="timeline">Usage: </a><a href="cmd_timeline.wiki">fossil timeline</a> ?WHEN? ?CHECK-IN|DATETIME? ?-n|--count N? |
| 538 | Print a summary of activity going backwards in date and time |
| 539 | specified or from the current date and time if no arguments |
| 540 | are given. Show as many as N (default 20) check-ins. The |
| 541 | WHEN argument can be any unique abbreviation of one of these |
| 542 | keywords: |
| @@ -544,11 +544,11 @@ | |
| 544 | before |
| 545 | after |
| 546 | descendants | children |
| 547 | ancestors | parents |
| 548 | |
| 549 | The CHECK-IN can be any unique prefix of 4 characters or more. |
| 550 | The DATETIME should be in the ISO8601 format. For |
| 551 | examples: "2007-08-18 07:21:21". You can also say "current" |
| 552 | for the current version or "now" for the current time. |
| 553 | |
| 554 | <hr><a href="#tof">ˆ</a> |
| 555 |
+3
-3
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -76,17 +76,17 @@ | ||
| 76 | 76 | Hence bugs in fossil are unlikely to corrupt the repository in |
| 77 | 77 | a way that prevents us from extracting historical versions of |
| 78 | 78 | files. |
| 79 | 79 | </p> |
| 80 | 80 | |
| 81 | -<h2>Checksum Over All Files In A Baseline</h2> | |
| 81 | +<h2>Checksum Over All Files In A Check-in</h2> | |
| 82 | 82 | |
| 83 | 83 | <p> |
| 84 | -Manifest artifacts that define a baseline have two fields (the | |
| 84 | +Manifest artifacts that define a check-in have two fields (the | |
| 85 | 85 | R-card and Z-card) that record MD5 hashs of the manifest itself |
| 86 | 86 | and of all other files in the manifest. Prior to any check-in |
| 87 | -commit, these checksums are verified to ensure that the baseline | |
| 87 | +commit, these checksums are verified to ensure that the check-in | |
| 88 | 88 | checked in agrees exactly with what is on disk. Similarly, |
| 89 | 89 | the repository checksum is verified after a checkout to make |
| 90 | 90 | sure that the entire repository was checked out correctly. |
| 91 | 91 | Note that these added checks use a different hash (MD5 instead |
| 92 | 92 | of SHA1) in order to avoid common-mode failures in the hash |
| 93 | 93 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -76,17 +76,17 @@ | |
| 76 | Hence bugs in fossil are unlikely to corrupt the repository in |
| 77 | a way that prevents us from extracting historical versions of |
| 78 | files. |
| 79 | </p> |
| 80 | |
| 81 | <h2>Checksum Over All Files In A Baseline</h2> |
| 82 | |
| 83 | <p> |
| 84 | Manifest artifacts that define a baseline have two fields (the |
| 85 | R-card and Z-card) that record MD5 hashs of the manifest itself |
| 86 | and of all other files in the manifest. Prior to any check-in |
| 87 | commit, these checksums are verified to ensure that the baseline |
| 88 | checked in agrees exactly with what is on disk. Similarly, |
| 89 | the repository checksum is verified after a checkout to make |
| 90 | sure that the entire repository was checked out correctly. |
| 91 | Note that these added checks use a different hash (MD5 instead |
| 92 | of SHA1) in order to avoid common-mode failures in the hash |
| 93 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -76,17 +76,17 @@ | |
| 76 | Hence bugs in fossil are unlikely to corrupt the repository in |
| 77 | a way that prevents us from extracting historical versions of |
| 78 | files. |
| 79 | </p> |
| 80 | |
| 81 | <h2>Checksum Over All Files In A Check-in</h2> |
| 82 | |
| 83 | <p> |
| 84 | Manifest artifacts that define a check-in have two fields (the |
| 85 | R-card and Z-card) that record MD5 hashs of the manifest itself |
| 86 | and of all other files in the manifest. Prior to any check-in |
| 87 | commit, these checksums are verified to ensure that the check-in |
| 88 | checked in agrees exactly with what is on disk. Similarly, |
| 89 | the repository checksum is verified after a checkout to make |
| 90 | sure that the entire repository was checked out correctly. |
| 91 | Note that these added checks use a different hash (MD5 instead |
| 92 | of SHA1) in order to avoid common-mode failures in the hash |
| 93 |
+2
-2
| --- www/wikitheory.wiki | ||
| +++ www/wikitheory.wiki | ||
| @@ -33,12 +33,12 @@ | ||
| 33 | 33 | |
| 34 | 34 | |
| 35 | 35 | <h2>Stand-alone Wiki Pages</h2> |
| 36 | 36 | |
| 37 | 37 | Each wiki page has its own revision history which is independent of |
| 38 | -the sequence of baselines (check-ins). Wiki pages can branch and merge | |
| 39 | -just like baselines, though as of this writing (2008-07-29) there is | |
| 38 | +the sequence of check-ins (check-ins). Wiki pages can branch and merge | |
| 39 | +just like check-ins, though as of this writing (2008-07-29) there is | |
| 40 | 40 | no mechanism in the user interface to support branching and merging. |
| 41 | 41 | The current implementation of the wiki shows the version of the wiki |
| 42 | 42 | page that has the most recent timestamp. |
| 43 | 43 | |
| 44 | 44 | In other words, if two users make unrelated changes to the same wiki |
| 45 | 45 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -33,12 +33,12 @@ | |
| 33 | |
| 34 | |
| 35 | <h2>Stand-alone Wiki Pages</h2> |
| 36 | |
| 37 | Each wiki page has its own revision history which is independent of |
| 38 | the sequence of baselines (check-ins). Wiki pages can branch and merge |
| 39 | just like baselines, though as of this writing (2008-07-29) there is |
| 40 | no mechanism in the user interface to support branching and merging. |
| 41 | The current implementation of the wiki shows the version of the wiki |
| 42 | page that has the most recent timestamp. |
| 43 | |
| 44 | In other words, if two users make unrelated changes to the same wiki |
| 45 |
| --- www/wikitheory.wiki | |
| +++ www/wikitheory.wiki | |
| @@ -33,12 +33,12 @@ | |
| 33 | |
| 34 | |
| 35 | <h2>Stand-alone Wiki Pages</h2> |
| 36 | |
| 37 | Each wiki page has its own revision history which is independent of |
| 38 | the sequence of check-ins (check-ins). Wiki pages can branch and merge |
| 39 | just like check-ins, though as of this writing (2008-07-29) there is |
| 40 | no mechanism in the user interface to support branching and merging. |
| 41 | The current implementation of the wiki shows the version of the wiki |
| 42 | page that has the most recent timestamp. |
| 43 | |
| 44 | In other words, if two users make unrelated changes to the same wiki |
| 45 |