** COMMAND: all
**
** Usage: %fossil all (list|ls|pull|push|rebuild|sync)
**
** The ~/.fossil file records the location of all repositories for a
** user.  This command performs certain operations on all repositories
** that can be useful before or after a period of disconnection operation.
**
** On Win32 systems, this file is located in %LOCALAPPDATA%, %APDDATA%
** or %HOMEPATH% and is named _fossil.
**
** Available operations are:
**
**    list | ls  Display the location of all repositories
**
**    pull       Run a "pull" operation on all repositories
**
**    push       Run a "push" on all repositories

** checkout.  You will be prompted to enter a check-in comment unless
** the comment has been specified on the command-line using "-m".
** The editor defined in the "editor" fossil option (see %fossil help set)
** will be used, or from the "VISUAL" or "EDITOR" environment variables
** (in that order) if no editor is set.
**
** You will be prompted for your GPG passphrase in order to sign the
** new manifest unless the "--nosign" option is used.  All files that
** have changed will be committed unless some subset of files is
** specified on the command line.
**
** The --branch option followed by a branch name cases the new check-in
** to be placed in the named branch.  The --bgcolor option can be followed
** by a color name (ex:  '#ffc0c0') to specify the background color of
** entries in the new branch when shown in the web timeline interface.

  blob_reset(&out);
}


/*
** COMMAND: configuration
**
** Usage: %fossil configure METHOD ... ?-R|--repository REPOSITORY?
**
** Where METHOD is one of: export import merge pull push reset.  All methods
** accept the -R or --repository option to specific a repository.
**
**    %fossil configuration export AREA FILENAME
**
**         Write to FILENAME exported configuraton information for AREA.

  db_finalize(&q);
}


/*
** COMMAND: settings
** COMMAND: unset
** %fossil settings ?PROPERTY? ?VALUE? ?-global?
** %fossil unset PROPERTY ?-global?
**
** The "settings" command with no arguments lists all properties and their
** values.  With just a property name it shows the value of that property.
** With a value argument it changes the property for the current repository.
**
** The "unset" command clears a property setting.
**
**
**    auto-captcha     If enabled, the Login page provides a button to
**                     fill in the captcha password.  Default: on
**
**    auto-shun        If enabled, automatically pull the shunning list
**                     from a server to which the client autosyncs.
**
**    autosync         If enabled, automatically pull prior to commit
**                     or update and automatically push after commit or
**                     tag or branch creation.  If the value is "pullonly"
**                     then only pull operations occur automatically.
**
**    binary-glob      The VALUE is a comma-separated list of GLOB patterns
**                     that should be treated as binary files for merging
**                     purposes.  Example:   *.xml
**
**    clearsign        When enabled, fossil will attempt to sign all commits

/*
** COMMAND: finfo
** 
** Usage: %fossil finfo FILENAME
**
** Print the change history for a single file.
**
** The "--limit N" and "--offset P" options limit the output to the first
** N changes after skipping P changes.
*/
void finfo_cmd(void){
  Stmt q;
  int vid;
  Blob dest;
  const char *zFilename;

<p>
<ol>
<p><li>
In large codes with many source files, it becomes difficult to determine
which .h files should be included in which .c files.
<p><li>
It is typically the case that a .h file will be forced to include
another .h files, which in turn might include other .h files,
and so forth.
The .c file must be recompiled when any of the .h files in this chain
are altered, but it can be difficult to determine what .h files are found
in the include chain.
A frequent Makefile error is to omit some .h files from a dependency
list even though those files are on the include file chain.

    }
  }
  bag_clear(&children);
  rebuild_step_done(rid);
}

/*
** Check to see if the "sym-trunk" tag exists.  If not, create it
** and attach it to the very first check-in.
*/
static void rebuild_tag_trunk(void){
  int tagid = db_int(0, "SELECT 1 FROM tag WHERE tagname='sym-trunk'");
  int rid;
  char *zUuid;

  ncid = db_lget_int("undo_checkout", 0);
  ucid = db_lget_int("checkout", 0);
  db_lset_int("undo_checkout", ucid);
  db_lset_int("checkout", ncid);
}

/*
** Reset the undo memory.
*/
void undo_reset(void){
  static const char zSql[] =
    @ DROP TABLE IF EXISTS undo;
    @ DROP TABLE IF EXISTS undo_vfile;
    @ DROP TABLE IF EXISTS undo_vmerge;
    @ DROP TABLE IF EXISTS undo_pending;

}

/*
** COMMAND: redo
**
** Usage: %fossil redo ?FILENAME...?
**
** Redo an update or merge or revert operation that has been undone
** by the undo command.  If FILENAME is specified then restore the changes
** associated with the named file(s) but otherwise leave the update
** or merge undone.
**
** A single level of undo/redo is supported.  The undo/redo stack
** is cleared by the commit and checkout commands.
*/

**
** Usage: %fossil update ?VERSION? ?FILES...?
**
** Change the version of the current checkout to VERSION.  Any uncommitted
** changes are retained and applied to the new checkout.
**
** The VERSION argument can be a specific version or tag or branch name.
** If the VERSION argument is omitted, then the leaf of the subtree
** that begins at the current version is used, if there is only a single
** leaf.  VERSION can also be "current" to select the leaf of the current
** version or "latest" to select the most recent check-in.
**
** If one or more FILES are listed after the VERSION then only the
** named files are candidates to be updated.  If FILES is omitted, all
** files in the current checkout are subject to be updated.

  return errCode;
}


/*
** COMMAND: revert
**
** Usage: %fossil revert ?-r REVISION? ?FILE ...?
**
** Revert to the current repository version of FILE, or to
** the version associated with baseline REVISION if the -r flag
** appears.
**
** Revert all files if no file name is provided.
**
** If a file is reverted accidently, it can be restored using
** the "fossil undo" command.
*/
void revert_cmd(void){
  const char *zFile;
  const char *zRevision;

of figure 1.  The check-in 4 of figure 3 captures addition state which
is omitted from figure 1.  Check-in 4 of figure 3 holds a copy
of Bob's local checkout before he merged in Alice's changes.  That snapshot
of Bob's changes independent of Alice's changes is omitted from figure 1.
Some people say that the approach taken in figure 3 is better because it
preserves this extra intermediate state.  Others say that the approach
taken in figure 1 is better because it is much easier to visualize a
linear line of development and because the merging happens automatically
instead of as a separate manual step.  We will not take sides in that
debate.  We will simply point out that fossil enables you to do it either way.

<h2>Forking Versus Branching</h2>

Having more than one leaf in the check-in tree is usually
considered undesirable, and so forks are usually either avoided entirely,

as 32-characters of lowercase hexadecimal.   The checksum is
computed as follows:  For each file in the check-in (except for
the manifest itself) in strict sorted lexicographical order, 
take the pathname of the file relative to the root of the
repository, append a single space (ASCII 0x20), the
size of the file in ASCII decimal, a single newline
character (ASCII 0x0A), and the complete text of the file.
Compute the MD5 checksum of the result.

A manifest might contain one or more T-cards used to set tags or
properties on the check-in.  The format of the T-card is the same as
described in <i>Control Artifacts</i> section below, except that the
second argument is the single characcter "<b>*</b>" instead of an
artifact ID.  The <b>*</b> in place of the artifact ID indicates that
the tag or property applies to the current artifact.  It is not

command to push your local commits to the remote repository. You must
of course have authorization to commit changes (access is configured
via the Admin/Users page mentioned above).

You may always use the <em>server</em> or <em>ui</em> commands to
browse a cloned repository. You can even edit create or wiki entries,
etc., and they will be pushed to the remote side the next time you
push data to the remote.

    at the next commit.

<hr><a href="#tof">&#710;</a>
    <a name="all">Usage: </a><code><a href="cmd_all.wiki">fossil all</a></code> (list|pull|push|rebuild|sync)
    The ~/.fossil file records the location of all repositories for a
    user.  This command performs certain operations on all repositories
    that can be useful before or after a period of disconnection operation.

    On Win32 systems, this file is located in %LOCALAPPDATA%, %APDDATA%
    or %HOMEPATH% and is named _fossil.

    Available operations are:

    list       Display the location of all repositories

    pull       Run a "pull" operation on all repositories

    push       Run a "push" on all repositories

<hr><a href="#tof">&#710;</a>
    <a name="commit">Usage: </a><a href="cmd_commit.wiki">fossil commit</a> ?-m COMMENT? ?--nosign? ?FILE...?    fossil ci  ...  (as above)

    Create a new version containing all of the changes in the current
    checkout.  You will be prompted to enter a check-in comment unless
    the "-m" option is used to specify a comment line.  You will be
    prompted for your GPG passphrase in order to sign the new manifest
    unless the "--nosign" option is used.  All files that have
    changed will be committed unless some subset of files is specified
    on the command line.

<hr><a href="#tof">&#710;</a>
    <a name="clean">Usage: </a><a href="cmd_clean.wiki">fossil clean</a> ?-all?
    Delete all "extra" files in the source tree.  "Extra" files are
    files that are not officially part of the checkout.  See also

    The "ui" command automatically starts a web browser after initializing
    the web server.

<hr><a href="#tof">&#710;</a>
    COMMAND: settings
    COMMAND: unset
    <a name="settings">Usage: </a><a href="cmd_setting.wiki">fossil settings</a> ?PROPERTY? ?VALUE? ?-global?
    fossil unset PROPERTY ?-global?

    The "settings" command with no arguments lists all properties and their
    values.  With just a property name it shows the value of that property.
    With a value argument it changes the property for the current repository.

    The "unset" command clears a property setting.

       autosync         If enabled, automatically pull prior to
		        commit or update and automatically push

the unchanging bag of artifacts.  The local relational database is an
implementation detail which currently happens to use SQLite.

Another way to think of the relational tables in a Fossil repository is
as an index for the artifacts.  Without the relational tables,
to generate a report like a timeline would require scanning every artifact -
the equivalent of a full table scan.  The relational tables hold pointers
the relevant artifacts in presorted order so that generating a timeline
is much more efficient.  So like an index in a relational database, the
relational tables in an Fossil repository do not add any new information,
they merely make the information in the artifacts faster and easier to
look up.

Fossil is not "based" on SQLite.  Fossil simply exploits SQLite as
a powerful tool to make the implementation easier.