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
|
Fossil has been hosting itself and many other projects for
years now. Many bugs have been encountered. But, thanks in large
part to the defensive measures described here, no data has been
lost. The integrity checks are doing their job well.</p>
<h2>Atomic Check-ins With Rollback</h2>
The fossil repository is an
<a href="http://www.sqlite.org/">SQLite version 3</a> database file.
SQLite is very mature and stable and has been in wide-spread use for many
years, so we are confident it will not cause repository
corruption. SQLite
databases do not corrupt even if a program or system crash or power
failure occurs in the middle of the update. If some kind of crash
does occur in the middle of a change, then all the changes are rolled
back the next time that the database is accessed.
A check-in operation in fossil makes many changes to the repository
database. But all these changes happen within a single transaction.
If something goes wrong in the middle of the commit, then the transaction
is rolled back and the database is unchanged.
<h2>Verification Of Delta Encodings Prior To Transaction Commit</h2>
The content files that comprise the global state of a fossil repository
are stored in the repository as a tree. The leaves of the tree are
stored as zlib-compressed BLOBs. Interior nodes are deltas from their
|
|
|
>
>
|
>
|
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
|
Fossil has been hosting itself and many other projects for
years now. Many bugs have been encountered. But, thanks in large
part to the defensive measures described here, no data has been
lost. The integrity checks are doing their job well.</p>
<h2>Atomic Check-ins With Rollback</h2>
The fossil repository is stored in an
<a href="http://www.sqlite.org/">SQLite</a> database file.
([./tech_overview.wiki | Addition information] about the repository
file format.)
SQLite is very mature and stable and has been in wide-spread use for many
years, so we are confident it will not cause repository
corruption. SQLite
databases do not corrupt even if a program or system crash or power
failure occurs in the middle of the update. If some kind of crash
does occur in the middle of a change, then all the changes are rolled
back the next time that the database is accessed.
A check-in operation in fossil makes many changes to the repository
database. But all these changes happen within a single transaction.
If something goes wrong in the middle of the commit, even if that something
is a power failure or OS crash, then the transaction
is rolled back and the database is unchanged.
<h2>Verification Of Delta Encodings Prior To Transaction Commit</h2>
The content files that comprise the global state of a fossil repository
are stored in the repository as a tree. The leaves of the tree are
stored as zlib-compressed BLOBs. Interior nodes are deltas from their
|
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
files.
<h2>Checksum Over All Files In A Check-in</h2>
Manifest artifacts that define a check-in have two fields (the
R-card and Z-card) that record MD5 hashes of the manifest itself
and of all other files in the manifest. Prior to any check-in
commit, these checksums are verified to ensure that the check-in
checked in agrees exactly with what is on disk. Similarly,
the repository checksum is verified after a checkout to make
sure that the entire repository was checked out correctly.
Note that these added checks use a different hash (MD5 instead
of SHA1) in order to avoid common-mode failures in the hash
algorithm implementation.
|
|
|
|
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
files.
<h2>Checksum Over All Files In A Check-in</h2>
Manifest artifacts that define a check-in have two fields (the
R-card and Z-card) that record MD5 hashes of the manifest itself
and of all other files in the manifest. Prior to any check-in
commit, these checksums are verified to ensure that the checkin
agrees exactly with what is on disk. Similarly,
the repository checksum is verified after a checkout to make
sure that the entire repository was checked out correctly.
Note that these added checks use a different hash (MD5 instead
of SHA1) in order to avoid common-mode failures in the hash
algorithm implementation.
|