Fossil SCM
Minor documentation tweaks.
Commit
1eab9b69f01ba13fccc49c4927dcb0dff5b18d57ade9ddadfc8a4e25c6ea0a10
Parent
d7c40d457507f88…
2 files changed
+6
-5
+1
-1
+6
-5
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -24,16 +24,16 @@ | ||
| 24 | 24 | |
| 25 | 25 | <verbatim type="pikchr float-right"> |
| 26 | 26 | R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70% |
| 27 | 27 | R2: cylinder same "Remote" "Repository" at 2.5*R1.wid right of R1 |
| 28 | 28 | spline <-> from R1.e to 0.6<R1.se,R2.sw> then to 0.4<R1.ne,R2.nw> then to R2.w |
| 29 | - text "HTTP" at .5<R1.ne,R2.nw> | |
| 29 | + text "HTTPS" at .5<R1.ne,R2.nw> | |
| 30 | 30 | R3: cylinder same "Local" "Repository" fill 0x90ee90 \ |
| 31 | 31 | at dist(R1.e,R2.w) below .5<R1,R2> |
| 32 | - 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> "HTTP" \ | |
| 33 | - behind R1 | |
| 34 | - spline <-> from R2.sw to .6<R2.sw,R3.n> to .5<R2.s,R3.e> to R3.ne "HTTP" ljust | |
| 32 | + 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> \ | |
| 33 | + "HTTPS" above behind R1 | |
| 34 | + spline <-> from R2.sw to .6<R2.sw,R3.n> to .5<R2.s,R3.e> to R3.ne "HTTPS" ljust | |
| 35 | 35 | T1: line from 1.0cm heading 200 from R3.sw go 2.2cm heading 150 then 2.2cm west close \ |
| 36 | 36 | fill 0xffff00 "Local" below "Source Tree" below |
| 37 | 37 | T2: line from 1.0cm heading 160 from R3.se same "Local" below "Source Tree" below |
| 38 | 38 | line <-> from R3.sw to T1.start |
| 39 | 39 | line <-> from R3.se to T2.start |
| @@ -91,11 +91,12 @@ | ||
| 91 | 91 | Fossil also has the concept of "cloning". A "clone" is like a "pull", |
| 92 | 92 | except that instead of beginning with an existing local repository, |
| 93 | 93 | a clone begins with nothing and creates a new local repository that |
| 94 | 94 | is a duplicate of a remote repository. |
| 95 | 95 | |
| 96 | -Communication between repositories is via HTTP. Remote | |
| 96 | +Communication between repositories is normally via HTTPS. (SSH is also | |
| 97 | +supported, as is unencrypted HTTP.) Remote | |
| 97 | 98 | repositories are identified by URL. You can also point a web browser |
| 98 | 99 | at a repository and get human-readable status, history, and tracking |
| 99 | 100 | information about the project. |
| 100 | 101 | |
| 101 | 102 | <h3 id="artifacts">2.1 Identification Of Artifacts</h3> |
| 102 | 103 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -24,16 +24,16 @@ | |
| 24 | |
| 25 | <verbatim type="pikchr float-right"> |
| 26 | R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70% |
| 27 | R2: cylinder same "Remote" "Repository" at 2.5*R1.wid right of R1 |
| 28 | spline <-> from R1.e to 0.6<R1.se,R2.sw> then to 0.4<R1.ne,R2.nw> then to R2.w |
| 29 | text "HTTP" at .5<R1.ne,R2.nw> |
| 30 | R3: cylinder same "Local" "Repository" fill 0x90ee90 \ |
| 31 | at dist(R1.e,R2.w) below .5<R1,R2> |
| 32 | 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> "HTTP" \ |
| 33 | behind R1 |
| 34 | spline <-> from R2.sw to .6<R2.sw,R3.n> to .5<R2.s,R3.e> to R3.ne "HTTP" ljust |
| 35 | T1: line from 1.0cm heading 200 from R3.sw go 2.2cm heading 150 then 2.2cm west close \ |
| 36 | fill 0xffff00 "Local" below "Source Tree" below |
| 37 | T2: line from 1.0cm heading 160 from R3.se same "Local" below "Source Tree" below |
| 38 | line <-> from R3.sw to T1.start |
| 39 | line <-> from R3.se to T2.start |
| @@ -91,11 +91,12 @@ | |
| 91 | Fossil also has the concept of "cloning". A "clone" is like a "pull", |
| 92 | except that instead of beginning with an existing local repository, |
| 93 | a clone begins with nothing and creates a new local repository that |
| 94 | is a duplicate of a remote repository. |
| 95 | |
| 96 | Communication between repositories is via 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 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -24,16 +24,16 @@ | |
| 24 | |
| 25 | <verbatim type="pikchr float-right"> |
| 26 | R1: cylinder "Remote" "Repository" fill 0xadd8e6 rad 70% |
| 27 | R2: cylinder same "Remote" "Repository" at 2.5*R1.wid right of R1 |
| 28 | spline <-> from R1.e to 0.6<R1.se,R2.sw> then to 0.4<R1.ne,R2.nw> then to R2.w |
| 29 | text "HTTPS" at .5<R1.ne,R2.nw> |
| 30 | R3: cylinder same "Local" "Repository" fill 0x90ee90 \ |
| 31 | at dist(R1.e,R2.w) below .5<R1,R2> |
| 32 | 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> \ |
| 33 | "HTTPS" above behind R1 |
| 34 | spline <-> from R2.sw to .6<R2.sw,R3.n> to .5<R2.s,R3.e> to R3.ne "HTTPS" ljust |
| 35 | T1: line from 1.0cm heading 200 from R3.sw go 2.2cm heading 150 then 2.2cm west close \ |
| 36 | fill 0xffff00 "Local" below "Source Tree" below |
| 37 | T2: line from 1.0cm heading 160 from R3.se same "Local" below "Source Tree" below |
| 38 | line <-> from R3.sw to T1.start |
| 39 | line <-> from R3.se to T2.start |
| @@ -91,11 +91,12 @@ | |
| 91 | Fossil also has the concept of "cloning". A "clone" is like a "pull", |
| 92 | except that instead of beginning with an existing local repository, |
| 93 | a clone begins with nothing and creates a new local repository that |
| 94 | is a duplicate of a remote repository. |
| 95 | |
| 96 | Communication between repositories is normally via HTTPS. (SSH is also |
| 97 | supported, as is unencrypted HTTP.) Remote |
| 98 | repositories are identified by URL. You can also point a web browser |
| 99 | at a repository and get human-readable status, history, and tracking |
| 100 | information about the project. |
| 101 | |
| 102 | <h3 id="artifacts">2.1 Identification Of Artifacts</h3> |
| 103 |
+1
-1
| --- www/whyusefossil.wiki | ||
| +++ www/whyusefossil.wiki | ||
| @@ -74,11 +74,11 @@ | ||
| 74 | 74 | <li><p>Fossil does not care what you name your repository files, |
| 75 | 75 | though names ending with ".fossil" are recommended. |
| 76 | 76 | <li><p>A single project typically has multiple, redundant repositories on |
| 77 | 77 | separate machines. |
| 78 | 78 | <li><p>All repositories stay synchronized with one another by exchanging |
| 79 | - information via HTTP or SSH. | |
| 79 | + information via HTTPS or SSH. | |
| 80 | 80 | <li><p>All repos for a single project redundantly store all information |
| 81 | 81 | about that project. So if any one repo is lost due to a disk |
| 82 | 82 | crash, all content is preserved in the surviving repos. |
| 83 | 83 | <li><p>The usual arrangement is one repository per user. And since |
| 84 | 84 | most users these days have their own computer, that means one |
| 85 | 85 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -74,11 +74,11 @@ | |
| 74 | <li><p>Fossil does not care what you name your repository files, |
| 75 | though names ending with ".fossil" are recommended. |
| 76 | <li><p>A single project typically has multiple, redundant repositories on |
| 77 | separate machines. |
| 78 | <li><p>All repositories stay synchronized with one another by exchanging |
| 79 | information via HTTP or SSH. |
| 80 | <li><p>All repos for a single project redundantly store all information |
| 81 | about that project. So if any one repo is lost due to a disk |
| 82 | crash, all content is preserved in the surviving repos. |
| 83 | <li><p>The usual arrangement is one repository per user. And since |
| 84 | most users these days have their own computer, that means one |
| 85 |
| --- www/whyusefossil.wiki | |
| +++ www/whyusefossil.wiki | |
| @@ -74,11 +74,11 @@ | |
| 74 | <li><p>Fossil does not care what you name your repository files, |
| 75 | though names ending with ".fossil" are recommended. |
| 76 | <li><p>A single project typically has multiple, redundant repositories on |
| 77 | separate machines. |
| 78 | <li><p>All repositories stay synchronized with one another by exchanging |
| 79 | information via HTTPS or SSH. |
| 80 | <li><p>All repos for a single project redundantly store all information |
| 81 | about that project. So if any one repo is lost due to a disk |
| 82 | crash, all content is preserved in the surviving repos. |
| 83 | <li><p>The usual arrangement is one repository per user. And since |
| 84 | most users these days have their own computer, that means one |
| 85 |