Fossil SCM
Updates to the "concepts" document.
Commit
26a2b61dbd76b1043b6970dad4dd03472e1d4f4e
Parent
1db8656f68f754c…
1 file changed
+130
-61
+130
-61
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -1,5 +1,6 @@ | ||
| 1 | +<nowiki> | |
| 1 | 2 | <h1 align="center"> |
| 2 | 3 | Fossil Concepts |
| 3 | 4 | </h1> |
| 4 | 5 | |
| 5 | 6 | <h2>1.0 Introduction</h2> |
| @@ -181,11 +182,11 @@ | ||
| 181 | 182 | for entering check-in comments. Fossil will use whatever text editor |
| 182 | 183 | is identified by your VISUAL environment variable. Fossil will also |
| 183 | 184 | use GPG to clearsign your manifests if you happen to have it installed, |
| 184 | 185 | but fossil will skip that step if GPG missing from your system. |
| 185 | 186 | You can optionally set up fossil to use external "diff" programs, |
| 186 | -though a perfectly functional "diff" algorithm is built it and works | |
| 187 | +though SQLite has an excellent built-in "diff" algorithm that works | |
| 187 | 188 | fine for most people.</p> |
| 188 | 189 | |
| 189 | 190 | <p>To uninstall fossil, simply delete the executable.</p> |
| 190 | 191 | |
| 191 | 192 | <p>To upgrade an older version of fossil to a newer version, just |
| @@ -192,11 +193,11 @@ | ||
| 192 | 193 | replace the old executable with the new one. You might need to |
| 193 | 194 | run a one-time command to restructure your repositories after |
| 194 | 195 | an upgrade. Check the instructions that come with the upgrade |
| 195 | 196 | for details.</p> |
| 196 | 197 | |
| 197 | -<p>To use fossil, simply type the name of executable in your | |
| 198 | +<p>To use fossil, simply type the name of the executable in your | |
| 198 | 199 | shell, followed by one of the various built-in commands and |
| 199 | 200 | arguments appropriate for that command. For example:</p> |
| 200 | 201 | |
| 201 | 202 | <blockquote><b> |
| 202 | 203 | fossil help |
| @@ -207,10 +208,34 @@ | ||
| 207 | 208 | token after the name of the fossil executable, as shown above.</p> |
| 208 | 209 | |
| 209 | 210 | <h2>4.0 Workflow</h2> |
| 210 | 211 | |
| 211 | 212 | <img src="concept2.gif" align="right" hspace="10"> |
| 213 | + | |
| 214 | +<p>Fossil has two modes of operation: "autosync" and "non-autosync". | |
| 215 | +Autosync mode works something like CVS or SVN in that it automatically | |
| 216 | +keeps your work in sync with the central server. Non-autosync is | |
| 217 | +more like GIT, or Bitkeeper in that your local repository develops | |
| 218 | +independently of your coworkers and you share your changes manually. | |
| 219 | +The interesting thing about fossil is that it supports both autosync | |
| 220 | +and non-autosync work flows.</p> | |
| 221 | + | |
| 222 | +<p>The default setting for fossil is to be in autosync mode. You | |
| 223 | +can change the autosync setting or check the current autosync | |
| 224 | +setting using commands like:</p> | |
| 225 | + | |
| 226 | +<blockquote> | |
| 227 | +<b>fossil setting autosync on<br> | |
| 228 | +fossil setting autosync off<br> | |
| 229 | +<b>fossil settings</b> | |
| 230 | +</blockquote> | |
| 231 | + | |
| 232 | +<p>By default, fossil runs with autosync mode turned on. The | |
| 233 | +authors find that projects run more smoothly when autosync is only | |
| 234 | +disabled when off-network.</p> | |
| 235 | + | |
| 236 | +<h3>4.1 Autosync Workflow</h3> | |
| 212 | 237 | |
| 213 | 238 | <ol> |
| 214 | 239 | <li><p> |
| 215 | 240 | Establish a local repository using either the <b>new</b> command |
| 216 | 241 | to start a new project, or the <b>clone</b> command to make a clone |
| @@ -223,14 +248,80 @@ | ||
| 223 | 248 | the <b>open</b> command with the name of the repository file as its |
| 224 | 249 | argument. |
| 225 | 250 | </p></li> |
| 226 | 251 | |
| 227 | 252 | <li><p> |
| 228 | -Use the <b>update</b> command followed by a UUID to cause your | |
| 229 | -source tree to change to the baseline identified by that UUID. | |
| 230 | -The <b>timeline</b> or <b>leaves</b> commands might help you to | |
| 231 | -identify an appropriate baseline. | |
| 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. | |
| 274 | +</p></li> | |
| 275 | + | |
| 276 | +<li><p> | |
| 277 | +When your coworkers make their own changes, you can merge those changes | |
| 278 | +into your local local source tree using the <b>update</b> command. | |
| 279 | +In autosync mode, <b>update</b> will first go back to the server you | |
| 280 | +cloned from or with which you most recently synced, and pull down all | |
| 281 | +recent changes into your local repository. Then it will merge recent | |
| 282 | +changes into your local source tree. If you do an <b>update</b> and | |
| 283 | +find that it messes something up in your source tree (perhaps a co-worker | |
| 284 | +checked in incompatible changes) you can use the <b>undo</b> command | |
| 285 | +to back out the changes. | |
| 286 | +</p></li> | |
| 287 | + | |
| 288 | +<li><p> | |
| 289 | +Repeat all of the above until you have generated great software. | |
| 290 | +</p></li> | |
| 291 | +</ol> | |
| 292 | + | |
| 293 | +<h3>4.2 Non-Autosync Workflow</h3> | |
| 294 | + | |
| 295 | +<p>When autosync is disabled, the <b>commit</b> command is decoupled from | |
| 296 | +<b>push</b> and the <b>update</b> command is decoupled from <b>pull</b>. | |
| 297 | +That means you have to do a few extra steps in order to accomplish the | |
| 298 | +<b>push</b> and <b>pull</b> tasks manually.</p> | |
| 299 | + | |
| 300 | +<ol> | |
| 301 | +<li><p> | |
| 302 | +Establish a local repository using either the <b>new</b> command | |
| 303 | +to start a new project, or the <b>clone</b> command to make a clone | |
| 304 | +of a repository for an existing project. The default setting for | |
| 305 | +a new repository is with autosync on, so you will need to turn it off | |
| 306 | +using the <b>setting autosync off</b> command with a <b>-R</b> option | |
| 307 | +to specify the repository. | |
| 308 | +</p></li> | |
| 309 | + | |
| 310 | +<li><p> | |
| 311 | +Establish one or more source trees by changing your working directory | |
| 312 | +to where you want the root of the source tree to be, then issuing | |
| 313 | +the <b>open</b> command with the name of the repository file as its | |
| 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. | |
| 232 | 323 | </p></li> |
| 233 | 324 | |
| 234 | 325 | <li><p> |
| 235 | 326 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 236 | 327 | command. Omit files from future baselines using the <b>rm</b> command. |
| @@ -243,72 +334,34 @@ | ||
| 243 | 334 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 244 | 335 | The commit copies the edits you have made in your local source |
| 245 | 336 | tree into your local repository. |
| 246 | 337 | </p></li> |
| 247 | 338 | |
| 248 | -<li><p> | |
| 249 | -Share your changes with others using the <b>push</b> command. | |
| 250 | -Push causes the edits you committed into your local repository to be | |
| 251 | -pushed out into other repositories. | |
| 252 | -</p></li> | |
| 253 | - | |
| 254 | -<li><p> | |
| 255 | -When your coworkers make their own changes, you can pull those changes | |
| 256 | -into your local repository using the <b>pull</b> command. Note that | |
| 257 | -the pull command only pulls the changes into your local repository, | |
| 258 | -not into your local source tree. | |
| 259 | -</p></li> | |
| 260 | - | |
| 261 | -<li><p> | |
| 262 | -After the changes of others are in your local repository, you | |
| 263 | -can move them into your local source tree using <b>update</b>. If | |
| 264 | -you have made parallel | |
| 265 | -changes, you can merge your changes together with your coworkers changes | |
| 266 | -by do an <b>update</b> to your latest baseline, then doing a | |
| 267 | -<b>merge</b> with your coworkers latest baseline. After your | |
| 268 | -verify that the merged code is still functional, you can <b>commit</b> | |
| 269 | -a new baseline that contains both yours and your coworkers changes | |
| 270 | -and then push the new baseline back to your coworker. | |
| 339 | +<li><p>Use the <b>push</b> command to push your changes out to a server | |
| 340 | +where your co-workers can access them. | |
| 341 | +</p></li> | |
| 342 | + | |
| 343 | +<li><p> | |
| 344 | +When co-workers make their own changes, use the <b>pull</b> command | |
| 345 | +to pull those changes into your local repository. Note that <b>pull</b> | |
| 346 | +does not move the changes into your local source tree, only into your | |
| 347 | +local repository. | |
| 348 | +</p></li> | |
| 349 | + | |
| 350 | +<li><p> | |
| 351 | +Once changes are in your local repository, use | |
| 352 | +use the <b>update</b> command to merge them to your local source tree. | |
| 353 | +If you merge in some changes and find that the changes do not work out | |
| 354 | +or are not to your liking, you can back out the changes using the | |
| 355 | +<b>undo</b> command. | |
| 271 | 356 | </p></li> |
| 272 | 357 | |
| 273 | 358 | <li><p> |
| 274 | 359 | Repeat all of the above until you have generated great software. |
| 275 | 360 | </p></li> |
| 276 | 361 | </ol> |
| 277 | 362 | |
| 278 | -<h3>4.1 Variations</h3> | |
| 279 | - | |
| 280 | -<p>The <b>settings</b> lets you view and modify various operating | |
| 281 | -properties of fossil. Among the available settings is "autosync" | |
| 282 | -mode. When autosync is enabled, the push and pull of content from | |
| 283 | -your local server is largely automated. Whenever you use the <b>update</b> | |
| 284 | -command, fossil first does a <b>pull</b> to see if other users have | |
| 285 | -perhaps added new baselines to the central repository. When you | |
| 286 | -<b>commit</b>, fossil also does a <b>pull</b> and issues a warning | |
| 287 | -if your check-in would cause a fork. After a <b>commit</b>, fossil | |
| 288 | -automatically does a <b>push</b> to send your changes up to the | |
| 289 | -central server.</p> | |
| 290 | - | |
| 291 | -<p>With autosync enabled, fossil works like | |
| 292 | -<a href="http://www.nongnu.org/cvs/">CVS</a> or | |
| 293 | -<a href="http://subversion.tigris.org/">Subversion</a>. | |
| 294 | -When autosync disabled, fossil works more like | |
| 295 | -<a href="http://monotone.ca/">Monotone</a>, | |
| 296 | -<a href="http://git.or.cz">GIT</a>, or | |
| 297 | -<a href="http://www.selenic.com/mercurial/wiki/">Mercurial</a>. | |
| 298 | -The fun thing about fossil is that it will work either | |
| 299 | -way, depending on your needs of the moment. You can freely switch | |
| 300 | -between these operating modes using commands like:</p> | |
| 301 | - | |
| 302 | -<blockquote> | |
| 303 | -<b>fossil setting autosync off<br /> | |
| 304 | -fossil setting autosync on</b> | |
| 305 | -</blockquote> | |
| 306 | - | |
| 307 | -<p>For additional information about autosync and other settings | |
| 308 | -using the <b>help</b> command.</p> | |
| 309 | - | |
| 310 | 363 | <h2>5.0 Setting Up A Fossil Server</h2> |
| 311 | 364 | |
| 312 | 365 | <p>With other configuration management software, setting up a server is |
| 313 | 366 | a lot of work and normally takes time, patience, and a lot of system |
| 314 | 367 | knowledge. Fossil is designed to avoid this frustration. Setting up |
| @@ -368,5 +421,21 @@ | ||
| 368 | 421 | drops all privileges prior to reading any information from the client. |
| 369 | 422 | Since fossil is a stand-alone program, you do not need to put anything |
| 370 | 423 | in the chroot jail with fossil in order for it to do its job.</p> |
| 371 | 424 | </li> |
| 372 | 425 | </ol> |
| 426 | + | |
| 427 | +<h2>6.0 Review Of Key Concepts</h2> | |
| 428 | + | |
| 429 | +<ul> | |
| 430 | +<li>The <b>fossil</b> program is a self-contained stand-alone executable. | |
| 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> | |
| 373 | 442 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -1,5 +1,6 @@ | |
| 1 | <h1 align="center"> |
| 2 | Fossil Concepts |
| 3 | </h1> |
| 4 | |
| 5 | <h2>1.0 Introduction</h2> |
| @@ -181,11 +182,11 @@ | |
| 181 | for entering check-in comments. Fossil will use whatever text editor |
| 182 | is identified by your VISUAL environment variable. Fossil will also |
| 183 | use GPG to clearsign your manifests if you happen to have it installed, |
| 184 | but fossil will skip that step if GPG missing from your system. |
| 185 | You can optionally set up fossil to use external "diff" programs, |
| 186 | though a perfectly functional "diff" algorithm is built it and works |
| 187 | fine for most people.</p> |
| 188 | |
| 189 | <p>To uninstall fossil, simply delete the executable.</p> |
| 190 | |
| 191 | <p>To upgrade an older version of fossil to a newer version, just |
| @@ -192,11 +193,11 @@ | |
| 192 | replace the old executable with the new one. You might need to |
| 193 | run a one-time command to restructure your repositories after |
| 194 | an upgrade. Check the instructions that come with the upgrade |
| 195 | for details.</p> |
| 196 | |
| 197 | <p>To use fossil, simply type the name of executable in your |
| 198 | shell, followed by one of the various built-in commands and |
| 199 | arguments appropriate for that command. For example:</p> |
| 200 | |
| 201 | <blockquote><b> |
| 202 | fossil help |
| @@ -207,10 +208,34 @@ | |
| 207 | token after the name of the fossil executable, as shown above.</p> |
| 208 | |
| 209 | <h2>4.0 Workflow</h2> |
| 210 | |
| 211 | <img src="concept2.gif" align="right" hspace="10"> |
| 212 | |
| 213 | <ol> |
| 214 | <li><p> |
| 215 | Establish a local repository using either the <b>new</b> command |
| 216 | to start a new project, or the <b>clone</b> command to make a clone |
| @@ -223,14 +248,80 @@ | |
| 223 | the <b>open</b> command with the name of the repository file as its |
| 224 | argument. |
| 225 | </p></li> |
| 226 | |
| 227 | <li><p> |
| 228 | Use the <b>update</b> command followed by a UUID to cause your |
| 229 | source tree to change to the baseline identified by that UUID. |
| 230 | The <b>timeline</b> or <b>leaves</b> commands might help you to |
| 231 | identify an appropriate baseline. |
| 232 | </p></li> |
| 233 | |
| 234 | <li><p> |
| 235 | Edit the code. Add new files to the source tree using the <b>add</b> |
| 236 | command. Omit files from future baselines using the <b>rm</b> command. |
| @@ -243,72 +334,34 @@ | |
| 243 | for a check-in comment and also for your GPG key if you have GPG installed. |
| 244 | The commit copies the edits you have made in your local source |
| 245 | tree into your local repository. |
| 246 | </p></li> |
| 247 | |
| 248 | <li><p> |
| 249 | Share your changes with others using the <b>push</b> command. |
| 250 | Push causes the edits you committed into your local repository to be |
| 251 | pushed out into other repositories. |
| 252 | </p></li> |
| 253 | |
| 254 | <li><p> |
| 255 | When your coworkers make their own changes, you can pull those changes |
| 256 | into your local repository using the <b>pull</b> command. Note that |
| 257 | the pull command only pulls the changes into your local repository, |
| 258 | not into your local source tree. |
| 259 | </p></li> |
| 260 | |
| 261 | <li><p> |
| 262 | After the changes of others are in your local repository, you |
| 263 | can move them into your local source tree using <b>update</b>. If |
| 264 | you have made parallel |
| 265 | changes, you can merge your changes together with your coworkers changes |
| 266 | by do an <b>update</b> to your latest baseline, then doing a |
| 267 | <b>merge</b> with your coworkers latest baseline. After your |
| 268 | verify that the merged code is still functional, you can <b>commit</b> |
| 269 | a new baseline that contains both yours and your coworkers changes |
| 270 | and then push the new baseline back to your coworker. |
| 271 | </p></li> |
| 272 | |
| 273 | <li><p> |
| 274 | Repeat all of the above until you have generated great software. |
| 275 | </p></li> |
| 276 | </ol> |
| 277 | |
| 278 | <h3>4.1 Variations</h3> |
| 279 | |
| 280 | <p>The <b>settings</b> lets you view and modify various operating |
| 281 | properties of fossil. Among the available settings is "autosync" |
| 282 | mode. When autosync is enabled, the push and pull of content from |
| 283 | your local server is largely automated. Whenever you use the <b>update</b> |
| 284 | command, fossil first does a <b>pull</b> to see if other users have |
| 285 | perhaps added new baselines to the central repository. When you |
| 286 | <b>commit</b>, fossil also does a <b>pull</b> and issues a warning |
| 287 | if your check-in would cause a fork. After a <b>commit</b>, fossil |
| 288 | automatically does a <b>push</b> to send your changes up to the |
| 289 | central server.</p> |
| 290 | |
| 291 | <p>With autosync enabled, fossil works like |
| 292 | <a href="http://www.nongnu.org/cvs/">CVS</a> or |
| 293 | <a href="http://subversion.tigris.org/">Subversion</a>. |
| 294 | When autosync disabled, fossil works more like |
| 295 | <a href="http://monotone.ca/">Monotone</a>, |
| 296 | <a href="http://git.or.cz">GIT</a>, or |
| 297 | <a href="http://www.selenic.com/mercurial/wiki/">Mercurial</a>. |
| 298 | The fun thing about fossil is that it will work either |
| 299 | way, depending on your needs of the moment. You can freely switch |
| 300 | between these operating modes using commands like:</p> |
| 301 | |
| 302 | <blockquote> |
| 303 | <b>fossil setting autosync off<br /> |
| 304 | fossil setting autosync on</b> |
| 305 | </blockquote> |
| 306 | |
| 307 | <p>For additional information about autosync and other settings |
| 308 | using the <b>help</b> command.</p> |
| 309 | |
| 310 | <h2>5.0 Setting Up A Fossil Server</h2> |
| 311 | |
| 312 | <p>With other configuration management software, setting up a server is |
| 313 | a lot of work and normally takes time, patience, and a lot of system |
| 314 | knowledge. Fossil is designed to avoid this frustration. Setting up |
| @@ -368,5 +421,21 @@ | |
| 368 | drops all privileges prior to reading any information from the client. |
| 369 | Since fossil is a stand-alone program, you do not need to put anything |
| 370 | in the chroot jail with fossil in order for it to do its job.</p> |
| 371 | </li> |
| 372 | </ol> |
| 373 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -1,5 +1,6 @@ | |
| 1 | <nowiki> |
| 2 | <h1 align="center"> |
| 3 | Fossil Concepts |
| 4 | </h1> |
| 5 | |
| 6 | <h2>1.0 Introduction</h2> |
| @@ -181,11 +182,11 @@ | |
| 182 | for entering check-in comments. Fossil will use whatever text editor |
| 183 | is identified by your VISUAL environment variable. Fossil will also |
| 184 | use GPG to clearsign your manifests if you happen to have it installed, |
| 185 | but fossil will skip that step if GPG missing from your system. |
| 186 | You can optionally set up fossil to use external "diff" programs, |
| 187 | though SQLite has an excellent built-in "diff" algorithm that works |
| 188 | fine for most people.</p> |
| 189 | |
| 190 | <p>To uninstall fossil, simply delete the executable.</p> |
| 191 | |
| 192 | <p>To upgrade an older version of fossil to a newer version, just |
| @@ -192,11 +193,11 @@ | |
| 193 | replace the old executable with the new one. You might need to |
| 194 | run a one-time command to restructure your repositories after |
| 195 | an upgrade. Check the instructions that come with the upgrade |
| 196 | for details.</p> |
| 197 | |
| 198 | <p>To use fossil, simply type the name of the executable in your |
| 199 | shell, followed by one of the various built-in commands and |
| 200 | arguments appropriate for that command. For example:</p> |
| 201 | |
| 202 | <blockquote><b> |
| 203 | fossil help |
| @@ -207,10 +208,34 @@ | |
| 208 | token after the name of the fossil executable, as shown above.</p> |
| 209 | |
| 210 | <h2>4.0 Workflow</h2> |
| 211 | |
| 212 | <img src="concept2.gif" align="right" hspace="10"> |
| 213 | |
| 214 | <p>Fossil has two modes of operation: "autosync" and "non-autosync". |
| 215 | Autosync mode works something like CVS or SVN in that it automatically |
| 216 | keeps your work in sync with the central server. Non-autosync is |
| 217 | more like GIT, or Bitkeeper in that your local repository develops |
| 218 | independently of your coworkers and you share your changes manually. |
| 219 | The interesting thing about fossil is that it supports both autosync |
| 220 | and non-autosync work flows.</p> |
| 221 | |
| 222 | <p>The default setting for fossil is to be in autosync mode. You |
| 223 | can change the autosync setting or check the current autosync |
| 224 | setting using commands like:</p> |
| 225 | |
| 226 | <blockquote> |
| 227 | <b>fossil setting autosync on<br> |
| 228 | fossil setting autosync off<br> |
| 229 | <b>fossil settings</b> |
| 230 | </blockquote> |
| 231 | |
| 232 | <p>By default, fossil runs with autosync mode turned on. The |
| 233 | authors find that projects run more smoothly when autosync is only |
| 234 | disabled when off-network.</p> |
| 235 | |
| 236 | <h3>4.1 Autosync Workflow</h3> |
| 237 | |
| 238 | <ol> |
| 239 | <li><p> |
| 240 | Establish a local repository using either the <b>new</b> command |
| 241 | to start a new project, or the <b>clone</b> command to make a clone |
| @@ -223,14 +248,80 @@ | |
| 248 | the <b>open</b> command with the name of the repository file as its |
| 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. |
| 274 | </p></li> |
| 275 | |
| 276 | <li><p> |
| 277 | When your coworkers make their own changes, you can merge those changes |
| 278 | into your local local source tree using the <b>update</b> command. |
| 279 | In autosync mode, <b>update</b> will first go back to the server you |
| 280 | cloned from or with which you most recently synced, and pull down all |
| 281 | recent changes into your local repository. Then it will merge recent |
| 282 | changes into your local source tree. If you do an <b>update</b> and |
| 283 | find that it messes something up in your source tree (perhaps a co-worker |
| 284 | checked in incompatible changes) you can use the <b>undo</b> command |
| 285 | to back out the changes. |
| 286 | </p></li> |
| 287 | |
| 288 | <li><p> |
| 289 | Repeat all of the above until you have generated great software. |
| 290 | </p></li> |
| 291 | </ol> |
| 292 | |
| 293 | <h3>4.2 Non-Autosync Workflow</h3> |
| 294 | |
| 295 | <p>When autosync is disabled, the <b>commit</b> command is decoupled from |
| 296 | <b>push</b> and the <b>update</b> command is decoupled from <b>pull</b>. |
| 297 | That means you have to do a few extra steps in order to accomplish the |
| 298 | <b>push</b> and <b>pull</b> tasks manually.</p> |
| 299 | |
| 300 | <ol> |
| 301 | <li><p> |
| 302 | Establish a local repository using either the <b>new</b> command |
| 303 | to start a new project, or the <b>clone</b> command to make a clone |
| 304 | of a repository for an existing project. The default setting for |
| 305 | a new repository is with autosync on, so you will need to turn it off |
| 306 | using the <b>setting autosync off</b> command with a <b>-R</b> option |
| 307 | to specify the repository. |
| 308 | </p></li> |
| 309 | |
| 310 | <li><p> |
| 311 | Establish one or more source trees by changing your working directory |
| 312 | to where you want the root of the source tree to be, then issuing |
| 313 | the <b>open</b> command with the name of the repository file as its |
| 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. |
| @@ -243,72 +334,34 @@ | |
| 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 | |
| 339 | <li><p>Use the <b>push</b> command to push your changes out to a server |
| 340 | where your co-workers can access them. |
| 341 | </p></li> |
| 342 | |
| 343 | <li><p> |
| 344 | When co-workers make their own changes, use the <b>pull</b> command |
| 345 | to pull those changes into your local repository. Note that <b>pull</b> |
| 346 | does not move the changes into your local source tree, only into your |
| 347 | local repository. |
| 348 | </p></li> |
| 349 | |
| 350 | <li><p> |
| 351 | Once changes are in your local repository, use |
| 352 | use the <b>update</b> command to merge them to your local source tree. |
| 353 | If you merge in some changes and find that the changes do not work out |
| 354 | or are not to your liking, you can back out the changes using the |
| 355 | <b>undo</b> command. |
| 356 | </p></li> |
| 357 | |
| 358 | <li><p> |
| 359 | Repeat all of the above until you have generated great software. |
| 360 | </p></li> |
| 361 | </ol> |
| 362 | |
| 363 | <h2>5.0 Setting Up A Fossil Server</h2> |
| 364 | |
| 365 | <p>With other configuration management software, setting up a server is |
| 366 | a lot of work and normally takes time, patience, and a lot of system |
| 367 | knowledge. Fossil is designed to avoid this frustration. Setting up |
| @@ -368,5 +421,21 @@ | |
| 421 | drops all privileges prior to reading any information from the client. |
| 422 | Since fossil is a stand-alone program, you do not need to put anything |
| 423 | in the chroot jail with fossil in order for it to do its job.</p> |
| 424 | </li> |
| 425 | </ol> |
| 426 | |
| 427 | <h2>6.0 Review Of Key Concepts</h2> |
| 428 | |
| 429 | <ul> |
| 430 | <li>The <b>fossil</b> program is a self-contained stand-alone executable. |
| 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 |