|
1
|
<title>Fossil Concepts</title> |
|
2
|
|
|
3
|
<h2>1.0 Introduction</h2> |
|
4
|
|
|
5
|
[./index.wiki | Fossil] is a |
|
6
|
[http://en.wikipedia.org/wiki/Software_configuration_management | software configuration management] system. |
|
7
|
Fossil is software that is designed to control and track the |
|
8
|
development of a software project and to record the history |
|
9
|
of the project. |
|
10
|
There are many such systems in use today. Fossil strives to |
|
11
|
distinguish itself from the others by being extremely simple |
|
12
|
to setup and operate. |
|
13
|
|
|
14
|
This document is intended as a quick introduction to the concepts |
|
15
|
behind Fossil. |
|
16
|
|
|
17
|
See also: |
|
18
|
|
|
19
|
* [./glossary.md | Glossary] |
|
20
|
* [./quickstart.wiki | Quick start guide] |
|
21
|
|
|
22
|
<h2>2.0 Composition Of A Project</h2> |
|
23
|
|
|
24
|
<verbatim type="pikchr float-right"> |
|
25
|
R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70% |
|
26
|
R2: cylinder same "Remote" "Repository" at 2.5*R1.wid right of R1 |
|
27
|
spline <-> from R1.e to 0.6<R1.se,R2.sw> then to 0.4<R1.ne,R2.nw> then to R2.w |
|
28
|
text "HTTPS" at .5<R1.ne,R2.nw> |
|
29
|
R3: cylinder same "Local" "Repository" fill 0x90ee90 \ |
|
30
|
at dist(R1.e,R2.w) below .5<R1,R2> |
|
31
|
spline <-> from .5<R1.s,R1.se> to 0.6<R1.s,R3.w> to 0.5<R1.se,R3.n> to .5<R3.nw,R3.n> \ |
|
32
|
"HTTPS" above behind R1 |
|
33
|
spline <-> from R2.sw to .6<R2.sw,R3.n> to .5<R2.s,R3.e> to R3.ne "HTTPS" ljust |
|
34
|
T1: line from 1.0cm heading 200 from R3.sw go 2.2cm heading 150 then 2.2cm west close \ |
|
35
|
fill 0xffff00 "Local" below "Source Tree" below |
|
36
|
T2: line from 1.0cm heading 160 from R3.se same "Local" below "Source Tree" below |
|
37
|
line <-> from R3.sw to T1.start |
|
38
|
line <-> from R3.se to T2.start |
|
39
|
</verbatim> |
|
40
|
|
|
41
|
A software project normally consists of a "source tree". |
|
42
|
A source tree is a hierarchy of files that are used to generate |
|
43
|
the end product. The source tree changes over time as the |
|
44
|
software grows and expands and as features are added and bugs |
|
45
|
are fixed. A snapshot of the source tree at any point in time |
|
46
|
is called a "version" or "revision" or a "baseline" of the product. |
|
47
|
In Fossil, we use the name "check-in". |
|
48
|
|
|
49
|
A "repository" is a database that contains copies of all historical |
|
50
|
check-ins for a project. Check-ins are normally stored in the |
|
51
|
repository in a highly space-efficient compressed format (delta encoding). |
|
52
|
But that is an implementation detail that you the user need not worry over. |
|
53
|
Think of the repository as a safe place where all your old check-ins are |
|
54
|
securely stored away and available for retrieval whenever you need |
|
55
|
them. |
|
56
|
|
|
57
|
A repository in Fossil is a single file on your disk. This file |
|
58
|
might be rather large (dozens or hundreds of megabytes for a large |
|
59
|
or long running project) but it is nevertheless just a file. You |
|
60
|
can move it around, rename it, write it out to a memory stick, or |
|
61
|
do anything else you normally do with files. |
|
62
|
|
|
63
|
Each source tree that is controlled by Fossil is associated with |
|
64
|
a single repository on the local disk drive. You can tie two or more |
|
65
|
source trees to a single repository if you want (though one |
|
66
|
tree per repository is the most common configuration.) So a |
|
67
|
single repository can be associated with many source trees, but |
|
68
|
each source tree is associated with only one repository. |
|
69
|
|
|
70
|
Fossil source trees may not overlap. A Fossil source tree is identified |
|
71
|
by a file named "_FOSSIL_" (or ".fslckout", but this article will always |
|
72
|
use the name "_FOSSIL_") in the root directory of the source tree. Every |
|
73
|
file that is a sibling of _FOSSIL_ and every file in every subfolder is |
|
74
|
considered potentially a part of the source tree. The _FOSSIL_ file |
|
75
|
contains (among other things) the pathname of the repository with which |
|
76
|
the source tree is associated. On the other hand, the repository has |
|
77
|
no record of its source trees. So you are free to delete a source tree |
|
78
|
or move it around without consequence. But if you move or rename or |
|
79
|
delete a repository, then any source trees associated with that repository |
|
80
|
will no longer be able to locate their repository and will stop working. |
|
81
|
|
|
82
|
When multiple developers are working on the same project, each |
|
83
|
developer typically has his or her own local repository and an associated |
|
84
|
source tree in which to work. Developers share their work by |
|
85
|
"syncing" the content of their local repositories either directly |
|
86
|
or through a central server. Changes can "push" from the local |
|
87
|
repository into a remote repository. Or changes can "pull" from a |
|
88
|
remote repository into a local repository. Or one can do a "sync" |
|
89
|
which is a shortcut for doing both a push and a pull at the same time. |
|
90
|
Fossil also has the concept of "cloning". A "clone" is like a "pull", |
|
91
|
except that instead of beginning with an existing local repository, |
|
92
|
a clone begins with nothing and creates a new local repository that |
|
93
|
is a duplicate of a remote repository. |
|
94
|
|
|
95
|
Communication between repositories is normally via HTTPS. (SSH is also |
|
96
|
supported, as is unencrypted HTTP.) Remote |
|
97
|
repositories are identified by URL. You can also point a web browser |
|
98
|
at a repository and get human-readable status, history, and tracking |
|
99
|
information about the project. |
|
100
|
|
|
101
|
<h3 id="artifacts">2.1 Identification Of Artifacts</h3> |
|
102
|
|
|
103
|
A particular version of a particular file is called an "artifact". Each |
|
104
|
artifact has a universally unique name which is the <a |
|
105
|
href="http://en.wikipedia.org/wiki/SHA1">SHA1</a> or <a |
|
106
|
href="http://en.wikipedia.org/wiki/SHA3">SHA3-256</a> hash of the |
|
107
|
content of that file expressed as either 40 or 64 characters of |
|
108
|
lower-case hexadecimal. (See the [./hashpolicy.wiki|hash policy |
|
109
|
document] for information on which algorithm is used, when.) Such a hash |
|
110
|
is referred to as the Artifact ID. These hash algorithms were created |
|
111
|
with Fossil's purpose in mind: to provide a highly forgery-resistant |
|
112
|
identifier for a blob of data, such as a file. Given any file, it is |
|
113
|
simple to find the artifact ID for that file. But given an artifact ID, |
|
114
|
it is computationally intractable to generate a file that will have that |
|
115
|
same artifact ID. |
|
116
|
|
|
117
|
Artifact IDs look something like this: |
|
118
|
|
|
119
|
<pre> |
|
120
|
6089f0b563a9db0a6d90682fe47fd7161ff867c8 |
|
121
|
59712614a1b3ccfd84078a37fa5b606e28434326 |
|
122
|
19dbf73078be9779edd6a0156195e610f81c94f9 |
|
123
|
b4104959a67175f02d6b415480be22a239f1f077 |
|
124
|
997c9d6ae03ad114b2b57f04e9eeef17dcb82788 |
|
125
|
</pre> |
|
126
|
|
|
127
|
When referring to an artifact using Fossil, you can use a unique |
|
128
|
prefix of the artifact ID that is four characters or longer. This saves |
|
129
|
a lot of typing. When displaying artifact IDs, Fossil will usually only |
|
130
|
show the first 10 digits since that is normally enough to uniquely |
|
131
|
identify a file. |
|
132
|
|
|
133
|
Changing (or adding or removing) a single byte in a file results |
|
134
|
in a completely different artifact ID. And since the artifact ID is the name of |
|
135
|
the artifact, making any change to a file results in a new artifact. |
|
136
|
In this way, artifacts are immutable. |
|
137
|
|
|
138
|
A repository is really just an unordered collection of |
|
139
|
artifacts. New artifacts can be added to the repository, but |
|
140
|
existing artifacts can never be removed. (Well, almost never. There |
|
141
|
is a [./shunning.wiki | "shunning"] mechanism that allows spam or other |
|
142
|
inappropriate content to be removed if absolutely necessary, but such |
|
143
|
removal is discouraged.) |
|
144
|
Fossil is designed in |
|
145
|
such a way that it can be handed a set of artifacts in any |
|
146
|
order and it can figure out the relationship between those |
|
147
|
artifacts and reconstruct the complete development history of |
|
148
|
a software project. |
|
149
|
|
|
150
|
<h3>2.2 Manifests</h3> |
|
151
|
|
|
152
|
Associated with every check-in is a special file called the |
|
153
|
[./fileformat.wiki#manifest| "manifest"]. The manifest is a |
|
154
|
listing of all other files in |
|
155
|
that source tree. The manifest contains the (complete) artifact ID |
|
156
|
of the file and the name of the file as it appears on disk, |
|
157
|
and thus serves as a mapping from artifact ID to disk name. The artifact ID |
|
158
|
of the manifest is the identifier for the entire check-in. When |
|
159
|
you look at a "timeline" of changes in Fossil, the ID associated |
|
160
|
with each check-in or commit is really just the artifact ID of the |
|
161
|
manifest for that check-in. |
|
162
|
|
|
163
|
The manifest file is not normally a real file on disk. Instead, |
|
164
|
the manifest is computed in memory by Fossil whenever it needs it. |
|
165
|
However, the "fossil setting manifest on" command will cause the |
|
166
|
manifest file to be materialized to disk, if desired. Both Fossil |
|
167
|
itself, and SQLite cause the manifest file to be materialized to disk |
|
168
|
so that the makefiles for these projects can read the manifest and |
|
169
|
embed version information in generated binaries. |
|
170
|
|
|
171
|
Fossil automatically generates a manifest whenever you "commit" |
|
172
|
a new check-in. So this is not something that you, the developer, |
|
173
|
need to worry with. The format of a manifest is intentionally |
|
174
|
designed to be simple to parse, so that if |
|
175
|
you want to read and interpret a manifest, either by hand or |
|
176
|
with a script, that is easy to do. But you will probably never |
|
177
|
need to do so. |
|
178
|
|
|
179
|
In addition to identifying all files in the check-in, a |
|
180
|
manifest also contains a check-in comment, the date and time |
|
181
|
when the check-in was established, who created the check-in, |
|
182
|
and links to other check-ins from which the current check-in |
|
183
|
is derived. There are also a couple of checksums used to verify |
|
184
|
the integrity of the check-in. And the whole manifest might |
|
185
|
be PGP clearsigned. |
|
186
|
|
|
187
|
<h3 id="keyconc">2.3 Key concepts</h3> |
|
188
|
|
|
189
|
<ul> |
|
190
|
<li>A <b>check-in</b> is a set of files arranged |
|
191
|
in a hierarchy.</li> |
|
192
|
<li>A <b>repository</b> keeps a record of historical check-ins.</li> |
|
193
|
<li>Repositories share their changes using <b>push</b>, <b>pull</b>, |
|
194
|
<b>sync</b>, and <b>clone</b>.</li> |
|
195
|
<li>A particular <u>version</u> of a particular file is an <b>artifact</b> |
|
196
|
that is identified by an <b>artifact ID</b>.</li> |
|
197
|
<li>Artifacts tracked by Fossil are inherently immutable.</li> |
|
198
|
<li>Fossil automatically generates a <b>manifest</b> file that identifies |
|
199
|
every artifact in a check-in.</li> |
|
200
|
<li>The artifact ID of the manifest is the identifier of the check-in.</li> |
|
201
|
</ul> |
|
202
|
|
|
203
|
<h2>3.0 Fossil - The Program</h2> |
|
204
|
|
|
205
|
Fossil is software. The implementation of Fossil is in the form |
|
206
|
of a single executable named "fossil" (or "fossil.exe" on Windows). |
|
207
|
To install Fossil on your system, |
|
208
|
all you have to do is obtain a copy of this one executable file (either |
|
209
|
by downloading a |
|
210
|
<a href="https://fossil-scm.org/home/uv/download.html">pre-compiled version</a> |
|
211
|
or [./build.wiki | compiling it yourself]) and then |
|
212
|
putting that file somewhere on your PATH. |
|
213
|
|
|
214
|
Fossil is completely self-contained. It is not necessary to |
|
215
|
install any other software in order to use Fossil. You do <u>not</u> need |
|
216
|
CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, Apache, PostgreSQL, MySQL, |
|
217
|
SQLite, patch, or any similar software on your system in order to use |
|
218
|
Fossil effectively. You will want to have some kind of text editor |
|
219
|
for entering check-in comments. Fossil will use whatever text editor |
|
220
|
is identified by your VISUAL environment variable. Fossil will also |
|
221
|
use GPG to clearsign your manifests if you happen to have it installed, |
|
222
|
but Fossil will skip that step if GPG is missing from your system. |
|
223
|
You can optionally set up Fossil to use external "diff" programs, |
|
224
|
though Fossil has an excellent built-in "diff" algorithm that works |
|
225
|
fine for most people. If you happen to have Tcl/Tk installed on your |
|
226
|
system, Fossil will use it to generate a graphical "diff" display when |
|
227
|
you use the --tk option to the "diff" command, but this too is entirely |
|
228
|
optional. |
|
229
|
|
|
230
|
|
|
231
|
To uninstall Fossil, simply delete the executable. |
|
232
|
|
|
233
|
To upgrade an older version of Fossil to a newer version, just |
|
234
|
replace the old executable with the new one. You might need to |
|
235
|
run "<b>fossil all rebuild</b>" to restructure your repositories after |
|
236
|
an upgrade. Running "all rebuild" never hurts, so when upgrading it |
|
237
|
is a good policy to run it even if it is not strictly necessary. |
|
238
|
|
|
239
|
To use Fossil, simply type the name of the executable in your |
|
240
|
shell, followed by one of the various built-in commands and |
|
241
|
arguments appropriate for that command. For example: |
|
242
|
|
|
243
|
<pre>fossil help</pre> |
|
244
|
|
|
245
|
In the next section, when we say things like "use the <b>help</b> |
|
246
|
command" we mean to use the command name "help" as the first |
|
247
|
token after the name of the Fossil executable, as shown above. |
|
248
|
|
|
249
|
<h2 id="workflow">4.0 Workflow</h2> |
|
250
|
|
|
251
|
<verbatim type="pikchr float-right"> |
|
252
|
down |
|
253
|
R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70% |
|
254
|
move 150% |
|
255
|
R2: cylinder same "Local" "Repository" fill 0x90ee90 |
|
256
|
move 120% |
|
257
|
T1: line go 2.2cm heading 150 then 2.2cm west close \ |
|
258
|
fill 0xffff00 "Local" below "Source Tree" below |
|
259
|
arrow from R2.n+(-0.25cm,+0.25cm) to R1.s+(-0.25cm,-0.25cm) \ |
|
260
|
"push " rjust |
|
261
|
arrow from R1.s+(+0.25cm,-0.25cm) to R2.n+(+0.25cm,+0.25cm) \ |
|
262
|
" pull" ljust " clone" ljust |
|
263
|
arrow from T1.start+(-0.25cm,+0cm) to R2.s+(-0.25cm,-0.25cm) \ |
|
264
|
"commit " rjust |
|
265
|
arrow from R2.s+(+0.25cm,-0.25cm) to T1.start+(+0.25cm,+0cm) \ |
|
266
|
" open" ljust " update" ljust " merge" ljust |
|
267
|
</verbatim> |
|
268
|
|
|
269
|
|
|
270
|
Fossil has two modes of operation: <i>"autosync"</i> and |
|
271
|
<i>"manual-merge"</i> |
|
272
|
Autosync mode is reminiscent of CVS or SVN in that it automatically |
|
273
|
keeps your changes in synchronization with your co-workers through |
|
274
|
the use of a central server. The manual-merge mode is the standard workflow |
|
275
|
for GIT or Mercurial in that your local repository develops |
|
276
|
independently of your coworkers and you share and merge your changes manually. |
|
277
|
An interesting feature of Fossil is that it supports both autosync |
|
278
|
and manual-merge work flows. |
|
279
|
|
|
280
|
The default setting for Fossil is to be in autosync mode. You |
|
281
|
can change the autosync setting or check the current autosync |
|
282
|
setting using commands like: |
|
283
|
|
|
284
|
<pre> |
|
285
|
fossil setting autosync on |
|
286
|
fossil setting autosync off |
|
287
|
fossil settings |
|
288
|
</pre> |
|
289
|
|
|
290
|
By default, Fossil runs with autosync mode turned on. The |
|
291
|
authors find that projects run more smoothly in autosync mode since |
|
292
|
autosync helps to prevent pointless forking and merging and helps keeps |
|
293
|
all collaborators working on exactly the same code rather than on their |
|
294
|
own personal forks of the code. In the author's view, manual-merge mode |
|
295
|
should be reserved for disconnected operation. |
|
296
|
|
|
297
|
<h3>4.1 Autosync Workflow</h3> |
|
298
|
|
|
299
|
<ol> |
|
300
|
<li> |
|
301
|
Establish a local repository using either the <b>new</b> command |
|
302
|
to start a new project, or the <b>clone</b> command to make a clone |
|
303
|
of a repository for an existing project. |
|
304
|
</li> |
|
305
|
|
|
306
|
<li> |
|
307
|
Establish one or more source trees using |
|
308
|
the <b>open</b> command with the name of the repository file as its |
|
309
|
argument. |
|
310
|
</li> |
|
311
|
|
|
312
|
<li> |
|
313
|
The <b>open</b> command in the previous step populates your local source |
|
314
|
tree with a copy of the latest check-in. Usually this is what you want. |
|
315
|
In the rare cases where it is not, use the <b>update</b> command to |
|
316
|
switch to a different check-in. |
|
317
|
Use the <b>timeline</b> or <b>leaves</b> commands |
|
318
|
to identify alternative check-ins to switch to. |
|
319
|
</li> |
|
320
|
|
|
321
|
<li> |
|
322
|
Edit the code. Add new files to the source tree using the <b>add</b> |
|
323
|
command. Omit files from future check-ins using the <b>rm</b> command. |
|
324
|
(Even when you remove files from future check-ins, those files continue |
|
325
|
to exist in historical check-ins.) Test your changes. |
|
326
|
</li> |
|
327
|
|
|
328
|
<li> |
|
329
|
Create a new check-in using the <b>commit</b> command. You will be prompted |
|
330
|
for a check-in comment and also for your GPG key if you have GPG installed. |
|
331
|
The commit copies the edits you have made in your local source |
|
332
|
tree into your local repository. After your commit completes, Fossil will |
|
333
|
automatically <b>push</b> your changes back to the server |
|
334
|
you cloned from or whatever server you most recently synced with. |
|
335
|
</li> |
|
336
|
|
|
337
|
<li> |
|
338
|
When your coworkers make their own changes, you can merge those changes |
|
339
|
into your local local source tree using the <b>update</b> command. |
|
340
|
In autosync mode, <b>update</b> will first go back to the server you |
|
341
|
cloned from or with which you most recently synced, and pull down all |
|
342
|
recent changes into your local repository. Then it will merge recent |
|
343
|
changes into your local source tree. If you do an <b>update</b> and |
|
344
|
find that it messes something up in your source tree (perhaps a co-worker |
|
345
|
checked in incompatible changes) you can use the <b>undo</b> command |
|
346
|
to back out the changes. |
|
347
|
</li> |
|
348
|
|
|
349
|
<li> |
|
350
|
Repeat all of the above until you have generated great software. |
|
351
|
</li> |
|
352
|
</ol> |
|
353
|
|
|
354
|
<h3>4.2 Manual-Merge Workflow</h3> |
|
355
|
|
|
356
|
When autosync is disabled, the <b>commit</b> command is decoupled from |
|
357
|
<b>push</b> and the <b>update</b> command is decoupled from <b>pull</b>. |
|
358
|
That means you have to do a few extra steps in order to accomplish the |
|
359
|
<b>push</b> and <b>pull</b> tasks manually. |
|
360
|
|
|
361
|
<ol> |
|
362
|
<li> |
|
363
|
Establish a local repository using either the <b>new</b> command |
|
364
|
to start a new project, or the <b>clone</b> command to make a clone |
|
365
|
of a repository for an existing project. The default setting for |
|
366
|
a new repository is with autosync on, so you will need to turn it off |
|
367
|
using the <b>setting autosync off</b> command with a <b>-R</b> option |
|
368
|
to specify the repository. |
|
369
|
</li> |
|
370
|
|
|
371
|
<li> |
|
372
|
Establish one or more source trees by changing your working directory |
|
373
|
to where you want the root of the source tree to be, then issuing |
|
374
|
the <b>open</b> command with the name of the repository file as its |
|
375
|
argument. |
|
376
|
</li> |
|
377
|
|
|
378
|
<li> |
|
379
|
The <b>open</b> command in the previous step populates your local source |
|
380
|
tree with a copy of the latest check-in. Usually this is what you want. |
|
381
|
In the rare cases where it is not, use the <b>update</b> command to |
|
382
|
switch to a different check-in. |
|
383
|
Use the <b>timeline</b> or <b>leaves</b> commands |
|
384
|
to identify alternative check-ins to switch to. |
|
385
|
</li> |
|
386
|
|
|
387
|
<li> |
|
388
|
Edit the code. Add new files to the source tree using the <b>add</b> |
|
389
|
command. Omit files from future check-ins using the <b>rm</b> command. |
|
390
|
(Even when you remove files from future check-ins, those files continue |
|
391
|
to exist in historical check-ins.) Test your changes. |
|
392
|
</li> |
|
393
|
|
|
394
|
<li> |
|
395
|
Create a new check-in using the <b>commit</b> command. You will be prompted |
|
396
|
for a check-in comment and also for your GPG key if you have GPG installed. |
|
397
|
The commit copies the edits you have made in your local source |
|
398
|
tree into your local repository. |
|
399
|
</li> |
|
400
|
|
|
401
|
<li> |
|
402
|
Use the <b>push</b> command to push your changes out to a server |
|
403
|
where your co-workers can access them. |
|
404
|
</li> |
|
405
|
|
|
406
|
<li> |
|
407
|
When co-workers make their own changes, use the <b>pull</b> command |
|
408
|
to pull those changes into your local repository. Note that <b>pull</b> |
|
409
|
does not move the changes into your local source tree, only into your |
|
410
|
local repository. |
|
411
|
</li> |
|
412
|
|
|
413
|
<li> |
|
414
|
Once changes are in your local repository, use |
|
415
|
the <b>update</b> command to merge them to your local source tree. |
|
416
|
If you merge in some changes and find that the changes do not work out |
|
417
|
or are not to your liking, you can back out the changes using the |
|
418
|
<b>undo</b> command. |
|
419
|
</li> |
|
420
|
|
|
421
|
<li> |
|
422
|
If two or more people ran "commit" against the same check-in, this will |
|
423
|
result in a [./branching.wiki | fork] which you may want to resolve by |
|
424
|
running <b>merge</b> followed by another <b>commit</b>. |
|
425
|
</li> |
|
426
|
|
|
427
|
<li> |
|
428
|
Repeat all of the above until you have generated great software. |
|
429
|
</li> |
|
430
|
</ol> |
|
431
|
|
|
432
|
<h2>5.0 Setting Up A Fossil Server</h2> |
|
433
|
|
|
434
|
With other configuration management software, setting up a server is |
|
435
|
a lot of work and normally takes time, patience, and a lot of system |
|
436
|
knowledge. Fossil is designed to avoid this frustration. Setting up |
|
437
|
a server with Fossil is ridiculously easy. You have four options: |
|
438
|
|
|
439
|
# <b>Stand-alone server.</b> |
|
440
|
Simply run the [/help/server|fossil server] or |
|
441
|
[/help/ui|fossil ui] command from the command-line. |
|
442
|
<br><br> |
|
443
|
# <b>CGI.</b> |
|
444
|
Install a 2-line CGI script on a CGI-enabled web-server like Apache. |
|
445
|
<br><br> |
|
446
|
# <b>SCGI.</b> |
|
447
|
Start an SCGI server using the |
|
448
|
[/help/server| fossil server --scgi] command for handling |
|
449
|
SCGI requests from web-servers like Nginx. |
|
450
|
<br><br> |
|
451
|
# <b>Inetd or Stunnel.</b> |
|
452
|
Configure programs like inetd, xinetd, or stunnel to hand off HTTP requests |
|
453
|
directly to the [/help/http|fossil http] command. |
|
454
|
|
|
455
|
See the [./server/ | How To Configure A Fossil Server] document |
|
456
|
for details. |
|
457
|
|
|
458
|
<h2>6.0 Review Of Key Concepts</h2> |
|
459
|
|
|
460
|
<ul> |
|
461
|
<li>The <b>fossil</b> program is a self-contained stand-alone executable. |
|
462
|
Just put it somewhere on your PATH to install it.</li> |
|
463
|
<li>Use the <b>clone</b> or <b>new</b> commands to create a new repository.</li> |
|
464
|
<li>Use the <b>open</b> command to create a new source tree.</li> |
|
465
|
<li>Use the <b>add</b> and <b>rm</b> or <b>delete</b> commands to add and |
|
466
|
remove files from the local source tree.</li> |
|
467
|
<li>Use the <b>commit</b> command to create a new check-in.</li> |
|
468
|
<li>Use the <b>update</b> command to merge in changes from others.</li> |
|
469
|
<li>The <b>push</b> and <b>pull</b> commands can be used to share changes |
|
470
|
manually, but these things happen automatically in the default |
|
471
|
autosync mode.</li> |
|
472
|
</ul> |
|
473
|
|