Fossil SCM
Documentation updates - remove references to SHA1 as the only available hash algorithm.
Commit
796db898c7c5b2ccedf5bf3c36912ac56608baa1
Parent
0f5dc21e337eb44…
13 files changed
+3
-3
+4
-4
+1
-1
+4
-9
+2
-1
+7
-6
+5
-5
+1
-1
+14
-14
+3
-2
+2
-1
+1
-1
+4
-3
+3
-3
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -10,14 +10,14 @@ | ||
| 10 | 10 | Figure 1 |
| 11 | 11 | </td></tr></table> |
| 12 | 12 | |
| 13 | 13 | Each circle represents a check-in. For the sake of clarity, the check-ins |
| 14 | 14 | are given small consecutive numbers. In a real system, of course, the |
| 15 | -check-in numbers would be 40-character SHA1 hashes since it is not possible | |
| 15 | +check-in numbers would be long hexadecimal hashes since it is not possible | |
| 16 | 16 | to allocate collision-free sequential numbers in a distributed system. |
| 17 | 17 | But as sequential numbers are easier to read, we will substitute them for |
| 18 | -the 40-character SHA1 hashes in this document. | |
| 18 | +the long hashes in this document. | |
| 19 | 19 | |
| 20 | 20 | The arrows in figure 1 show the evolution of a project. The initial |
| 21 | 21 | check-in is 1. Check-in 2 is derived from 1. In other words, check-in 2 |
| 22 | 22 | was created by making edits to check-in 1 and then committing those edits. |
| 23 | 23 | We say that 2 is a <i>child</i> of 1 |
| @@ -193,11 +193,11 @@ | ||
| 193 | 193 | figure 5, that initial check-in is check-in 1. The <b>branch</b> tag |
| 194 | 194 | tells (by its value) what branch the check-in is a member of. |
| 195 | 195 | The default branch is called "trunk." All tags that begin with "<b>sym-</b>" |
| 196 | 196 | are symbolic name tags. When a symbolic name tag is attached to a |
| 197 | 197 | check-in, that allows you to refer to that check-in by its symbolic |
| 198 | -name rather than by its 40-character SHA1 hash name. When a symbolic name | |
| 198 | +name rather than by its hexadecimal hash name. When a symbolic name | |
| 199 | 199 | tag propagates (as does the <b>sym-trunk</b> tag) then referring to that |
| 200 | 200 | name is the same as referring to the most recent check-in with that name. |
| 201 | 201 | Thus the two tags on check-in 1 cause all descendants to be in the |
| 202 | 202 | "trunk" branch and to have the symbolic name "trunk." |
| 203 | 203 | |
| 204 | 204 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -10,14 +10,14 @@ | |
| 10 | Figure 1 |
| 11 | </td></tr></table> |
| 12 | |
| 13 | Each circle represents a check-in. For the sake of clarity, the check-ins |
| 14 | are given small consecutive numbers. In a real system, of course, the |
| 15 | check-in numbers would be 40-character SHA1 hashes since it is not possible |
| 16 | to allocate collision-free sequential numbers in a distributed system. |
| 17 | But as sequential numbers are easier to read, we will substitute them for |
| 18 | the 40-character SHA1 hashes in this document. |
| 19 | |
| 20 | The arrows in figure 1 show the evolution of a project. The initial |
| 21 | check-in is 1. Check-in 2 is derived from 1. In other words, check-in 2 |
| 22 | was created by making edits to check-in 1 and then committing those edits. |
| 23 | We say that 2 is a <i>child</i> of 1 |
| @@ -193,11 +193,11 @@ | |
| 193 | figure 5, that initial check-in is check-in 1. The <b>branch</b> tag |
| 194 | tells (by its value) what branch the check-in is a member of. |
| 195 | The default branch is called "trunk." All tags that begin with "<b>sym-</b>" |
| 196 | are symbolic name tags. When a symbolic name tag is attached to a |
| 197 | check-in, that allows you to refer to that check-in by its symbolic |
| 198 | name rather than by its 40-character SHA1 hash name. When a symbolic name |
| 199 | tag propagates (as does the <b>sym-trunk</b> tag) then referring to that |
| 200 | name is the same as referring to the most recent check-in with that name. |
| 201 | Thus the two tags on check-in 1 cause all descendants to be in the |
| 202 | "trunk" branch and to have the symbolic name "trunk." |
| 203 | |
| 204 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -10,14 +10,14 @@ | |
| 10 | Figure 1 |
| 11 | </td></tr></table> |
| 12 | |
| 13 | Each circle represents a check-in. For the sake of clarity, the check-ins |
| 14 | are given small consecutive numbers. In a real system, of course, the |
| 15 | check-in numbers would be long hexadecimal hashes since it is not possible |
| 16 | to allocate collision-free sequential numbers in a distributed system. |
| 17 | But as sequential numbers are easier to read, we will substitute them for |
| 18 | the long hashes in this document. |
| 19 | |
| 20 | The arrows in figure 1 show the evolution of a project. The initial |
| 21 | check-in is 1. Check-in 2 is derived from 1. In other words, check-in 2 |
| 22 | was created by making edits to check-in 1 and then committing those edits. |
| 23 | We say that 2 is a <i>child</i> of 1 |
| @@ -193,11 +193,11 @@ | |
| 193 | figure 5, that initial check-in is check-in 1. The <b>branch</b> tag |
| 194 | tells (by its value) what branch the check-in is a member of. |
| 195 | The default branch is called "trunk." All tags that begin with "<b>sym-</b>" |
| 196 | are symbolic name tags. When a symbolic name tag is attached to a |
| 197 | check-in, that allows you to refer to that check-in by its symbolic |
| 198 | name rather than by its hexadecimal hash name. When a symbolic name |
| 199 | tag propagates (as does the <b>sym-trunk</b> tag) then referring to that |
| 200 | name is the same as referring to the most recent check-in with that name. |
| 201 | Thus the two tags on check-in 1 cause all descendants to be in the |
| 202 | "trunk" branch and to have the symbolic name "trunk." |
| 203 | |
| 204 |
+4
-4
| --- www/checkin_names.wiki | ||
| +++ www/checkin_names.wiki | ||
| @@ -4,11 +4,11 @@ | ||
| 4 | 4 | <tr><td> |
| 5 | 5 | <h3>Executive Summary</h3> |
| 6 | 6 | <p>A check-in can be identified using any of the following |
| 7 | 7 | names: |
| 8 | 8 | <ul> |
| 9 | -<li> SHA1 hash prefix | |
| 9 | +<li> Cryptographic hash prefix | |
| 10 | 10 | <li> Tag or branchname |
| 11 | 11 | <li> Timestamp: <i>YYYY-MM-DD HH:MM:SS</i> |
| 12 | 12 | <li> <i>tag-name</i> <big><b>:</b></big> <i>timestamp</i> |
| 13 | 13 | <li> <b>root :</b> <i>branchname</i> |
| 14 | 14 | <li> Special names: |
| @@ -44,19 +44,19 @@ | ||
| 44 | 44 | Fossil provides a variety of ways to specify a check-in. This |
| 45 | 45 | document describes the various methods. |
| 46 | 46 | |
| 47 | 47 | <h2>Canonical Check-in Name</h2> |
| 48 | 48 | |
| 49 | -The canonical name of a check-in is the SHA1 hash of its | |
| 50 | -[./fileformat.wiki#manifest | manifest] expressed as a 40-character | |
| 49 | +The canonical name of a check-in is the hash of its | |
| 50 | +[./fileformat.wiki#manifest | manifest] expressed as a 40-or-more character | |
| 51 | 51 | lowercase hexadecimal number. For example: |
| 52 | 52 | |
| 53 | 53 | <blockquote><pre> |
| 54 | 54 | fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9 |
| 55 | 55 | </pre></blockquote> |
| 56 | 56 | |
| 57 | -The full 40-character SHA1 hash is unwieldy to remember and type, though, | |
| 57 | +The full 40+ character hash is unwieldy to remember and type, though, | |
| 58 | 58 | so Fossil also accepts a unique prefix of the hash, using any combination |
| 59 | 59 | of upper and lower case letters, as long as the prefix is at least 4 |
| 60 | 60 | characters long. Hence the following commands all |
| 61 | 61 | accomplish the same thing as the above: |
| 62 | 62 | |
| 63 | 63 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -4,11 +4,11 @@ | |
| 4 | <tr><td> |
| 5 | <h3>Executive Summary</h3> |
| 6 | <p>A check-in can be identified using any of the following |
| 7 | names: |
| 8 | <ul> |
| 9 | <li> SHA1 hash prefix |
| 10 | <li> Tag or branchname |
| 11 | <li> Timestamp: <i>YYYY-MM-DD HH:MM:SS</i> |
| 12 | <li> <i>tag-name</i> <big><b>:</b></big> <i>timestamp</i> |
| 13 | <li> <b>root :</b> <i>branchname</i> |
| 14 | <li> Special names: |
| @@ -44,19 +44,19 @@ | |
| 44 | Fossil provides a variety of ways to specify a check-in. This |
| 45 | document describes the various methods. |
| 46 | |
| 47 | <h2>Canonical Check-in Name</h2> |
| 48 | |
| 49 | The canonical name of a check-in is the SHA1 hash of its |
| 50 | [./fileformat.wiki#manifest | manifest] expressed as a 40-character |
| 51 | lowercase hexadecimal number. For example: |
| 52 | |
| 53 | <blockquote><pre> |
| 54 | fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9 |
| 55 | </pre></blockquote> |
| 56 | |
| 57 | The full 40-character SHA1 hash is unwieldy to remember and type, though, |
| 58 | so Fossil also accepts a unique prefix of the hash, using any combination |
| 59 | of upper and lower case letters, as long as the prefix is at least 4 |
| 60 | characters long. Hence the following commands all |
| 61 | accomplish the same thing as the above: |
| 62 | |
| 63 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -4,11 +4,11 @@ | |
| 4 | <tr><td> |
| 5 | <h3>Executive Summary</h3> |
| 6 | <p>A check-in can be identified using any of the following |
| 7 | names: |
| 8 | <ul> |
| 9 | <li> Cryptographic hash prefix |
| 10 | <li> Tag or branchname |
| 11 | <li> Timestamp: <i>YYYY-MM-DD HH:MM:SS</i> |
| 12 | <li> <i>tag-name</i> <big><b>:</b></big> <i>timestamp</i> |
| 13 | <li> <b>root :</b> <i>branchname</i> |
| 14 | <li> Special names: |
| @@ -44,19 +44,19 @@ | |
| 44 | Fossil provides a variety of ways to specify a check-in. This |
| 45 | document describes the various methods. |
| 46 | |
| 47 | <h2>Canonical Check-in Name</h2> |
| 48 | |
| 49 | The canonical name of a check-in is the hash of its |
| 50 | [./fileformat.wiki#manifest | manifest] expressed as a 40-or-more character |
| 51 | lowercase hexadecimal number. For example: |
| 52 | |
| 53 | <blockquote><pre> |
| 54 | fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9 |
| 55 | </pre></blockquote> |
| 56 | |
| 57 | The full 40+ character hash is unwieldy to remember and type, though, |
| 58 | so Fossil also accepts a unique prefix of the hash, using any combination |
| 59 | of upper and lower case letters, as long as the prefix is at least 4 |
| 60 | characters long. Hence the following commands all |
| 61 | accomplish the same thing as the above: |
| 62 | |
| 63 |
+1
-1
| --- www/customskin.md | ||
| +++ www/customskin.md | ||
| @@ -177,11 +177,11 @@ | ||
| 177 | 177 | |
| 178 | 178 | * **csrf_token** - A token used to prevent cross-site request forgery. |
| 179 | 179 | |
| 180 | 180 | * **release_version** - The release version of Fossil. Ex: "1.31" |
| 181 | 181 | |
| 182 | - * **manifest_version** - A prefix on the SHA1 check-in hash of the | |
| 182 | + * **manifest_version** - A prefix on the check-in hash of the | |
| 183 | 183 | specific version of fossil that is running. Ex: "\[47bb6432a1\]" |
| 184 | 184 | |
| 185 | 185 | * **manifest_date** - The date of the source-code check-in for the |
| 186 | 186 | version of fossil that is running. |
| 187 | 187 | |
| 188 | 188 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -177,11 +177,11 @@ | |
| 177 | |
| 178 | * **csrf_token** - A token used to prevent cross-site request forgery. |
| 179 | |
| 180 | * **release_version** - The release version of Fossil. Ex: "1.31" |
| 181 | |
| 182 | * **manifest_version** - A prefix on the SHA1 check-in hash of the |
| 183 | specific version of fossil that is running. Ex: "\[47bb6432a1\]" |
| 184 | |
| 185 | * **manifest_date** - The date of the source-code check-in for the |
| 186 | version of fossil that is running. |
| 187 | |
| 188 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -177,11 +177,11 @@ | |
| 177 | |
| 178 | * **csrf_token** - A token used to prevent cross-site request forgery. |
| 179 | |
| 180 | * **release_version** - The release version of Fossil. Ex: "1.31" |
| 181 | |
| 182 | * **manifest_version** - A prefix on the check-in hash of the |
| 183 | specific version of fossil that is running. Ex: "\[47bb6432a1\]" |
| 184 | |
| 185 | * **manifest_date** - The date of the source-code check-in for the |
| 186 | version of fossil that is running. |
| 187 | |
| 188 |
+4
-9
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -40,18 +40,13 @@ | ||
| 40 | 40 | Each artifact in the repository is named by a hash of its content. |
| 41 | 41 | No prefixes, suffixes, or other information is added to an artifact before |
| 42 | 42 | the hash is computed. The artifact name is just the (lower-case |
| 43 | 43 | hexadecimal) hash of the raw artifact. |
| 44 | 44 | |
| 45 | -Fossil supports multiple hash algorithms including SHA1 and various | |
| 46 | -lengths of SHA3. Because an artifact can be hashed using multiple algorithms, | |
| 47 | -a single artifact can have multiple names. Usually, Fossil knows | |
| 48 | -each artifact by just a single name called the "display name". But it is | |
| 49 | -possible for Fossil to know an artifact by multiple names from different | |
| 50 | -hashes. In that case, Fossil uses the display name for output, but continues | |
| 51 | -to accept the alternative names as command-line arguments or as parameters to | |
| 52 | -webpage URLs. | |
| 45 | +Fossil currently computes artifact names using either SHA1 or SHA3-256. It | |
| 46 | +is relatively easy to add new algorithms in the future, but there are no | |
| 47 | +plans to do so at this time. | |
| 53 | 48 | |
| 54 | 49 | When referring to artifacts in using tty commands or webpage URLs, it is |
| 55 | 50 | sufficient to specify a unique prefix for the artifact name. If the input |
| 56 | 51 | prefix is not unique, Fossil will show an error. Within a structural |
| 57 | 52 | artifact, however, all references to other artifacts must be the complete |
| @@ -62,11 +57,11 @@ | ||
| 62 | 57 | alternative hash algorithms. |
| 63 | 58 | |
| 64 | 59 | <a name="structural"></a> |
| 65 | 60 | <h2>2.0 Structural Artifacts</h2> |
| 66 | 61 | |
| 67 | -A structural artifact is an artifact that has a particular format and | |
| 62 | +A structural artifact is an artifact with a particular format | |
| 68 | 63 | that is used to define the relationships between other artifacts in the |
| 69 | 64 | repository. |
| 70 | 65 | Fossil recognizes the following kinds of structural |
| 71 | 66 | artifacts: |
| 72 | 67 | |
| 73 | 68 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -40,18 +40,13 @@ | |
| 40 | Each artifact in the repository is named by a hash of its content. |
| 41 | No prefixes, suffixes, or other information is added to an artifact before |
| 42 | the hash is computed. The artifact name is just the (lower-case |
| 43 | hexadecimal) hash of the raw artifact. |
| 44 | |
| 45 | Fossil supports multiple hash algorithms including SHA1 and various |
| 46 | lengths of SHA3. Because an artifact can be hashed using multiple algorithms, |
| 47 | a single artifact can have multiple names. Usually, Fossil knows |
| 48 | each artifact by just a single name called the "display name". But it is |
| 49 | possible for Fossil to know an artifact by multiple names from different |
| 50 | hashes. In that case, Fossil uses the display name for output, but continues |
| 51 | to accept the alternative names as command-line arguments or as parameters to |
| 52 | webpage URLs. |
| 53 | |
| 54 | When referring to artifacts in using tty commands or webpage URLs, it is |
| 55 | sufficient to specify a unique prefix for the artifact name. If the input |
| 56 | prefix is not unique, Fossil will show an error. Within a structural |
| 57 | artifact, however, all references to other artifacts must be the complete |
| @@ -62,11 +57,11 @@ | |
| 62 | alternative hash algorithms. |
| 63 | |
| 64 | <a name="structural"></a> |
| 65 | <h2>2.0 Structural Artifacts</h2> |
| 66 | |
| 67 | A structural artifact is an artifact that has a particular format and |
| 68 | that is used to define the relationships between other artifacts in the |
| 69 | repository. |
| 70 | Fossil recognizes the following kinds of structural |
| 71 | artifacts: |
| 72 | |
| 73 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -40,18 +40,13 @@ | |
| 40 | Each artifact in the repository is named by a hash of its content. |
| 41 | No prefixes, suffixes, or other information is added to an artifact before |
| 42 | the hash is computed. The artifact name is just the (lower-case |
| 43 | hexadecimal) hash of the raw artifact. |
| 44 | |
| 45 | Fossil currently computes artifact names using either SHA1 or SHA3-256. It |
| 46 | is relatively easy to add new algorithms in the future, but there are no |
| 47 | plans to do so at this time. |
| 48 | |
| 49 | When referring to artifacts in using tty commands or webpage URLs, it is |
| 50 | sufficient to specify a unique prefix for the artifact name. If the input |
| 51 | prefix is not unique, Fossil will show an error. Within a structural |
| 52 | artifact, however, all references to other artifacts must be the complete |
| @@ -62,11 +57,11 @@ | |
| 57 | alternative hash algorithms. |
| 58 | |
| 59 | <a name="structural"></a> |
| 60 | <h2>2.0 Structural Artifacts</h2> |
| 61 | |
| 62 | A structural artifact is an artifact with a particular format |
| 63 | that is used to define the relationships between other artifacts in the |
| 64 | repository. |
| 65 | Fossil recognizes the following kinds of structural |
| 66 | artifacts: |
| 67 | |
| 68 |
+2
-1
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -67,11 +67,12 @@ | ||
| 67 | 67 | |
| 68 | 68 | <h3>3.2 Database</h3> |
| 69 | 69 | |
| 70 | 70 | The baseline data structures for Fossil and Git are the same (modulo |
| 71 | 71 | formatting details). Both systems store check-ins as immutable |
| 72 | -objects referencing their immediate ancestors and named by their SHA1 hash. | |
| 72 | +objects referencing their immediate ancestors and named by a | |
| 73 | +cryptographic hash of the check-in content. | |
| 73 | 74 | |
| 74 | 75 | The difference is that Git stores its objects as individual files |
| 75 | 76 | in the ".git" folder or compressed into |
| 76 | 77 | bespoke "pack-files", whereas Fossil stores its objects in a |
| 77 | 78 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 78 | 79 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -67,11 +67,12 @@ | |
| 67 | |
| 68 | <h3>3.2 Database</h3> |
| 69 | |
| 70 | The baseline data structures for Fossil and Git are the same (modulo |
| 71 | formatting details). Both systems store check-ins as immutable |
| 72 | objects referencing their immediate ancestors and named by their SHA1 hash. |
| 73 | |
| 74 | The difference is that Git stores its objects as individual files |
| 75 | in the ".git" folder or compressed into |
| 76 | bespoke "pack-files", whereas Fossil stores its objects in a |
| 77 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 78 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -67,11 +67,12 @@ | |
| 67 | |
| 68 | <h3>3.2 Database</h3> |
| 69 | |
| 70 | The baseline data structures for Fossil and Git are the same (modulo |
| 71 | formatting details). Both systems store check-ins as immutable |
| 72 | objects referencing their immediate ancestors and named by a |
| 73 | cryptographic hash of the check-in content. |
| 74 | |
| 75 | The difference is that Git stores its objects as individual files |
| 76 | in the ".git" folder or compressed into |
| 77 | bespoke "pack-files", whereas Fossil stores its objects in a |
| 78 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 79 |
+7
-6
| --- www/pop.wiki | ||
| +++ www/pop.wiki | ||
| @@ -25,17 +25,18 @@ | ||
| 25 | 25 | The global state represents the content of the project. |
| 26 | 26 | The local state identifies the authorized users and |
| 27 | 27 | access policies for a particular repository.</p></li> |
| 28 | 28 | |
| 29 | 29 | <li><p>The global state of a repository is an unordered |
| 30 | -collection of artifacts. Each artifact is named by | |
| 31 | -its SHA1 hash encoded in lowercase hexadecimal. | |
| 30 | +collection of artifacts. Each artifact is named by a | |
| 31 | +cryptographic hash (SHA1 or SHA3-256) encoded in | |
| 32 | +lowercase hexadecimal. | |
| 32 | 33 | In many contexts, the name can be |
| 33 | 34 | abbreviated to a unique prefix. A five- or six-character |
| 34 | 35 | prefix usually suffices to uniquely identify a file.</p></li> |
| 35 | 36 | |
| 36 | -<li><p>Because artifacts are named by their SHA1 hash, all artifacts | |
| 37 | +<li><p>Because artifacts are named by a cryptographic hash, all artifacts | |
| 37 | 38 | are immutable. Any change to the content of an artifact also |
| 38 | 39 | changes the hash that forms the artifacts name, thus |
| 39 | 40 | creating a new artifact. Both the old original version of the |
| 40 | 41 | artifact and the new change are preserved under different names.</p></li> |
| 41 | 42 | |
| @@ -42,16 +43,16 @@ | ||
| 42 | 43 | <li><p>It is theoretically possible for two artifacts with different |
| 43 | 44 | content to share the same hash. But finding two such |
| 44 | 45 | artifacts is so incredibly difficult and unlikely that we |
| 45 | 46 | consider it to be an impossibility.</p></li> |
| 46 | 47 | |
| 47 | -<li><p>The signature of an artifact is the SHA1 hash of the | |
| 48 | +<li><p>The signature of an artifact is the cryptographic hash of the | |
| 48 | 49 | artifact itself, exactly as it would appear in a disk file. No prefix |
| 49 | 50 | or meta-information about the artifact is added before computing |
| 50 | 51 | the hash. So you can |
| 51 | -always find the SHA1 signature of a file by using the | |
| 52 | -"sha1sum" command-line utility.</p></li> | |
| 52 | +always find the signature of a file by using the | |
| 53 | +"sha1sum" or "sha3sum" or similar command-line utilities.</p></li> | |
| 53 | 54 | |
| 54 | 55 | <li><p>The artifacts that comprise the global state of a repository |
| 55 | 56 | are the complete global state of that repository. The SQLite |
| 56 | 57 | database that holds the repository contains additional information |
| 57 | 58 | about linkages between artifacts, but all of that added information |
| 58 | 59 |
| --- www/pop.wiki | |
| +++ www/pop.wiki | |
| @@ -25,17 +25,18 @@ | |
| 25 | The global state represents the content of the project. |
| 26 | The local state identifies the authorized users and |
| 27 | access policies for a particular repository.</p></li> |
| 28 | |
| 29 | <li><p>The global state of a repository is an unordered |
| 30 | collection of artifacts. Each artifact is named by |
| 31 | its SHA1 hash encoded in lowercase hexadecimal. |
| 32 | In many contexts, the name can be |
| 33 | abbreviated to a unique prefix. A five- or six-character |
| 34 | prefix usually suffices to uniquely identify a file.</p></li> |
| 35 | |
| 36 | <li><p>Because artifacts are named by their SHA1 hash, all artifacts |
| 37 | are immutable. Any change to the content of an artifact also |
| 38 | changes the hash that forms the artifacts name, thus |
| 39 | creating a new artifact. Both the old original version of the |
| 40 | artifact and the new change are preserved under different names.</p></li> |
| 41 | |
| @@ -42,16 +43,16 @@ | |
| 42 | <li><p>It is theoretically possible for two artifacts with different |
| 43 | content to share the same hash. But finding two such |
| 44 | artifacts is so incredibly difficult and unlikely that we |
| 45 | consider it to be an impossibility.</p></li> |
| 46 | |
| 47 | <li><p>The signature of an artifact is the SHA1 hash of the |
| 48 | artifact itself, exactly as it would appear in a disk file. No prefix |
| 49 | or meta-information about the artifact is added before computing |
| 50 | the hash. So you can |
| 51 | always find the SHA1 signature of a file by using the |
| 52 | "sha1sum" command-line utility.</p></li> |
| 53 | |
| 54 | <li><p>The artifacts that comprise the global state of a repository |
| 55 | are the complete global state of that repository. The SQLite |
| 56 | database that holds the repository contains additional information |
| 57 | about linkages between artifacts, but all of that added information |
| 58 |
| --- www/pop.wiki | |
| +++ www/pop.wiki | |
| @@ -25,17 +25,18 @@ | |
| 25 | The global state represents the content of the project. |
| 26 | The local state identifies the authorized users and |
| 27 | access policies for a particular repository.</p></li> |
| 28 | |
| 29 | <li><p>The global state of a repository is an unordered |
| 30 | collection of artifacts. Each artifact is named by a |
| 31 | cryptographic hash (SHA1 or SHA3-256) encoded in |
| 32 | lowercase hexadecimal. |
| 33 | In many contexts, the name can be |
| 34 | abbreviated to a unique prefix. A five- or six-character |
| 35 | prefix usually suffices to uniquely identify a file.</p></li> |
| 36 | |
| 37 | <li><p>Because artifacts are named by a cryptographic hash, all artifacts |
| 38 | are immutable. Any change to the content of an artifact also |
| 39 | changes the hash that forms the artifacts name, thus |
| 40 | creating a new artifact. Both the old original version of the |
| 41 | artifact and the new change are preserved under different names.</p></li> |
| 42 | |
| @@ -42,16 +43,16 @@ | |
| 43 | <li><p>It is theoretically possible for two artifacts with different |
| 44 | content to share the same hash. But finding two such |
| 45 | artifacts is so incredibly difficult and unlikely that we |
| 46 | consider it to be an impossibility.</p></li> |
| 47 | |
| 48 | <li><p>The signature of an artifact is the cryptographic hash of the |
| 49 | artifact itself, exactly as it would appear in a disk file. No prefix |
| 50 | or meta-information about the artifact is added before computing |
| 51 | the hash. So you can |
| 52 | always find the signature of a file by using the |
| 53 | "sha1sum" or "sha3sum" or similar command-line utilities.</p></li> |
| 54 | |
| 55 | <li><p>The artifacts that comprise the global state of a repository |
| 56 | are the complete global state of that repository. The SQLite |
| 57 | database that holds the repository contains additional information |
| 58 | about linkages between artifacts, but all of that added information |
| 59 |
+5
-5
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -51,14 +51,14 @@ | ||
| 51 | 51 | commit. So during the course of check-in (or other repository |
| 52 | 52 | operation) many different files |
| 53 | 53 | in the repository might be modified. Some files are simply |
| 54 | 54 | compressed. Other files are delta encoded and then compressed. |
| 55 | 55 | While all this is going on, fossil makes a record of every file |
| 56 | -that is encoded and the SHA1 hash of the original content of that | |
| 56 | +and the SHA1 or SHA3-256 hash of the original content of that | |
| 57 | 57 | file. Then just before transaction commit, fossil re-extracts |
| 58 | -the original content of all files that were written, computes | |
| 59 | -the SHA1 checksum again, and verifies that the checksums match. | |
| 58 | +the original content of all files that were written, recomputes | |
| 59 | +the hash, and verifies that the recomputed hash still matches. | |
| 60 | 60 | If anything does not match up, an error |
| 61 | 61 | message is printed and the transaction rolls back. |
| 62 | 62 | |
| 63 | 63 | So, in other words, fossil always checks to make sure it can |
| 64 | 64 | re-extract a file before it commits a change to that file. |
| @@ -73,12 +73,12 @@ | ||
| 73 | 73 | and of all other files in the manifest. Prior to any check-in |
| 74 | 74 | commit, these checksums are verified to ensure that the check-in |
| 75 | 75 | agrees exactly with what is on disk. Similarly, |
| 76 | 76 | the repository checksum is verified after a checkout to make |
| 77 | 77 | sure that the entire repository was checked out correctly. |
| 78 | -Note that these added checks use a different hash (MD5 instead | |
| 79 | -of SHA1) in order to avoid common-mode failures in the hash | |
| 78 | +Note that these added checks use a different hash algorithm (MD5) | |
| 79 | +in order to avoid common-mode failures in the hash | |
| 80 | 80 | algorithm implementation. |
| 81 | 81 | |
| 82 | 82 | |
| 83 | 83 | <h2>Checksums On Control Artifacts And Deltas</h2> |
| 84 | 84 | |
| 85 | 85 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -51,14 +51,14 @@ | |
| 51 | commit. So during the course of check-in (or other repository |
| 52 | operation) many different files |
| 53 | in the repository might be modified. Some files are simply |
| 54 | compressed. Other files are delta encoded and then compressed. |
| 55 | While all this is going on, fossil makes a record of every file |
| 56 | that is encoded and the SHA1 hash of the original content of that |
| 57 | file. Then just before transaction commit, fossil re-extracts |
| 58 | the original content of all files that were written, computes |
| 59 | the SHA1 checksum again, and verifies that the checksums match. |
| 60 | If anything does not match up, an error |
| 61 | message is printed and the transaction rolls back. |
| 62 | |
| 63 | So, in other words, fossil always checks to make sure it can |
| 64 | re-extract a file before it commits a change to that file. |
| @@ -73,12 +73,12 @@ | |
| 73 | and of all other files in the manifest. Prior to any check-in |
| 74 | commit, these checksums are verified to ensure that the check-in |
| 75 | agrees exactly with what is on disk. Similarly, |
| 76 | the repository checksum is verified after a checkout to make |
| 77 | sure that the entire repository was checked out correctly. |
| 78 | Note that these added checks use a different hash (MD5 instead |
| 79 | of SHA1) in order to avoid common-mode failures in the hash |
| 80 | algorithm implementation. |
| 81 | |
| 82 | |
| 83 | <h2>Checksums On Control Artifacts And Deltas</h2> |
| 84 | |
| 85 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -51,14 +51,14 @@ | |
| 51 | commit. So during the course of check-in (or other repository |
| 52 | operation) many different files |
| 53 | in the repository might be modified. Some files are simply |
| 54 | compressed. Other files are delta encoded and then compressed. |
| 55 | While all this is going on, fossil makes a record of every file |
| 56 | and the SHA1 or SHA3-256 hash of the original content of that |
| 57 | file. Then just before transaction commit, fossil re-extracts |
| 58 | the original content of all files that were written, recomputes |
| 59 | the hash, and verifies that the recomputed hash still matches. |
| 60 | If anything does not match up, an error |
| 61 | message is printed and the transaction rolls back. |
| 62 | |
| 63 | So, in other words, fossil always checks to make sure it can |
| 64 | re-extract a file before it commits a change to that file. |
| @@ -73,12 +73,12 @@ | |
| 73 | and of all other files in the manifest. Prior to any check-in |
| 74 | commit, these checksums are verified to ensure that the check-in |
| 75 | agrees exactly with what is on disk. Similarly, |
| 76 | the repository checksum is verified after a checkout to make |
| 77 | sure that the entire repository was checked out correctly. |
| 78 | Note that these added checks use a different hash algorithm (MD5) |
| 79 | in order to avoid common-mode failures in the hash |
| 80 | algorithm implementation. |
| 81 | |
| 82 | |
| 83 | <h2>Checksums On Control Artifacts And Deltas</h2> |
| 84 | |
| 85 |
+1
-1
| --- www/shunning.wiki | ||
| +++ www/shunning.wiki | ||
| @@ -23,11 +23,11 @@ | ||
| 23 | 23 | <h2>Shunning</h2> |
| 24 | 24 | |
| 25 | 25 | Fossil provides a mechanism called "shunning" for removing content from |
| 26 | 26 | a repository. |
| 27 | 27 | |
| 28 | -Every Fossil repository maintains a list of the SHA1 hash names of | |
| 28 | +Every Fossil repository maintains a list of the hash names of | |
| 29 | 29 | "shunned" artifacts. |
| 30 | 30 | Fossil will refuse to push or pull any shunned artifact. |
| 31 | 31 | Furthermore, all shunned artifacts (but not the shunning list |
| 32 | 32 | itself) are removed from the |
| 33 | 33 | repository whenever the repository is reconstructed using the |
| 34 | 34 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -23,11 +23,11 @@ | |
| 23 | <h2>Shunning</h2> |
| 24 | |
| 25 | Fossil provides a mechanism called "shunning" for removing content from |
| 26 | a repository. |
| 27 | |
| 28 | Every Fossil repository maintains a list of the SHA1 hash names of |
| 29 | "shunned" artifacts. |
| 30 | Fossil will refuse to push or pull any shunned artifact. |
| 31 | Furthermore, all shunned artifacts (but not the shunning list |
| 32 | itself) are removed from the |
| 33 | repository whenever the repository is reconstructed using the |
| 34 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -23,11 +23,11 @@ | |
| 23 | <h2>Shunning</h2> |
| 24 | |
| 25 | Fossil provides a mechanism called "shunning" for removing content from |
| 26 | a repository. |
| 27 | |
| 28 | Every Fossil repository maintains a list of the hash names of |
| 29 | "shunned" artifacts. |
| 30 | Fossil will refuse to push or pull any shunned artifact. |
| 31 | Furthermore, all shunned artifacts (but not the shunning list |
| 32 | itself) are removed from the |
| 33 | repository whenever the repository is reconstructed using the |
| 34 |
+14
-14
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -4,23 +4,23 @@ | ||
| 4 | 4 | content between two Fossil repositories.</p> |
| 5 | 5 | |
| 6 | 6 | <h2>1.0 Overview</h2> |
| 7 | 7 | |
| 8 | 8 | <p>The global state of a fossil repository consists of an unordered |
| 9 | -collection of artifacts. Each artifact is identified by its SHA1 hash | |
| 10 | -expressed as a 40-character lower-case hexadecimal string. | |
| 9 | +collection of artifacts. Each artifact is identified by a cryptographic | |
| 10 | +hash of its content, expressed as a lower-case hexadecimal string. | |
| 11 | 11 | Synchronization is the process of sharing artifacts between |
| 12 | 12 | servers so that all servers have copies of all artifacts. Because |
| 13 | 13 | artifacts are unordered, the order in which artifacts are received |
| 14 | -at a server is inconsequential. It is assumed that the SHA1 hashes | |
| 15 | -of artifacts are unique - that every artifact has a different SHA1 hash. | |
| 14 | +at a server is inconsequential. It is assumed that the hash names | |
| 15 | +of artifacts are unique - that every artifact has a different hash. | |
| 16 | 16 | To a first approximation, synchronization proceeds by sharing lists |
| 17 | -SHA1 hashes of available artifacts, then sharing those artifacts that | |
| 18 | -are not found on one side or the other of the connection. In practice, | |
| 19 | -a repository might contain millions of artifacts. The list of | |
| 20 | -SHA1 hashes for this many artifacts can be large. So optimizations are | |
| 21 | -employed that usually reduce the number of SHA1 hashes that need to be | |
| 17 | +hash values for available artifacts, then sharing the content of artifacts | |
| 18 | +whose names are missing from one side or the other of the connection. | |
| 19 | +In practice, a repository might contain millions of artifacts. The list of | |
| 20 | +hash names for this many artifacts can be large. So optimizations are | |
| 21 | +employed that usually reduce the number of hashes that need to be | |
| 22 | 22 | shared to a few hundred.</p> |
| 23 | 23 | |
| 24 | 24 | <p>Each repository also has local state. The local state determines |
| 25 | 25 | the web-page formatting preferences, authorized users, ticket formats, |
| 26 | 26 | and similar information that varies from one repository to another. |
| @@ -198,11 +198,11 @@ | ||
| 198 | 198 | terminates the file card. |
| 199 | 199 | </p> |
| 200 | 200 | |
| 201 | 201 | <p>The first argument of a file card is the ID of the artifact that |
| 202 | 202 | is being transferred. The artifact ID is the lower-case hexadecimal |
| 203 | -representation of the SHA1 hash of the artifact. | |
| 203 | +representation of the name hash for the artifact. | |
| 204 | 204 | The last argument of the file card is the number of bytes of |
| 205 | 205 | payload that immediately follow the file card. If the file |
| 206 | 206 | card has only two arguments, that means the payload is the |
| 207 | 207 | complete content of the artifact. If the file card has three |
| 208 | 208 | arguments, then the payload is a delta and second argument is |
| @@ -231,11 +231,11 @@ | ||
| 231 | 231 | <b>cfile</b> <i>artifact-id delta-artifact-id usize csize</i> <b>\n</b> <i>content</i><br> |
| 232 | 232 | </blockquote> |
| 233 | 233 | |
| 234 | 234 | <p>The first argument of the cfile card is the ID of the artifact that |
| 235 | 235 | is being transferred. The artifact ID is the lower-case hexadecimal |
| 236 | -representation of the SHA1 hash of the artifact. The second argument of | |
| 236 | +representation of the name hash for the artifact. The second argument of | |
| 237 | 237 | the cfile card is the original size in bytes of the artifact. The last |
| 238 | 238 | argument of the cfile card is the number of compressed bytes of payload |
| 239 | 239 | that immediately follow the cfile card. If the cfile card has only |
| 240 | 240 | three arguments, that means the payload is the complete content of the |
| 241 | 241 | artifact. If the cfile card has four arguments, then the payload is a |
| @@ -271,11 +271,11 @@ | ||
| 271 | 271 | <b>uvfile</b> <i>name mtime hash size flags</i> <b>\n</b> <i>content</i> |
| 272 | 272 | </blockquote> |
| 273 | 273 | |
| 274 | 274 | <p>The <i>name</i> field is the name of the unversioned file. The |
| 275 | 275 | <i>mtime</i> is the last modification time of the file in seconds |
| 276 | -since 1970. The <i>hash</i> field is the SHA1 hash of the content | |
| 276 | +since 1970. The <i>hash</i> field is the hash of the content | |
| 277 | 277 | for the unversioned file, or "<b>-</b>" for deleted content. |
| 278 | 278 | The <i>size</i> field is the (uncompressed) size of the content |
| 279 | 279 | in bytes. The <i>flags</i> field is an integer which is interpreted |
| 280 | 280 | as an array of bits. The 0x0004 bit of <i>flags</i> indicates that |
| 281 | 281 | the <i>content</i> is to be omitted. The content might be omitted if |
| @@ -409,12 +409,12 @@ | ||
| 409 | 409 | </blockquote> |
| 410 | 410 | |
| 411 | 411 | <p>The <i>name</i> argument is the name of an unversioned file. |
| 412 | 412 | The <i>mtime</i> is the last modification time of the unversioned file |
| 413 | 413 | in seconds since 1970. |
| 414 | -The <i>hash</i> is the SHA1 hash of the unversioned file content, or | |
| 415 | -"<b>-</b>" if the file has been deleted. | |
| 414 | +The <i>hash</i> is the SHA1 or SHA3-256 hash of the unversioned file | |
| 415 | +content, or "<b>-</b>" if the file has been deleted. | |
| 416 | 416 | The <i>size</i> is the uncompressed size of the file in bytes. |
| 417 | 417 | |
| 418 | 418 | <p>When the server sees a "pragma uv-hash" card for which the hash |
| 419 | 419 | does not match, it sends uvigot cards for every unversioned file that it |
| 420 | 420 | holds. The client will use this information to figure out which |
| 421 | 421 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -4,23 +4,23 @@ | |
| 4 | content between two Fossil repositories.</p> |
| 5 | |
| 6 | <h2>1.0 Overview</h2> |
| 7 | |
| 8 | <p>The global state of a fossil repository consists of an unordered |
| 9 | collection of artifacts. Each artifact is identified by its SHA1 hash |
| 10 | expressed as a 40-character lower-case hexadecimal string. |
| 11 | Synchronization is the process of sharing artifacts between |
| 12 | servers so that all servers have copies of all artifacts. Because |
| 13 | artifacts are unordered, the order in which artifacts are received |
| 14 | at a server is inconsequential. It is assumed that the SHA1 hashes |
| 15 | of artifacts are unique - that every artifact has a different SHA1 hash. |
| 16 | To a first approximation, synchronization proceeds by sharing lists |
| 17 | SHA1 hashes of available artifacts, then sharing those artifacts that |
| 18 | are not found on one side or the other of the connection. In practice, |
| 19 | a repository might contain millions of artifacts. The list of |
| 20 | SHA1 hashes for this many artifacts can be large. So optimizations are |
| 21 | employed that usually reduce the number of SHA1 hashes that need to be |
| 22 | shared to a few hundred.</p> |
| 23 | |
| 24 | <p>Each repository also has local state. The local state determines |
| 25 | the web-page formatting preferences, authorized users, ticket formats, |
| 26 | and similar information that varies from one repository to another. |
| @@ -198,11 +198,11 @@ | |
| 198 | terminates the file card. |
| 199 | </p> |
| 200 | |
| 201 | <p>The first argument of a file card is the ID of the artifact that |
| 202 | is being transferred. The artifact ID is the lower-case hexadecimal |
| 203 | representation of the SHA1 hash of the artifact. |
| 204 | The last argument of the file card is the number of bytes of |
| 205 | payload that immediately follow the file card. If the file |
| 206 | card has only two arguments, that means the payload is the |
| 207 | complete content of the artifact. If the file card has three |
| 208 | arguments, then the payload is a delta and second argument is |
| @@ -231,11 +231,11 @@ | |
| 231 | <b>cfile</b> <i>artifact-id delta-artifact-id usize csize</i> <b>\n</b> <i>content</i><br> |
| 232 | </blockquote> |
| 233 | |
| 234 | <p>The first argument of the cfile card is the ID of the artifact that |
| 235 | is being transferred. The artifact ID is the lower-case hexadecimal |
| 236 | representation of the SHA1 hash of the artifact. The second argument of |
| 237 | the cfile card is the original size in bytes of the artifact. The last |
| 238 | argument of the cfile card is the number of compressed bytes of payload |
| 239 | that immediately follow the cfile card. If the cfile card has only |
| 240 | three arguments, that means the payload is the complete content of the |
| 241 | artifact. If the cfile card has four arguments, then the payload is a |
| @@ -271,11 +271,11 @@ | |
| 271 | <b>uvfile</b> <i>name mtime hash size flags</i> <b>\n</b> <i>content</i> |
| 272 | </blockquote> |
| 273 | |
| 274 | <p>The <i>name</i> field is the name of the unversioned file. The |
| 275 | <i>mtime</i> is the last modification time of the file in seconds |
| 276 | since 1970. The <i>hash</i> field is the SHA1 hash of the content |
| 277 | for the unversioned file, or "<b>-</b>" for deleted content. |
| 278 | The <i>size</i> field is the (uncompressed) size of the content |
| 279 | in bytes. The <i>flags</i> field is an integer which is interpreted |
| 280 | as an array of bits. The 0x0004 bit of <i>flags</i> indicates that |
| 281 | the <i>content</i> is to be omitted. The content might be omitted if |
| @@ -409,12 +409,12 @@ | |
| 409 | </blockquote> |
| 410 | |
| 411 | <p>The <i>name</i> argument is the name of an unversioned file. |
| 412 | The <i>mtime</i> is the last modification time of the unversioned file |
| 413 | in seconds since 1970. |
| 414 | The <i>hash</i> is the SHA1 hash of the unversioned file content, or |
| 415 | "<b>-</b>" if the file has been deleted. |
| 416 | The <i>size</i> is the uncompressed size of the file in bytes. |
| 417 | |
| 418 | <p>When the server sees a "pragma uv-hash" card for which the hash |
| 419 | does not match, it sends uvigot cards for every unversioned file that it |
| 420 | holds. The client will use this information to figure out which |
| 421 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -4,23 +4,23 @@ | |
| 4 | content between two Fossil repositories.</p> |
| 5 | |
| 6 | <h2>1.0 Overview</h2> |
| 7 | |
| 8 | <p>The global state of a fossil repository consists of an unordered |
| 9 | collection of artifacts. Each artifact is identified by a cryptographic |
| 10 | hash of its content, expressed as a lower-case hexadecimal string. |
| 11 | Synchronization is the process of sharing artifacts between |
| 12 | servers so that all servers have copies of all artifacts. Because |
| 13 | artifacts are unordered, the order in which artifacts are received |
| 14 | at a server is inconsequential. It is assumed that the hash names |
| 15 | of artifacts are unique - that every artifact has a different hash. |
| 16 | To a first approximation, synchronization proceeds by sharing lists |
| 17 | hash values for available artifacts, then sharing the content of artifacts |
| 18 | whose names are missing from one side or the other of the connection. |
| 19 | In practice, a repository might contain millions of artifacts. The list of |
| 20 | hash names for this many artifacts can be large. So optimizations are |
| 21 | employed that usually reduce the number of hashes that need to be |
| 22 | shared to a few hundred.</p> |
| 23 | |
| 24 | <p>Each repository also has local state. The local state determines |
| 25 | the web-page formatting preferences, authorized users, ticket formats, |
| 26 | and similar information that varies from one repository to another. |
| @@ -198,11 +198,11 @@ | |
| 198 | terminates the file card. |
| 199 | </p> |
| 200 | |
| 201 | <p>The first argument of a file card is the ID of the artifact that |
| 202 | is being transferred. The artifact ID is the lower-case hexadecimal |
| 203 | representation of the name hash for the artifact. |
| 204 | The last argument of the file card is the number of bytes of |
| 205 | payload that immediately follow the file card. If the file |
| 206 | card has only two arguments, that means the payload is the |
| 207 | complete content of the artifact. If the file card has three |
| 208 | arguments, then the payload is a delta and second argument is |
| @@ -231,11 +231,11 @@ | |
| 231 | <b>cfile</b> <i>artifact-id delta-artifact-id usize csize</i> <b>\n</b> <i>content</i><br> |
| 232 | </blockquote> |
| 233 | |
| 234 | <p>The first argument of the cfile card is the ID of the artifact that |
| 235 | is being transferred. The artifact ID is the lower-case hexadecimal |
| 236 | representation of the name hash for the artifact. The second argument of |
| 237 | the cfile card is the original size in bytes of the artifact. The last |
| 238 | argument of the cfile card is the number of compressed bytes of payload |
| 239 | that immediately follow the cfile card. If the cfile card has only |
| 240 | three arguments, that means the payload is the complete content of the |
| 241 | artifact. If the cfile card has four arguments, then the payload is a |
| @@ -271,11 +271,11 @@ | |
| 271 | <b>uvfile</b> <i>name mtime hash size flags</i> <b>\n</b> <i>content</i> |
| 272 | </blockquote> |
| 273 | |
| 274 | <p>The <i>name</i> field is the name of the unversioned file. The |
| 275 | <i>mtime</i> is the last modification time of the file in seconds |
| 276 | since 1970. The <i>hash</i> field is the hash of the content |
| 277 | for the unversioned file, or "<b>-</b>" for deleted content. |
| 278 | The <i>size</i> field is the (uncompressed) size of the content |
| 279 | in bytes. The <i>flags</i> field is an integer which is interpreted |
| 280 | as an array of bits. The 0x0004 bit of <i>flags</i> indicates that |
| 281 | the <i>content</i> is to be omitted. The content might be omitted if |
| @@ -409,12 +409,12 @@ | |
| 409 | </blockquote> |
| 410 | |
| 411 | <p>The <i>name</i> argument is the name of an unversioned file. |
| 412 | The <i>mtime</i> is the last modification time of the unversioned file |
| 413 | in seconds since 1970. |
| 414 | The <i>hash</i> is the SHA1 or SHA3-256 hash of the unversioned file |
| 415 | content, or "<b>-</b>" if the file has been deleted. |
| 416 | The <i>size</i> is the uncompressed size of the file in bytes. |
| 417 | |
| 418 | <p>When the server sees a "pragma uv-hash" card for which the hash |
| 419 | does not match, it sends uvigot cards for every unversioned file that it |
| 420 | holds. The client will use this information to figure out which |
| 421 |
+3
-2
| --- www/tech_overview.wiki | ||
| +++ www/tech_overview.wiki | ||
| @@ -173,11 +173,12 @@ | ||
| 173 | 173 | the [/help/deconstruct | fossil deconstruct] |
| 174 | 174 | command. Individual artifacts can be extracted using the |
| 175 | 175 | [/help/artifact | fossil artifact] command. |
| 176 | 176 | When accessing the repository database using raw SQL and the |
| 177 | 177 | [/help/sqlite3 | fossil sql] command, the extension function |
| 178 | -"<tt>content()</tt>" with a single argument which is the SHA1 hash | |
| 178 | +"<tt>content()</tt>" with a single argument which is the SHA1 or | |
| 179 | +SHA3-256 hash | |
| 179 | 180 | of an artifact will return the complete undeleted and uncompressed |
| 180 | 181 | content of that artifact. |
| 181 | 182 | |
| 182 | 183 | Going the other way, the [/help/reconstruct | fossil reconstruct] |
| 183 | 184 | command will scan a directory hierarchy and add all files found to |
| @@ -278,11 +279,11 @@ | ||
| 278 | 279 | project - is intended to be an append-only database. In other words, |
| 279 | 280 | new artifacts can be added but artifacts can never be removed. But |
| 280 | 281 | it sometimes happens that inappropriate content is mistakenly or |
| 281 | 282 | maliciously added to a repository. The only way to get rid of |
| 282 | 283 | the undesired content is to [./shunning.wiki | "shun"] it. |
| 283 | -The "shun" table in the repository database records the SHA1 hash of | |
| 284 | +The "shun" table in the repository database records the hash values for | |
| 284 | 285 | all shunned artifacts. |
| 285 | 286 | |
| 286 | 287 | The shun table can be pushed or pulled using |
| 287 | 288 | the [/help/config | fossil config] command with the "shun" AREA argument. |
| 288 | 289 | The shun table is also copied during a [/help/clone | clone]. |
| 289 | 290 |
| --- www/tech_overview.wiki | |
| +++ www/tech_overview.wiki | |
| @@ -173,11 +173,12 @@ | |
| 173 | the [/help/deconstruct | fossil deconstruct] |
| 174 | command. Individual artifacts can be extracted using the |
| 175 | [/help/artifact | fossil artifact] command. |
| 176 | When accessing the repository database using raw SQL and the |
| 177 | [/help/sqlite3 | fossil sql] command, the extension function |
| 178 | "<tt>content()</tt>" with a single argument which is the SHA1 hash |
| 179 | of an artifact will return the complete undeleted and uncompressed |
| 180 | content of that artifact. |
| 181 | |
| 182 | Going the other way, the [/help/reconstruct | fossil reconstruct] |
| 183 | command will scan a directory hierarchy and add all files found to |
| @@ -278,11 +279,11 @@ | |
| 278 | project - is intended to be an append-only database. In other words, |
| 279 | new artifacts can be added but artifacts can never be removed. But |
| 280 | it sometimes happens that inappropriate content is mistakenly or |
| 281 | maliciously added to a repository. The only way to get rid of |
| 282 | the undesired content is to [./shunning.wiki | "shun"] it. |
| 283 | The "shun" table in the repository database records the SHA1 hash of |
| 284 | all shunned artifacts. |
| 285 | |
| 286 | The shun table can be pushed or pulled using |
| 287 | the [/help/config | fossil config] command with the "shun" AREA argument. |
| 288 | The shun table is also copied during a [/help/clone | clone]. |
| 289 |
| --- www/tech_overview.wiki | |
| +++ www/tech_overview.wiki | |
| @@ -173,11 +173,12 @@ | |
| 173 | the [/help/deconstruct | fossil deconstruct] |
| 174 | command. Individual artifacts can be extracted using the |
| 175 | [/help/artifact | fossil artifact] command. |
| 176 | When accessing the repository database using raw SQL and the |
| 177 | [/help/sqlite3 | fossil sql] command, the extension function |
| 178 | "<tt>content()</tt>" with a single argument which is the SHA1 or |
| 179 | SHA3-256 hash |
| 180 | of an artifact will return the complete undeleted and uncompressed |
| 181 | content of that artifact. |
| 182 | |
| 183 | Going the other way, the [/help/reconstruct | fossil reconstruct] |
| 184 | command will scan a directory hierarchy and add all files found to |
| @@ -278,11 +279,11 @@ | |
| 279 | project - is intended to be an append-only database. In other words, |
| 280 | new artifacts can be added but artifacts can never be removed. But |
| 281 | it sometimes happens that inappropriate content is mistakenly or |
| 282 | maliciously added to a repository. The only way to get rid of |
| 283 | the undesired content is to [./shunning.wiki | "shun"] it. |
| 284 | The "shun" table in the repository database records the hash values for |
| 285 | all shunned artifacts. |
| 286 | |
| 287 | The shun table can be pushed or pulled using |
| 288 | the [/help/config | fossil config] command with the "shun" AREA argument. |
| 289 | The shun table is also copied during a [/help/clone | clone]. |
| 290 |
+2
-1
| --- www/theory1.wiki | ||
| +++ www/theory1.wiki | ||
| @@ -38,11 +38,12 @@ | ||
| 38 | 38 | been checked into the Fossil repository. Call these "content artifacts". |
| 39 | 39 | Other artifacts, known as |
| 40 | 40 | "control artifacts", contain ASCII text in a particular format that |
| 41 | 41 | defines relationships between other artifacts, such as which |
| 42 | 42 | content artifacts that go together to form a particular version of the |
| 43 | -project. Each artifact is named by its SHA1 hash and is thus immutable. | |
| 43 | +project. Each artifact is named by its SHA1 or SHA3-256 hash and is | |
| 44 | +thus immutable. | |
| 44 | 45 | Artifacts can be added to the database but not removed (if we ignore |
| 45 | 46 | the exceptional case of [./shunning.wiki | shunning].) Repositories |
| 46 | 47 | synchronize by computing the union of their artifact sets. SQL and |
| 47 | 48 | relation theory play no role in any of this. |
| 48 | 49 | |
| 49 | 50 |
| --- www/theory1.wiki | |
| +++ www/theory1.wiki | |
| @@ -38,11 +38,12 @@ | |
| 38 | been checked into the Fossil repository. Call these "content artifacts". |
| 39 | Other artifacts, known as |
| 40 | "control artifacts", contain ASCII text in a particular format that |
| 41 | defines relationships between other artifacts, such as which |
| 42 | content artifacts that go together to form a particular version of the |
| 43 | project. Each artifact is named by its SHA1 hash and is thus immutable. |
| 44 | Artifacts can be added to the database but not removed (if we ignore |
| 45 | the exceptional case of [./shunning.wiki | shunning].) Repositories |
| 46 | synchronize by computing the union of their artifact sets. SQL and |
| 47 | relation theory play no role in any of this. |
| 48 | |
| 49 |
| --- www/theory1.wiki | |
| +++ www/theory1.wiki | |
| @@ -38,11 +38,12 @@ | |
| 38 | been checked into the Fossil repository. Call these "content artifacts". |
| 39 | Other artifacts, known as |
| 40 | "control artifacts", contain ASCII text in a particular format that |
| 41 | defines relationships between other artifacts, such as which |
| 42 | content artifacts that go together to form a particular version of the |
| 43 | project. Each artifact is named by its SHA1 or SHA3-256 hash and is |
| 44 | thus immutable. |
| 45 | Artifacts can be added to the database but not removed (if we ignore |
| 46 | the exceptional case of [./shunning.wiki | shunning].) Repositories |
| 47 | synchronize by computing the union of their artifact sets. SQL and |
| 48 | relation theory play no role in any of this. |
| 49 | |
| 50 |
+1
-1
| --- www/webpage-ex.md | ||
| +++ www/webpage-ex.md | ||
| @@ -123,10 +123,10 @@ | ||
| 123 | 123 | href='$ROOT/bigbloblist'>Example</a> |
| 124 | 124 | The largest objects in the repository. |
| 125 | 125 | |
| 126 | 126 | * <a target='_blank' class='exbtn' |
| 127 | 127 | href='$ROOT/hash-collisions'>Example</a> |
| 128 | - SHA1 prefix collisions | |
| 128 | + Hash prefix collisions | |
| 129 | 129 | |
| 130 | 130 | * <a target='_blank' class='exbtn' |
| 131 | 131 | href='$ROOT/sitemap'>Example</a> |
| 132 | 132 | The "sitemap" containing links to many other pages |
| 133 | 133 |
| --- www/webpage-ex.md | |
| +++ www/webpage-ex.md | |
| @@ -123,10 +123,10 @@ | |
| 123 | href='$ROOT/bigbloblist'>Example</a> |
| 124 | The largest objects in the repository. |
| 125 | |
| 126 | * <a target='_blank' class='exbtn' |
| 127 | href='$ROOT/hash-collisions'>Example</a> |
| 128 | SHA1 prefix collisions |
| 129 | |
| 130 | * <a target='_blank' class='exbtn' |
| 131 | href='$ROOT/sitemap'>Example</a> |
| 132 | The "sitemap" containing links to many other pages |
| 133 |
| --- www/webpage-ex.md | |
| +++ www/webpage-ex.md | |
| @@ -123,10 +123,10 @@ | |
| 123 | href='$ROOT/bigbloblist'>Example</a> |
| 124 | The largest objects in the repository. |
| 125 | |
| 126 | * <a target='_blank' class='exbtn' |
| 127 | href='$ROOT/hash-collisions'>Example</a> |
| 128 | Hash prefix collisions |
| 129 | |
| 130 | * <a target='_blank' class='exbtn' |
| 131 | href='$ROOT/sitemap'>Example</a> |
| 132 | The "sitemap" containing links to many other pages |
| 133 |
+4
-3
| --- www/whyusefossil.wiki | ||
| +++ www/whyusefossil.wiki | ||
| @@ -232,18 +232,19 @@ | ||
| 232 | 232 | </ul> |
| 233 | 233 | </ul> |
| 234 | 234 | <li><p><b>Why version control is important (reprise)</b> |
| 235 | 235 | <ol type="A"> |
| 236 | 236 | <li><p>Every check-in and every individual file has a unique name - its |
| 237 | - SHA1 hash. Team members can unambiguously identify any specific | |
| 237 | + SHA1 or SHA3-256 hash. Team members can unambiguously identify | |
| 238 | + any specific | |
| 238 | 239 | version of the overall project or any specific version of an |
| 239 | 240 | individual file. |
| 240 | 241 | <li><p>Any historical version of the whole project or of any individual |
| 241 | 242 | file can be easily recreated at any time and by any team member. |
| 242 | 243 | <li><p>Accidental changes to files can be detected by recomputing their |
| 243 | - SHA1 hash. | |
| 244 | - <li><p>Files of unknown origin can be identified using their SHA1 hash. | |
| 244 | + cryptographic hash. | |
| 245 | + <li><p>Files of unknown origin can be identified using their hash. | |
| 245 | 246 | <li><p>Developers are able to work in parallel, review each others work, |
| 246 | 247 | and easily merge their changes together. External revisions to |
| 247 | 248 | the baseline can be easily incorporated into the latest changes. |
| 248 | 249 | <li><p>Developers can follow experimental lines of development, then |
| 249 | 250 | revert back to an earlier stable version if the experiment does |
| 250 | 251 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -232,18 +232,19 @@ | |
| 232 | </ul> |
| 233 | </ul> |
| 234 | <li><p><b>Why version control is important (reprise)</b> |
| 235 | <ol type="A"> |
| 236 | <li><p>Every check-in and every individual file has a unique name - its |
| 237 | SHA1 hash. Team members can unambiguously identify any specific |
| 238 | version of the overall project or any specific version of an |
| 239 | individual file. |
| 240 | <li><p>Any historical version of the whole project or of any individual |
| 241 | file can be easily recreated at any time and by any team member. |
| 242 | <li><p>Accidental changes to files can be detected by recomputing their |
| 243 | SHA1 hash. |
| 244 | <li><p>Files of unknown origin can be identified using their SHA1 hash. |
| 245 | <li><p>Developers are able to work in parallel, review each others work, |
| 246 | and easily merge their changes together. External revisions to |
| 247 | the baseline can be easily incorporated into the latest changes. |
| 248 | <li><p>Developers can follow experimental lines of development, then |
| 249 | revert back to an earlier stable version if the experiment does |
| 250 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -232,18 +232,19 @@ | |
| 232 | </ul> |
| 233 | </ul> |
| 234 | <li><p><b>Why version control is important (reprise)</b> |
| 235 | <ol type="A"> |
| 236 | <li><p>Every check-in and every individual file has a unique name - its |
| 237 | SHA1 or SHA3-256 hash. Team members can unambiguously identify |
| 238 | any specific |
| 239 | version of the overall project or any specific version of an |
| 240 | individual file. |
| 241 | <li><p>Any historical version of the whole project or of any individual |
| 242 | file can be easily recreated at any time and by any team member. |
| 243 | <li><p>Accidental changes to files can be detected by recomputing their |
| 244 | cryptographic hash. |
| 245 | <li><p>Files of unknown origin can be identified using their hash. |
| 246 | <li><p>Developers are able to work in parallel, review each others work, |
| 247 | and easily merge their changes together. External revisions to |
| 248 | the baseline can be easily incorporated into the latest changes. |
| 249 | <li><p>Developers can follow experimental lines of development, then |
| 250 | revert back to an earlier stable version if the experiment does |
| 251 |