|
1
|
<title>Principles Of Operation</title> |
|
2
|
|
|
3
|
This page attempts to define the foundational principals upon |
|
4
|
which Fossil is built. |
|
5
|
|
|
6
|
* A project consists of source files, wiki pages, and |
|
7
|
trouble tickets, and control files (collectively "artifacts"). |
|
8
|
All historical copies of all artifacts |
|
9
|
are saved. The project maintains an audit |
|
10
|
trail. |
|
11
|
|
|
12
|
* A project resides in one or more repositories. Each |
|
13
|
repository is administered and operates independently |
|
14
|
of the others. |
|
15
|
|
|
16
|
* Each repository has both global and local state. The |
|
17
|
global state is common to all repositories (or at least |
|
18
|
has the potential to be shared in common when the |
|
19
|
repositories are fully synchronized). The local state |
|
20
|
for each repository is private to that repository. |
|
21
|
The global state represents the content of the project. |
|
22
|
The local state identifies the authorized users and |
|
23
|
access policies for a particular repository. |
|
24
|
|
|
25
|
* The global state of a repository is an unordered |
|
26
|
collection of artifacts. Each artifact is named by a |
|
27
|
cryptographic hash (SHA1 or SHA3-256) encoded in |
|
28
|
lowercase hexadecimal. |
|
29
|
In many contexts, the name can be |
|
30
|
abbreviated to a unique prefix. A five- or six-character |
|
31
|
prefix usually suffices to uniquely identify a file. |
|
32
|
|
|
33
|
* Because artifacts are named by a cryptographic hash, all artifacts |
|
34
|
are immutable. Any change to the content of an artifact also |
|
35
|
changes the hash that forms the artifacts name, thus |
|
36
|
creating a new artifact. Both the old original version of the |
|
37
|
artifact and the new change are preserved under different names. |
|
38
|
|
|
39
|
* It is theoretically possible for two artifacts with different |
|
40
|
content to share the same hash. But finding two such |
|
41
|
artifacts is so incredibly difficult and unlikely that we |
|
42
|
consider it to be an impossibility. |
|
43
|
|
|
44
|
* The signature of an artifact is the cryptographic hash of the |
|
45
|
artifact itself, exactly as it would appear in a disk file. No prefix |
|
46
|
or meta-information about the artifact is added before computing |
|
47
|
the hash. So you can |
|
48
|
always find the signature of a file by using the |
|
49
|
"sha1sum" or "sha3sum" or similar command-line utilities. |
|
50
|
|
|
51
|
* The artifacts that comprise the global state of a repository |
|
52
|
are the complete global state of that repository. The SQLite |
|
53
|
database that holds the repository contains additional information |
|
54
|
about linkages between artifacts, but all of that added information |
|
55
|
can be discarded and reconstructed by rescanning the content |
|
56
|
artifacts. |
|
57
|
|
|
58
|
* Two repositories for the same project can synchronize |
|
59
|
their global states simply by sharing artifacts. The local |
|
60
|
state of repositories is not normally synchronized or |
|
61
|
shared. |
|
62
|
|
|
63
|
* Every check-in has a special file at the top-level |
|
64
|
named "manifest" which is an index of all other files in |
|
65
|
that check-in. The manifest is automatically created and |
|
66
|
maintained by the system. |
|
67
|
|
|
68
|
* The <a href="fileformat.wiki">file formats</a> |
|
69
|
used by Fossil are all very simple so that with access |
|
70
|
to the original content files, one can easily reconstruct |
|
71
|
the content of a check-in without the need for any |
|
72
|
special tools or software. |
|
73
|
|