Fossil SCM
Fix typos in unvers.wiki.
Commit
22ee43db43f3aa657e389f0c6d75b3fd902c03659e570c7b025a0412e503c83e
Parent
33fa91550881d63…
1 file changed
+2
-2
+2
-2
| --- www/unvers.wiki | ||
| +++ www/unvers.wiki | ||
| @@ -5,11 +5,11 @@ | ||
| 5 | 5 | files stored in a Fossil repository without history, meaning |
| 6 | 6 | it retains the newest version of each such file, and that alone. |
| 7 | 7 | |
| 8 | 8 | Though it omits history, Fossil does sync unversioned content between |
| 9 | 9 | repositories. In the event of a conflict during a sync, it retains |
| 10 | -the most recent version of each unversioned file, discrding | |
| 10 | +the most recent version of each unversioned file, discarding | |
| 11 | 11 | older versions. |
| 12 | 12 | |
| 13 | 13 | Unversioned files are useful for storing ephemeral content such as builds |
| 14 | 14 | or frequently changing web pages. We store |
| 15 | 15 | the [https://fossil-scm.org/home/uv/download.html|download] page of |
| @@ -100,15 +100,15 @@ | ||
| 100 | 100 | Lacking history for unversioned files, Fossil does not attempt delta |
| 101 | 101 | compression on them. |
| 102 | 102 | |
| 103 | 103 | Fossil servers exchange unversioned content whole; it does not attempt |
| 104 | 104 | to "diff" your local version against the remote and send only the |
| 105 | -changes. We point tihs out because one use-case for unversioned content | |
| 105 | +changes. We point this out because one use-case for unversioned content | |
| 106 | 106 | is to send large, frequently-changing files. Appreciate the consequences |
| 107 | 107 | before making each change. |
| 108 | 108 | |
| 109 | 109 | There are two bandwidth-saving measures in "<tt>fossil uv sync</tt>". |
| 110 | 110 | The first is the regular HTTP payload compression step, done on all |
| 111 | 111 | syncs. The second is that Fossil sends SHA1 hash exchanges to determine |
| 112 | 112 | when it can avoid sending duplicate content over the wire unnecessarily. |
| 113 | 113 | See the [./sync.wiki|synchronization protocol documentation] for further |
| 114 | 114 | information. |
| 115 | 115 |
| --- www/unvers.wiki | |
| +++ www/unvers.wiki | |
| @@ -5,11 +5,11 @@ | |
| 5 | files stored in a Fossil repository without history, meaning |
| 6 | it retains the newest version of each such file, and that alone. |
| 7 | |
| 8 | Though it omits history, Fossil does sync unversioned content between |
| 9 | repositories. In the event of a conflict during a sync, it retains |
| 10 | the most recent version of each unversioned file, discrding |
| 11 | older versions. |
| 12 | |
| 13 | Unversioned files are useful for storing ephemeral content such as builds |
| 14 | or frequently changing web pages. We store |
| 15 | the [https://fossil-scm.org/home/uv/download.html|download] page of |
| @@ -100,15 +100,15 @@ | |
| 100 | Lacking history for unversioned files, Fossil does not attempt delta |
| 101 | compression on them. |
| 102 | |
| 103 | Fossil servers exchange unversioned content whole; it does not attempt |
| 104 | to "diff" your local version against the remote and send only the |
| 105 | changes. We point tihs out because one use-case for unversioned content |
| 106 | is to send large, frequently-changing files. Appreciate the consequences |
| 107 | before making each change. |
| 108 | |
| 109 | There are two bandwidth-saving measures in "<tt>fossil uv sync</tt>". |
| 110 | The first is the regular HTTP payload compression step, done on all |
| 111 | syncs. The second is that Fossil sends SHA1 hash exchanges to determine |
| 112 | when it can avoid sending duplicate content over the wire unnecessarily. |
| 113 | See the [./sync.wiki|synchronization protocol documentation] for further |
| 114 | information. |
| 115 |
| --- www/unvers.wiki | |
| +++ www/unvers.wiki | |
| @@ -5,11 +5,11 @@ | |
| 5 | files stored in a Fossil repository without history, meaning |
| 6 | it retains the newest version of each such file, and that alone. |
| 7 | |
| 8 | Though it omits history, Fossil does sync unversioned content between |
| 9 | repositories. In the event of a conflict during a sync, it retains |
| 10 | the most recent version of each unversioned file, discarding |
| 11 | older versions. |
| 12 | |
| 13 | Unversioned files are useful for storing ephemeral content such as builds |
| 14 | or frequently changing web pages. We store |
| 15 | the [https://fossil-scm.org/home/uv/download.html|download] page of |
| @@ -100,15 +100,15 @@ | |
| 100 | Lacking history for unversioned files, Fossil does not attempt delta |
| 101 | compression on them. |
| 102 | |
| 103 | Fossil servers exchange unversioned content whole; it does not attempt |
| 104 | to "diff" your local version against the remote and send only the |
| 105 | changes. We point this out because one use-case for unversioned content |
| 106 | is to send large, frequently-changing files. Appreciate the consequences |
| 107 | before making each change. |
| 108 | |
| 109 | There are two bandwidth-saving measures in "<tt>fossil uv sync</tt>". |
| 110 | The first is the regular HTTP payload compression step, done on all |
| 111 | syncs. The second is that Fossil sends SHA1 hash exchanges to determine |
| 112 | when it can avoid sending duplicate content over the wire unnecessarily. |
| 113 | See the [./sync.wiki|synchronization protocol documentation] for further |
| 114 | information. |
| 115 |