Fossil

Check-in [a9dcbf3e]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:docs
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:a9dcbf3ede5a7431659aad4956155b6846fa42d3
User & Date: kejoki 2008-12-16 05:16:57
Context
2008-12-16
18:37
Upgrade SQLite to version 3.6.7. check-in: 458331b9 user: drh tags: trunk
05:16
docs check-in: a9dcbf3e user: kejoki tags: trunk
2008-12-15
08:44
added quite a few docs to replace the mistakenly added silly templates. check-in: fb185f0a user: kejoki tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Added www/cmd_changes.wiki.







































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<h2>changes</h2>

The <code>changes</code> command is informational, it doesn't do
anything to a checked-out project, but it tells you something about
it.

This is simply a quick way to get a list of the files which are
different in the source tree (the checkout) and the repository.

There is a bit more information (was a file edited, added or
removed?, for instance).

The same information will be displayed if you
[./cmd_status.wiki | <code>&nbsp;fossil&nbsp;status&nbsp;</code>],
except there will be some additional repository information displayed
first.

See also: [./cmd_status.wiki | fossil status],
[./reference.wiki | Reference]

Added www/cmd_checkout.wiki.





























































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
<h2>checkout</h2>

The <code>checkout</code> command is how a project version goes from
the repository to the chosen project directory.

Without going into detail about getting/opening a repository, once you
have a repository and a place in which the repository has been
opened, you can "check out" a "version" of the files which make up the
repository at somewhen.

The term "checkout" is traditional in source management systems, but a
bit of an anachronism in a distributed system like <b>fossil</b>.
"Checking out" a version of a project means getting all of the source
artifacts out into the standard environment---currently the
shell/file-system.

Traditionally, the version is some "incrementing" code like
v1.3.2rcQuink or f451 or something.  In distributed SCM systems it's
some absolutely unique identifier, usually the result of a one-way
hash (SHA1, in fossil's case.)  The <b>fossil</b> term for these is
<em>artifact IDs</em>.

<code>fossil&nbsp;checkout&nbsp;</code> <i>id</i> will check out the
version corresponding to <i>id</i> into the source tree.

<code>checkout</code> requires you to pick a precise version to put into
the "on-disk" source tree, and leaves any edited files which are already
in the tree intact.

<code>update</code>, on the other hand, <em>merges</em> edits into the
version you choose (if you choose one; you can default the version.)

Since a version is required, and <b>fossil</b>'s artifact IDs are
fairly long, there are two good ways to refer to the version.  You can
use a unique proper prefix of the version (six or eight characters is
more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki |
tag] your baselines and use the tags for checkouts, reverting,
branching (tags are the best way to branch) and so forth.  Both
methods work throughout fossil.

See also [./cmd_tag.wiki | fossil tag],
[./cmd_revert.wiki | fossil revert],
[./cmd_update.wiki | fossil update],
[./cmd_push.wiki | fossil push],
[./cmd_pull.wiki | fossil pull],
[./reference.wiki | Reference]

Changes to www/cmd_new.wiki.

22
23
24
25
26
27
28

29
30
31
32
  you are adding exisiting files, you can add them individually, via
  globbing from the shell, or by adding the directory (which will add
  all of the directory's file-system descendants recursively.)

But you can't do all that until you create a repository file with
<code>new</code>.


See also: [./cmd_open.wiki | fossil open],
[./cmd_add.wiki | fossil add],
[./cmd_server.wiki | fossil ui],
[./reference.wiki | Reference]







>
|



22
23
24
25
26
27
28
29
30
31
32
33
  you are adding exisiting files, you can add them individually, via
  globbing from the shell, or by adding the directory (which will add
  all of the directory's file-system descendants recursively.)

But you can't do all that until you create a repository file with
<code>new</code>.

See also:
[./cmd_open.wiki | fossil open],
[./cmd_add.wiki | fossil add],
[./cmd_server.wiki | fossil ui],
[./reference.wiki | Reference]

Added www/cmd_status.wiki.











































































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
<h2>status</h2>

The <code>status</code> command is informational, it doesn't do anything to
a checked-out project, but it tells you something about it.

Running <code>&nbsp;fossil&nbsp;status&nbsp;</code> currently prefixes
the output of the <code>[./cmd_changes.wiki | changes]</code> command
with information about the repository and checkout.  The information
is in the form of the [./concepts.wiki#aidex | Artifact ID]s of the
server code, the checkout, and the parent (of, I <em>think</em> the
checkout.)

This is useful for getting an at-a-glance view of the state of your
project, especially in a situation where you need the artifact IDs.

Here is what I get when I issue a <code>status</code> on my local
version of the <b>fossil</b> repository as I write this:

<nowiki><pre>
   $ fossil status
   repository:   /home/me/myclone.fossil
   local-root:   /home/me/fossil/
   server-code:  99d6c9cf3f262720579db177503812814d712fc7
   checkout:     a8c3a7ea9249281e0a1fb55fb31d2ad57844f848
   parent:       21cecd209f7201f17e8a784c0d8f735603d440ae
   EDITED   www/cmd_.wiki-template
   EDITED   www/cmd_add.wiki
   EDITED   www/cmd_all.wiki
   EDITED   www/cmd_extra.wiki
   EDITED   www/cmd_ls.wiki
   EDITED   www/cmd_update.wiki
   EDITED   www/index.wiki
   $
</pre></nowiki>

Once I actually make changes to the repository (say, a
[./cmd_commit.wiki | commit]) most of that will change&#8212;all
of those files showing as "EDITED" will be checked in and won't
show up, and the artifact IDs will reflect the new state of the
repository.

If the only thing you want to see is which files in the checked-out
source tree have changed in some way, use the
[./cmd_changes.wiki | <code>changes</code>] command.

If what you want is the files in the checked-out source tree which are
<em>not</em> part of the project, use the
[./cmd_extra.wiki | <code>extra</code>] command.

See also: [./cmd_changes.wiki | fossil changes],
[./cmd_extra.wiki | fossil extra],
[./concepts.wiki | <i>Fossil concepts</i>],
[./reference.wiki | Reference]

Added www/cmd_sync.wiki.













































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<h2>sync</h2>

The <code>sync</code> command [./cmd_pull.wiki | <code>pull</code>]s and
[./cmd_push.wiki | <code>push</code>]es repository changes simultaneously.

This applies to repositories available via a URL, of course.  If your
project is strictly local you can do all of the distributed stuff as
long as you are "serving" the repository via http in some fashion, but
it's probably pointless to do so.

Assuming you aren't running <b>fossil</b> as a high-powered version of
[http://www.gnu.org/software/rcs | RCS], your use of <code>sync</code>
in your projects is up to you.  <b>fossil</b> defaults to using a
[./cmd_setting.wiki | setting] of <code>autosync</code>
If you have cloned a repository you will automatically sync with the
original if you [./cmd_commit.wiki | commit] changes to your local
version <em>unless</em> you customize your configuration.

See also: [./cmd_pull.wiki | fossil pull],
[./cmd_push.wiki | fossil push],
[./cmd_setting.wiki | fossil setting],
[./reference.wiki | Reference]

Added www/cmd_version.wiki.

























>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
<h2>version</h2>

The <code>version</code> command is informational, it doesn't do
anything to a checked-out project, but it tells you something about
it.

Issuing the version command will print out the short-form of the
artifact ID for the fossil executable.

See also: [./cmd_status.wiki | fossil status],
[./cmd_info.wiki | fossil info],
[./reference.wiki | Reference]

Changes to www/reference.wiki.

126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
...
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
    sync       Run a "sync" on all repositories

    Respositories are automatically added to the set of known repositories
    when one of the following commands against the repository: clone, info,
    pull, push, or sync

<hr><a href="#tof">&#710;</a>
    <a name="cgi">Usage: </a><a href="cmd_cgi">fossil cgi</a> SCRIPT
    The SCRIPT argument is the name of a file that is the CGI script
    that is being run.  The command name, "cgi", may be omitted if
    the GATEWAY_INTERFACE environment variable is set to "CGI" (which
    should always be the case for CGI scripts run by a webserver.)  The
    SCRIPT file should look something like this:

    #!/usr/bin/fossil
................................................................................
    repository: /home/somebody/project.db

    The second line defines the name of the repository.  After locating
    the repository, fossil will generate a webpage on stdout based on
    the values of standard CGI environment variables.

<hr><a href="#tof">&#710;</a>
    <a name="changes">Usage: </a><a href="cmd_changes">fossil changes</a>
    Report on the edit status of all files in the current checkout.
    See also the "status" and "extra" commands.

<hr><a href="#tof">&#710;</a>
    <a name="checkout">Usage: </a><a href="cmd_checkout.wiki">fossil checkout</a> VERSION ?-f|--force?
    Check out a version specified on the command-line.  This command
    will not overwrite edited files in the current checkout unless







|







 







|







126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
...
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
    sync       Run a "sync" on all repositories

    Respositories are automatically added to the set of known repositories
    when one of the following commands against the repository: clone, info,
    pull, push, or sync

<hr><a href="#tof">&#710;</a>
    <a name="cgi">Usage: </a><a href="cmd_cgi.wiki">fossil cgi</a> SCRIPT
    The SCRIPT argument is the name of a file that is the CGI script
    that is being run.  The command name, "cgi", may be omitted if
    the GATEWAY_INTERFACE environment variable is set to "CGI" (which
    should always be the case for CGI scripts run by a webserver.)  The
    SCRIPT file should look something like this:

    #!/usr/bin/fossil
................................................................................
    repository: /home/somebody/project.db

    The second line defines the name of the repository.  After locating
    the repository, fossil will generate a webpage on stdout based on
    the values of standard CGI environment variables.

<hr><a href="#tof">&#710;</a>
    <a name="changes">Usage: </a><a href="cmd_changes.wiki">fossil changes</a>
    Report on the edit status of all files in the current checkout.
    See also the "status" and "extra" commands.

<hr><a href="#tof">&#710;</a>
    <a name="checkout">Usage: </a><a href="cmd_checkout.wiki">fossil checkout</a> VERSION ?-f|--force?
    Check out a version specified on the command-line.  This command
    will not overwrite edited files in the current checkout unless