Differences From:
File www/concepts.html part of check-in [469002ccdf] - Added navbar to all pages, linking back to the index. Fixed typo in the index page. by aku on 2007-09-12 04:19:59. Also file www/concepts.html part of check-in [bbcb6326c9] - Pulled in the navbar and timeline changes. by aku on 2007-09-17 00:58:51. [view]
To:
File www/concepts.html part of check-in [f9f7cf5684] - The autosync setting understands values like "on", "off", "true", and "false" in addition to 0 and 1. Updates to the documentation. by drh on 2007-11-24 02:45:39. [view]
@@ -76,9 +76,9 @@ which is a shortcut for doing both a push and a pull at the same time. Fossil also has the concept of "cloning". A "clone" is like a "pull", except that instead of beginning with an existing local repository, a clone begins with nothing and creates a new local repository that -is a replicate of a remote repository.</p> +is a duplicate of a remote repository.</p> <p>Communication between repositories is via HTTP. Remote repositories are identified by URL. You can also point a webbrowser at a repository and get human-readable status, history, and tracking @@ -141,11 +141,12 @@ <p>Fossil automatically generates a manifest whenever you "commit" a new baseline. So this is not something that you, the developer, need to worry with. The format of a manifest is intentionally -designed to be simple to parse, however, so that if +designed to be simple to parse, so that if you want to read and interpret a manifest, either by hand or -with a script, that is easy to do.</p> +with a script, that is easy to do. But you will probably never +need to do so.</p> <p>In addition to identifying all files in the baseline, a manifest also contains a check-in comment, the date and time when the baseline was established, who created the baseline, @@ -275,8 +276,40 @@ <li><p> Repeat all of the above until you have generated great software. </p></li> </ol> + +<h3>4.1 Variations</h3> + +<p>The <b>settings</b> lets you view and modify various operating +properties of fossil. Among the available settings is "autosync" +mode. When autosync is enabled, the push and pull of content from +your local server is largely automated. Whenever you use the <b>update</b> +command, fossil first does a <b>pull</b> to see if other users have +perhaps added new baselines to the central repository. When you +<b>commit</b>, fossil also does a <b>pull</b> and issues a warning +if your check-in would cause a fork. After a <b>commit</b>, fossil +automatically does a <b>push</b> to send your changes up to the +central server.</p> + +<p>With autosync enabled, fossil works like +<a href="http://www.nongnu.org/cvs/">CVS</a> or +<a href="http://subversion.tigris.org/">Subversion</a>. +When autosync disabled, fossil works more like +<a href="http://monotone.ca/">Monotone</a>, +<a href="http://git.or.cz">GIT</a>, or +<a href="http://www.selenic.com/mercurial/wiki/">Mercurial</a>. +The fun thing about fossil is that it will work either +way, depending on your needs of the moment. You can freely switch +between these operating modes using commands like:</p> + +<blockquote> +<b>fossil setting autosync off<br /> +fossil setting autosync on</b> +</blockquote> + +<p>For additional information about autosync and other settings +using the <b>help</b> command.</p> <h2>5.0 Setting Up A Fossil Server</h2> <p>With other configuration management software, setting up a server is