Artifact 89c914e396d6fa1fb5db5b43c794e5d407d64345
File www/cmd_update.wiki part of check-in [51868cb12f] - Changed update docs, ** ADDED A _SPECIAL_ (but MUTYPE_BLOCK) wikitag <annotation> to put html comments in wikimarkup by kkennell on 2009-01-30 21:18:10.
<h2>update</h2> <u>Updating</u> a repository is the process of applying to it changes made by external entities. Contrast this with [./cmd_commit.wiki | commit]ing a locally made change; updating is a bit like "committing" external changes to the local repo. Update <em>merges</em> changes from the repository into your checkout. That means that it won't have any effect unless there <i>are</i> changes in the repository. The only way the checkout can affect the repo (this is the local repo we're talking about) is if you do a [./cmd_commit.wiki | <code>ci</code>]. So, <code>update</code> only really makes sense if you have [./cmd_pull.wiki | <code>pull</code>]ed changes from the master repository into the local repository. <annotation> Note : really really need a quick overview of the pull-update-edit-commit-push workflow, and the shortcuts for that, and re-emphasize the role of autosync in changing the basic nature of the workflow </annotation> Local intranet <code>[./cmd_commit.wiki | commit]</code>s (by someone else) or Net <code>[./cmd_pull.wiki | pull]</code>s from a server will usually require a <code>fossil update</code> afterward, because they are likely not to be done in [./cmd_settings.wiki#autosync | autosync] mode. Local commits are likely to be made with [./cmd_settings.wiki#autosync | automatic syncing] set to "on", however, so if you don't use <b>fossil</b> for Net-wide projects you may never have to use <code>update</code>. See also: [./cmd_pull.wiki | fossil pull], [./cmd_commit.wiki | fossil commit], [./cmd_settings.wiki#autosync | fossil setting] (autosync), [./branching.wiki | <i>branching, merging, forking and tagging</i>], [./reference.wiki | Reference]