Fossil SCM
Capitalize "Fossil" in the concepts.wiki document.
Commit
b63c4300028643768ad1a1fc60e8834d64af9cee
Parent
26d0c20a37b014c…
1 file changed
+25
-25
+25
-25
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -11,11 +11,11 @@ | ||
| 11 | 11 | There are many such systems in use today. Fossil strives to |
| 12 | 12 | distinguish itself from the others by being extremely simple |
| 13 | 13 | to setup and operate. |
| 14 | 14 | |
| 15 | 15 | This document is intended as a quick introduction to the concepts |
| 16 | -behind fossil. | |
| 16 | +behind Fossil. | |
| 17 | 17 | |
| 18 | 18 | <h2>2.0 Composition Of A Project</h2> |
| 19 | 19 | <img src="concept1.gif" align="right" hspace="10"> |
| 20 | 20 | |
| 21 | 21 | A software project normally consists of a "source tree". |
| @@ -22,34 +22,34 @@ | ||
| 22 | 22 | A source tree is a hierarchy of files that are used to generate |
| 23 | 23 | the end product. The source tree changes over time as the |
| 24 | 24 | software grows and expands and as features are added and bugs |
| 25 | 25 | are fixed. A snapshot of the source tree at any point in time |
| 26 | 26 | is called a "version" or "revision" or a "baseline" of the product. |
| 27 | -In fossil, we use the name "check-in". | |
| 27 | +In Fossil, we use the name "check-in". | |
| 28 | 28 | |
| 29 | 29 | A "repository" is a database that contains copies of all historical |
| 30 | 30 | check-ins for a project. Check-ins are normally stored in the |
| 31 | 31 | repository in a highly space-efficient compressed format (delta encoding). |
| 32 | 32 | But that is an implementation detail that you the user need not worry over. |
| 33 | 33 | Think of the repository as a safe place where all your old check-ins are |
| 34 | 34 | securely stored away and available for retrieval whenever you need |
| 35 | 35 | them. |
| 36 | 36 | |
| 37 | -A repository in fossil is a single file on your disk. This file | |
| 37 | +A repository in Fossil is a single file on your disk. This file | |
| 38 | 38 | might be rather large (dozens or hundreds of megabytes for a large |
| 39 | 39 | or long running project) but it is nevertheless just a file. You |
| 40 | 40 | can move it around, rename it, write it out to a memory stick, or |
| 41 | 41 | do anything else you normally do with files. |
| 42 | 42 | |
| 43 | -Each source tree that is controlled by fossil is associated with | |
| 43 | +Each source tree that is controlled by Fossil is associated with | |
| 44 | 44 | a single repository on the local disk drive. You can tie two or more |
| 45 | 45 | source trees to a single repository if you want (though one |
| 46 | 46 | tree per repository is the most common configuration.) So a |
| 47 | 47 | single repository can be associated with many source trees, but |
| 48 | 48 | each source tree is associated with only one repository. |
| 49 | 49 | |
| 50 | -Fossil source trees may not overlap. A fossil source tree is identified | |
| 50 | +Fossil source trees may not overlap. A Fossil source tree is identified | |
| 51 | 51 | by a file named "_FOSSIL_" (or ".fslckout", but this article will always |
| 52 | 52 | use the name "_FOSSIL_") in the root directory of the source tree. Every |
| 53 | 53 | file that is a sibling of _FOSSIL_ and every file in every subfolder is |
| 54 | 54 | considered potentially a part of the source tree. The _FOSSIL_ file |
| 55 | 55 | contains (among other things) the pathname of the repository with which |
| @@ -98,13 +98,13 @@ | ||
| 98 | 98 | 19dbf73078be9779edd6a0156195e610f81c94f9<br> |
| 99 | 99 | b4104959a67175f02d6b415480be22a239f1f077<br> |
| 100 | 100 | 997c9d6ae03ad114b2b57f04e9eeef17dcb82788 |
| 101 | 101 | </b></blockquote> |
| 102 | 102 | |
| 103 | -When referring to an artifact using fossil, you can use a unique | |
| 103 | +When referring to an artifact using Fossil, you can use a unique | |
| 104 | 104 | prefix of the artifact ID that is four characters or longer. This saves |
| 105 | -a lot of typing. When displaying artifact IDs, fossil will usually only | |
| 105 | +a lot of typing. When displaying artifact IDs, Fossil will usually only | |
| 106 | 106 | show the first 10 digits since that is normally enough to uniquely |
| 107 | 107 | identify a file. |
| 108 | 108 | |
| 109 | 109 | Changing (or adding or removing) a single byte in a file results |
| 110 | 110 | in a completely different artifact ID. And since the artifact ID is the name of |
| @@ -130,11 +130,11 @@ | ||
| 130 | 130 | listing of all other files in |
| 131 | 131 | that source tree. The manifest contains the (complete) artifact ID |
| 132 | 132 | of the file and the name of the file as it appears on disk, |
| 133 | 133 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 134 | 134 | of the manifest is the identifier for the entire check-in. When |
| 135 | -you look at a "timeline" of changes in fossil, the ID associated | |
| 135 | +you look at a "timeline" of changes in Fossil, the ID associated | |
| 136 | 136 | with each check-in or commit is really just the artifact ID of the |
| 137 | 137 | manifest for that check-in. |
| 138 | 138 | |
| 139 | 139 | <p>The manifest file is not normally a real file on disk. Instead, |
| 140 | 140 | the manifest is computed in memory by Fossil whenever it needs it. |
| @@ -169,63 +169,63 @@ | ||
| 169 | 169 | <li>A <b>repository</b> keeps a record of historical check-ins.</li> |
| 170 | 170 | <li>Repositories share their changes using <b>push</b>, <b>pull</b>, |
| 171 | 171 | <b>sync</b>, and <b>clone</b>.</li> |
| 172 | 172 | <li>A particular <u>version</u> of a particular file is an <b>artifact</b> |
| 173 | 173 | that is identified by an <b>artifact ID</b>.</li> |
| 174 | -<li>Artifacts tracked by fossil are inherently immutable.</li> | |
| 174 | +<li>Artifacts tracked by Fossil are inherently immutable.</li> | |
| 175 | 175 | <li>Fossil automatically generates a <b>manifest</b> file that identifies |
| 176 | 176 | every artifact in a check-in.</li> |
| 177 | 177 | <li>The artifact ID of the manifest is the identifier of the check-in.</li> |
| 178 | 178 | </ul> |
| 179 | 179 | |
| 180 | 180 | <h2>3.0 Fossil - The Program</h2> |
| 181 | 181 | |
| 182 | -Fossil is software. The implementation of fossil is in the form | |
| 182 | +Fossil is software. The implementation of Fossil is in the form | |
| 183 | 183 | of a single executable named "fossil" (or "fossil.exe" on Windows). |
| 184 | -To install fossil on your system, | |
| 184 | +To install Fossil on your system, | |
| 185 | 185 | all you have to do is obtain a copy of this one executable file (either |
| 186 | 186 | by downloading a |
| 187 | 187 | <a href="http://www.fossil-scm.org/download.html">pre-compiled version</a> |
| 188 | 188 | or [./build.wiki | compiling it yourself]) and then |
| 189 | 189 | putting that file somewhere on your PATH. |
| 190 | 190 | |
| 191 | 191 | Fossil is completely self-contained. It is not necessary to |
| 192 | -install any other software in order to use fossil. You do <u>not</u> need | |
| 192 | +install any other software in order to use Fossil. You do <u>not</u> need | |
| 193 | 193 | CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL, |
| 194 | 194 | SQLite, patch, or any similar software on your system in order to use |
| 195 | -fossil effectively. You will want to have some kind of text editor | |
| 195 | +Fossil effectively. You will want to have some kind of text editor | |
| 196 | 196 | for entering check-in comments. Fossil will use whatever text editor |
| 197 | 197 | is identified by your VISUAL environment variable. Fossil will also |
| 198 | 198 | use GPG to clearsign your manifests if you happen to have it installed, |
| 199 | -but fossil will skip that step if GPG missing from your system. | |
| 200 | -You can optionally set up fossil to use external "diff" programs, | |
| 201 | -though fossil has an excellent built-in "diff" algorithm that works | |
| 199 | +but Fossil will skip that step if GPG missing from your system. | |
| 200 | +You can optionally set up Fossil to use external "diff" programs, | |
| 201 | +though Fossil has an excellent built-in "diff" algorithm that works | |
| 202 | 202 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 203 | 203 | system, Fossil will use it to generate a graphical "diff" display when |
| 204 | 204 | you use the --tk option to the "diff" command, but this too is entirely |
| 205 | 205 | optional. |
| 206 | 206 | |
| 207 | 207 | |
| 208 | -To uninstall fossil, simply delete the executable. | |
| 208 | +To uninstall Fossil, simply delete the executable. | |
| 209 | 209 | |
| 210 | -To upgrade an older version of fossil to a newer version, just | |
| 210 | +To upgrade an older version of Fossil to a newer version, just | |
| 211 | 211 | replace the old executable with the new one. You might need to |
| 212 | 212 | run "<b>fossil all rebuild</b>" to restructure your repositories after |
| 213 | 213 | an upgrade. Running "all rebuild" never hurts, so when upgrading it |
| 214 | 214 | is a good policy to run it even if it is not strictly necessary. |
| 215 | 215 | |
| 216 | -To use fossil, simply type the name of the executable in your | |
| 216 | +To use Fossil, simply type the name of the executable in your | |
| 217 | 217 | shell, followed by one of the various built-in commands and |
| 218 | 218 | arguments appropriate for that command. For example: |
| 219 | 219 | |
| 220 | 220 | <blockquote><b> |
| 221 | 221 | fossil help |
| 222 | 222 | </b></blockquote> |
| 223 | 223 | |
| 224 | 224 | In the next section, when we say things like "use the <b>help</b> |
| 225 | 225 | command" we mean to use the command name "help" as the first |
| 226 | -token after the name of the fossil executable, as shown above. | |
| 226 | +token after the name of the Fossil executable, as shown above. | |
| 227 | 227 | |
| 228 | 228 | <a name="workflow"></a> |
| 229 | 229 | <h2>4.0 Workflow</h2> |
| 230 | 230 | |
| 231 | 231 | <img src="concept2.gif" align="right" hspace="10"> |
| @@ -235,24 +235,24 @@ | ||
| 235 | 235 | Autosync mode is reminiscent of CVS or SVN in that it automatically |
| 236 | 236 | keeps your changes in synchronization with your co-workers through |
| 237 | 237 | the use of a central server. The manual-merge mode is the standard workflow |
| 238 | 238 | for GIT or Mercurial in that your local repository develops |
| 239 | 239 | independently of your coworkers and you share and merge your changes manually. |
| 240 | -An interesting feature of fossil is that it supports both autosync | |
| 240 | +An interesting feature of Fossil is that it supports both autosync | |
| 241 | 241 | and manual-merge work flows. |
| 242 | 242 | |
| 243 | -The default setting for fossil is to be in autosync mode. You | |
| 243 | +The default setting for Fossil is to be in autosync mode. You | |
| 244 | 244 | can change the autosync setting or check the current autosync |
| 245 | 245 | setting using commands like: |
| 246 | 246 | |
| 247 | 247 | <blockquote> |
| 248 | 248 | <b>fossil setting autosync on<br> |
| 249 | 249 | fossil setting autosync off<br> |
| 250 | 250 | <b>fossil settings</b> |
| 251 | 251 | </blockquote> |
| 252 | 252 | |
| 253 | -By default, fossil runs with autosync mode turned on. The | |
| 253 | +By default, Fossil runs with autosync mode turned on. The | |
| 254 | 254 | authors finds that projects run more smoothly in autosync mode since |
| 255 | 255 | autosync helps to prevent pointless forking and merge and helps keeps |
| 256 | 256 | all collaborators working on exactly the same code rather than on their |
| 257 | 257 | own personal forks of the code. In the author's view, manual-merge mode |
| 258 | 258 | should be reserved for disconnected operation. |
| @@ -290,11 +290,11 @@ | ||
| 290 | 290 | |
| 291 | 291 | <li> |
| 292 | 292 | Create a new check-in using the <b>commit</b> command. You will be prompted |
| 293 | 293 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 294 | 294 | The commit copies the edits you have made in your local source |
| 295 | -tree into your local repository. After your commit completes, fossil will | |
| 295 | +tree into your local repository. After your commit completes, Fossil will | |
| 296 | 296 | automatically <b>push</b> your changes back to the server |
| 297 | 297 | you cloned from or whatever server you most recently synced with. |
| 298 | 298 | </li> |
| 299 | 299 | |
| 300 | 300 | <li> |
| @@ -395,11 +395,11 @@ | ||
| 395 | 395 | <h2>5.0 Setting Up A Fossil Server</h2> |
| 396 | 396 | |
| 397 | 397 | With other configuration management software, setting up a server is |
| 398 | 398 | a lot of work and normally takes time, patience, and a lot of system |
| 399 | 399 | knowledge. Fossil is designed to avoid this frustration. Setting up |
| 400 | -a server with fossil is ridiculously easy. You have four options:</p> | |
| 400 | +a server with Fossil is ridiculously easy. You have four options:</p> | |
| 401 | 401 | |
| 402 | 402 | <ol> |
| 403 | 403 | <li><p><b>Stand-alone server.</b> |
| 404 | 404 | Simply run the [/help?cmd=server|fossil server] or |
| 405 | 405 | [/help?cmd=ui|fossil ui] command from the command-line. |
| 406 | 406 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -11,11 +11,11 @@ | |
| 11 | There are many such systems in use today. Fossil strives to |
| 12 | distinguish itself from the others by being extremely simple |
| 13 | to setup and operate. |
| 14 | |
| 15 | This document is intended as a quick introduction to the concepts |
| 16 | behind fossil. |
| 17 | |
| 18 | <h2>2.0 Composition Of A Project</h2> |
| 19 | <img src="concept1.gif" align="right" hspace="10"> |
| 20 | |
| 21 | A software project normally consists of a "source tree". |
| @@ -22,34 +22,34 @@ | |
| 22 | A source tree is a hierarchy of files that are used to generate |
| 23 | the end product. The source tree changes over time as the |
| 24 | software grows and expands and as features are added and bugs |
| 25 | are fixed. A snapshot of the source tree at any point in time |
| 26 | is called a "version" or "revision" or a "baseline" of the product. |
| 27 | In fossil, we use the name "check-in". |
| 28 | |
| 29 | A "repository" is a database that contains copies of all historical |
| 30 | check-ins for a project. Check-ins are normally stored in the |
| 31 | repository in a highly space-efficient compressed format (delta encoding). |
| 32 | But that is an implementation detail that you the user need not worry over. |
| 33 | Think of the repository as a safe place where all your old check-ins are |
| 34 | securely stored away and available for retrieval whenever you need |
| 35 | them. |
| 36 | |
| 37 | A repository in fossil is a single file on your disk. This file |
| 38 | might be rather large (dozens or hundreds of megabytes for a large |
| 39 | or long running project) but it is nevertheless just a file. You |
| 40 | can move it around, rename it, write it out to a memory stick, or |
| 41 | do anything else you normally do with files. |
| 42 | |
| 43 | Each source tree that is controlled by fossil is associated with |
| 44 | a single repository on the local disk drive. You can tie two or more |
| 45 | source trees to a single repository if you want (though one |
| 46 | tree per repository is the most common configuration.) So a |
| 47 | single repository can be associated with many source trees, but |
| 48 | each source tree is associated with only one repository. |
| 49 | |
| 50 | Fossil source trees may not overlap. A fossil source tree is identified |
| 51 | by a file named "_FOSSIL_" (or ".fslckout", but this article will always |
| 52 | use the name "_FOSSIL_") in the root directory of the source tree. Every |
| 53 | file that is a sibling of _FOSSIL_ and every file in every subfolder is |
| 54 | considered potentially a part of the source tree. The _FOSSIL_ file |
| 55 | contains (among other things) the pathname of the repository with which |
| @@ -98,13 +98,13 @@ | |
| 98 | 19dbf73078be9779edd6a0156195e610f81c94f9<br> |
| 99 | b4104959a67175f02d6b415480be22a239f1f077<br> |
| 100 | 997c9d6ae03ad114b2b57f04e9eeef17dcb82788 |
| 101 | </b></blockquote> |
| 102 | |
| 103 | When referring to an artifact using fossil, you can use a unique |
| 104 | prefix of the artifact ID that is four characters or longer. This saves |
| 105 | a lot of typing. When displaying artifact IDs, fossil will usually only |
| 106 | show the first 10 digits since that is normally enough to uniquely |
| 107 | identify a file. |
| 108 | |
| 109 | Changing (or adding or removing) a single byte in a file results |
| 110 | in a completely different artifact ID. And since the artifact ID is the name of |
| @@ -130,11 +130,11 @@ | |
| 130 | listing of all other files in |
| 131 | that source tree. The manifest contains the (complete) artifact ID |
| 132 | of the file and the name of the file as it appears on disk, |
| 133 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 134 | of the manifest is the identifier for the entire check-in. When |
| 135 | you look at a "timeline" of changes in fossil, the ID associated |
| 136 | with each check-in or commit is really just the artifact ID of the |
| 137 | manifest for that check-in. |
| 138 | |
| 139 | <p>The manifest file is not normally a real file on disk. Instead, |
| 140 | the manifest is computed in memory by Fossil whenever it needs it. |
| @@ -169,63 +169,63 @@ | |
| 169 | <li>A <b>repository</b> keeps a record of historical check-ins.</li> |
| 170 | <li>Repositories share their changes using <b>push</b>, <b>pull</b>, |
| 171 | <b>sync</b>, and <b>clone</b>.</li> |
| 172 | <li>A particular <u>version</u> of a particular file is an <b>artifact</b> |
| 173 | that is identified by an <b>artifact ID</b>.</li> |
| 174 | <li>Artifacts tracked by fossil are inherently immutable.</li> |
| 175 | <li>Fossil automatically generates a <b>manifest</b> file that identifies |
| 176 | every artifact in a check-in.</li> |
| 177 | <li>The artifact ID of the manifest is the identifier of the check-in.</li> |
| 178 | </ul> |
| 179 | |
| 180 | <h2>3.0 Fossil - The Program</h2> |
| 181 | |
| 182 | Fossil is software. The implementation of fossil is in the form |
| 183 | of a single executable named "fossil" (or "fossil.exe" on Windows). |
| 184 | To install fossil on your system, |
| 185 | all you have to do is obtain a copy of this one executable file (either |
| 186 | by downloading a |
| 187 | <a href="http://www.fossil-scm.org/download.html">pre-compiled version</a> |
| 188 | or [./build.wiki | compiling it yourself]) and then |
| 189 | putting that file somewhere on your PATH. |
| 190 | |
| 191 | Fossil is completely self-contained. It is not necessary to |
| 192 | install any other software in order to use fossil. You do <u>not</u> need |
| 193 | CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL, |
| 194 | SQLite, patch, or any similar software on your system in order to use |
| 195 | fossil effectively. You will want to have some kind of text editor |
| 196 | for entering check-in comments. Fossil will use whatever text editor |
| 197 | is identified by your VISUAL environment variable. Fossil will also |
| 198 | use GPG to clearsign your manifests if you happen to have it installed, |
| 199 | but fossil will skip that step if GPG missing from your system. |
| 200 | You can optionally set up fossil to use external "diff" programs, |
| 201 | though fossil has an excellent built-in "diff" algorithm that works |
| 202 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 203 | system, Fossil will use it to generate a graphical "diff" display when |
| 204 | you use the --tk option to the "diff" command, but this too is entirely |
| 205 | optional. |
| 206 | |
| 207 | |
| 208 | To uninstall fossil, simply delete the executable. |
| 209 | |
| 210 | To upgrade an older version of fossil to a newer version, just |
| 211 | replace the old executable with the new one. You might need to |
| 212 | run "<b>fossil all rebuild</b>" to restructure your repositories after |
| 213 | an upgrade. Running "all rebuild" never hurts, so when upgrading it |
| 214 | is a good policy to run it even if it is not strictly necessary. |
| 215 | |
| 216 | To use fossil, simply type the name of the executable in your |
| 217 | shell, followed by one of the various built-in commands and |
| 218 | arguments appropriate for that command. For example: |
| 219 | |
| 220 | <blockquote><b> |
| 221 | fossil help |
| 222 | </b></blockquote> |
| 223 | |
| 224 | In the next section, when we say things like "use the <b>help</b> |
| 225 | command" we mean to use the command name "help" as the first |
| 226 | token after the name of the fossil executable, as shown above. |
| 227 | |
| 228 | <a name="workflow"></a> |
| 229 | <h2>4.0 Workflow</h2> |
| 230 | |
| 231 | <img src="concept2.gif" align="right" hspace="10"> |
| @@ -235,24 +235,24 @@ | |
| 235 | Autosync mode is reminiscent of CVS or SVN in that it automatically |
| 236 | keeps your changes in synchronization with your co-workers through |
| 237 | the use of a central server. The manual-merge mode is the standard workflow |
| 238 | for GIT or Mercurial in that your local repository develops |
| 239 | independently of your coworkers and you share and merge your changes manually. |
| 240 | An interesting feature of fossil is that it supports both autosync |
| 241 | and manual-merge work flows. |
| 242 | |
| 243 | The default setting for fossil is to be in autosync mode. You |
| 244 | can change the autosync setting or check the current autosync |
| 245 | setting using commands like: |
| 246 | |
| 247 | <blockquote> |
| 248 | <b>fossil setting autosync on<br> |
| 249 | fossil setting autosync off<br> |
| 250 | <b>fossil settings</b> |
| 251 | </blockquote> |
| 252 | |
| 253 | By default, fossil runs with autosync mode turned on. The |
| 254 | authors finds that projects run more smoothly in autosync mode since |
| 255 | autosync helps to prevent pointless forking and merge and helps keeps |
| 256 | all collaborators working on exactly the same code rather than on their |
| 257 | own personal forks of the code. In the author's view, manual-merge mode |
| 258 | should be reserved for disconnected operation. |
| @@ -290,11 +290,11 @@ | |
| 290 | |
| 291 | <li> |
| 292 | Create a new check-in using the <b>commit</b> command. You will be prompted |
| 293 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 294 | The commit copies the edits you have made in your local source |
| 295 | tree into your local repository. After your commit completes, fossil will |
| 296 | automatically <b>push</b> your changes back to the server |
| 297 | you cloned from or whatever server you most recently synced with. |
| 298 | </li> |
| 299 | |
| 300 | <li> |
| @@ -395,11 +395,11 @@ | |
| 395 | <h2>5.0 Setting Up A Fossil Server</h2> |
| 396 | |
| 397 | With other configuration management software, setting up a server is |
| 398 | a lot of work and normally takes time, patience, and a lot of system |
| 399 | knowledge. Fossil is designed to avoid this frustration. Setting up |
| 400 | a server with fossil is ridiculously easy. You have four options:</p> |
| 401 | |
| 402 | <ol> |
| 403 | <li><p><b>Stand-alone server.</b> |
| 404 | Simply run the [/help?cmd=server|fossil server] or |
| 405 | [/help?cmd=ui|fossil ui] command from the command-line. |
| 406 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -11,11 +11,11 @@ | |
| 11 | There are many such systems in use today. Fossil strives to |
| 12 | distinguish itself from the others by being extremely simple |
| 13 | to setup and operate. |
| 14 | |
| 15 | This document is intended as a quick introduction to the concepts |
| 16 | behind Fossil. |
| 17 | |
| 18 | <h2>2.0 Composition Of A Project</h2> |
| 19 | <img src="concept1.gif" align="right" hspace="10"> |
| 20 | |
| 21 | A software project normally consists of a "source tree". |
| @@ -22,34 +22,34 @@ | |
| 22 | A source tree is a hierarchy of files that are used to generate |
| 23 | the end product. The source tree changes over time as the |
| 24 | software grows and expands and as features are added and bugs |
| 25 | are fixed. A snapshot of the source tree at any point in time |
| 26 | is called a "version" or "revision" or a "baseline" of the product. |
| 27 | In Fossil, we use the name "check-in". |
| 28 | |
| 29 | A "repository" is a database that contains copies of all historical |
| 30 | check-ins for a project. Check-ins are normally stored in the |
| 31 | repository in a highly space-efficient compressed format (delta encoding). |
| 32 | But that is an implementation detail that you the user need not worry over. |
| 33 | Think of the repository as a safe place where all your old check-ins are |
| 34 | securely stored away and available for retrieval whenever you need |
| 35 | them. |
| 36 | |
| 37 | A repository in Fossil is a single file on your disk. This file |
| 38 | might be rather large (dozens or hundreds of megabytes for a large |
| 39 | or long running project) but it is nevertheless just a file. You |
| 40 | can move it around, rename it, write it out to a memory stick, or |
| 41 | do anything else you normally do with files. |
| 42 | |
| 43 | Each source tree that is controlled by Fossil is associated with |
| 44 | a single repository on the local disk drive. You can tie two or more |
| 45 | source trees to a single repository if you want (though one |
| 46 | tree per repository is the most common configuration.) So a |
| 47 | single repository can be associated with many source trees, but |
| 48 | each source tree is associated with only one repository. |
| 49 | |
| 50 | Fossil source trees may not overlap. A Fossil source tree is identified |
| 51 | by a file named "_FOSSIL_" (or ".fslckout", but this article will always |
| 52 | use the name "_FOSSIL_") in the root directory of the source tree. Every |
| 53 | file that is a sibling of _FOSSIL_ and every file in every subfolder is |
| 54 | considered potentially a part of the source tree. The _FOSSIL_ file |
| 55 | contains (among other things) the pathname of the repository with which |
| @@ -98,13 +98,13 @@ | |
| 98 | 19dbf73078be9779edd6a0156195e610f81c94f9<br> |
| 99 | b4104959a67175f02d6b415480be22a239f1f077<br> |
| 100 | 997c9d6ae03ad114b2b57f04e9eeef17dcb82788 |
| 101 | </b></blockquote> |
| 102 | |
| 103 | When referring to an artifact using Fossil, you can use a unique |
| 104 | prefix of the artifact ID that is four characters or longer. This saves |
| 105 | a lot of typing. When displaying artifact IDs, Fossil will usually only |
| 106 | show the first 10 digits since that is normally enough to uniquely |
| 107 | identify a file. |
| 108 | |
| 109 | Changing (or adding or removing) a single byte in a file results |
| 110 | in a completely different artifact ID. And since the artifact ID is the name of |
| @@ -130,11 +130,11 @@ | |
| 130 | listing of all other files in |
| 131 | that source tree. The manifest contains the (complete) artifact ID |
| 132 | of the file and the name of the file as it appears on disk, |
| 133 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 134 | of the manifest is the identifier for the entire check-in. When |
| 135 | you look at a "timeline" of changes in Fossil, the ID associated |
| 136 | with each check-in or commit is really just the artifact ID of the |
| 137 | manifest for that check-in. |
| 138 | |
| 139 | <p>The manifest file is not normally a real file on disk. Instead, |
| 140 | the manifest is computed in memory by Fossil whenever it needs it. |
| @@ -169,63 +169,63 @@ | |
| 169 | <li>A <b>repository</b> keeps a record of historical check-ins.</li> |
| 170 | <li>Repositories share their changes using <b>push</b>, <b>pull</b>, |
| 171 | <b>sync</b>, and <b>clone</b>.</li> |
| 172 | <li>A particular <u>version</u> of a particular file is an <b>artifact</b> |
| 173 | that is identified by an <b>artifact ID</b>.</li> |
| 174 | <li>Artifacts tracked by Fossil are inherently immutable.</li> |
| 175 | <li>Fossil automatically generates a <b>manifest</b> file that identifies |
| 176 | every artifact in a check-in.</li> |
| 177 | <li>The artifact ID of the manifest is the identifier of the check-in.</li> |
| 178 | </ul> |
| 179 | |
| 180 | <h2>3.0 Fossil - The Program</h2> |
| 181 | |
| 182 | Fossil is software. The implementation of Fossil is in the form |
| 183 | of a single executable named "fossil" (or "fossil.exe" on Windows). |
| 184 | To install Fossil on your system, |
| 185 | all you have to do is obtain a copy of this one executable file (either |
| 186 | by downloading a |
| 187 | <a href="http://www.fossil-scm.org/download.html">pre-compiled version</a> |
| 188 | or [./build.wiki | compiling it yourself]) and then |
| 189 | putting that file somewhere on your PATH. |
| 190 | |
| 191 | Fossil is completely self-contained. It is not necessary to |
| 192 | install any other software in order to use Fossil. You do <u>not</u> need |
| 193 | CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL, |
| 194 | SQLite, patch, or any similar software on your system in order to use |
| 195 | Fossil effectively. You will want to have some kind of text editor |
| 196 | for entering check-in comments. Fossil will use whatever text editor |
| 197 | is identified by your VISUAL environment variable. Fossil will also |
| 198 | use GPG to clearsign your manifests if you happen to have it installed, |
| 199 | but Fossil will skip that step if GPG missing from your system. |
| 200 | You can optionally set up Fossil to use external "diff" programs, |
| 201 | though Fossil has an excellent built-in "diff" algorithm that works |
| 202 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 203 | system, Fossil will use it to generate a graphical "diff" display when |
| 204 | you use the --tk option to the "diff" command, but this too is entirely |
| 205 | optional. |
| 206 | |
| 207 | |
| 208 | To uninstall Fossil, simply delete the executable. |
| 209 | |
| 210 | To upgrade an older version of Fossil to a newer version, just |
| 211 | replace the old executable with the new one. You might need to |
| 212 | run "<b>fossil all rebuild</b>" to restructure your repositories after |
| 213 | an upgrade. Running "all rebuild" never hurts, so when upgrading it |
| 214 | is a good policy to run it even if it is not strictly necessary. |
| 215 | |
| 216 | To use Fossil, simply type the name of the executable in your |
| 217 | shell, followed by one of the various built-in commands and |
| 218 | arguments appropriate for that command. For example: |
| 219 | |
| 220 | <blockquote><b> |
| 221 | fossil help |
| 222 | </b></blockquote> |
| 223 | |
| 224 | In the next section, when we say things like "use the <b>help</b> |
| 225 | command" we mean to use the command name "help" as the first |
| 226 | token after the name of the Fossil executable, as shown above. |
| 227 | |
| 228 | <a name="workflow"></a> |
| 229 | <h2>4.0 Workflow</h2> |
| 230 | |
| 231 | <img src="concept2.gif" align="right" hspace="10"> |
| @@ -235,24 +235,24 @@ | |
| 235 | Autosync mode is reminiscent of CVS or SVN in that it automatically |
| 236 | keeps your changes in synchronization with your co-workers through |
| 237 | the use of a central server. The manual-merge mode is the standard workflow |
| 238 | for GIT or Mercurial in that your local repository develops |
| 239 | independently of your coworkers and you share and merge your changes manually. |
| 240 | An interesting feature of Fossil is that it supports both autosync |
| 241 | and manual-merge work flows. |
| 242 | |
| 243 | The default setting for Fossil is to be in autosync mode. You |
| 244 | can change the autosync setting or check the current autosync |
| 245 | setting using commands like: |
| 246 | |
| 247 | <blockquote> |
| 248 | <b>fossil setting autosync on<br> |
| 249 | fossil setting autosync off<br> |
| 250 | <b>fossil settings</b> |
| 251 | </blockquote> |
| 252 | |
| 253 | By default, Fossil runs with autosync mode turned on. The |
| 254 | authors finds that projects run more smoothly in autosync mode since |
| 255 | autosync helps to prevent pointless forking and merge and helps keeps |
| 256 | all collaborators working on exactly the same code rather than on their |
| 257 | own personal forks of the code. In the author's view, manual-merge mode |
| 258 | should be reserved for disconnected operation. |
| @@ -290,11 +290,11 @@ | |
| 290 | |
| 291 | <li> |
| 292 | Create a new check-in using the <b>commit</b> command. You will be prompted |
| 293 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 294 | The commit copies the edits you have made in your local source |
| 295 | tree into your local repository. After your commit completes, Fossil will |
| 296 | automatically <b>push</b> your changes back to the server |
| 297 | you cloned from or whatever server you most recently synced with. |
| 298 | </li> |
| 299 | |
| 300 | <li> |
| @@ -395,11 +395,11 @@ | |
| 395 | <h2>5.0 Setting Up A Fossil Server</h2> |
| 396 | |
| 397 | With other configuration management software, setting up a server is |
| 398 | a lot of work and normally takes time, patience, and a lot of system |
| 399 | knowledge. Fossil is designed to avoid this frustration. Setting up |
| 400 | a server with Fossil is ridiculously easy. You have four options:</p> |
| 401 | |
| 402 | <ol> |
| 403 | <li><p><b>Stand-alone server.</b> |
| 404 | Simply run the [/help?cmd=server|fossil server] or |
| 405 | [/help?cmd=ui|fossil ui] command from the command-line. |
| 406 |