Fossil SCM
Merge typo fixes from the bv-corrections01 branch.
Commit
a186d8b8c965c25144d20b2e5ca21c3230994543faa8b1ee8df5d59ad158fbb7
Parent
95c1490cd630e37…
15 files changed
+1
-1
+1
-1
+1
-1
+4
-4
+2
-2
+5
-5
+10
-9
+2
-1
+1
-1
+4
-4
+2
-2
+1
-1
+2
-2
+1
-1
+1
-1
+1
-1
| --- Makefile.in | ||
| +++ Makefile.in | ||
| @@ -51,11 +51,11 @@ | ||
| 51 | 51 | BCCFLAGS = @CPPFLAGS@ $(CFLAGS) |
| 52 | 52 | TCCFLAGS = @EXTRA_CFLAGS@ @CPPFLAGS@ $(CFLAGS) -DHAVE_AUTOCONFIG_H |
| 53 | 53 | # |
| 54 | 54 | # Fuzzing may be enable by appending -fsanitize=fuzzer -DFOSSIL_FUZZ |
| 55 | 55 | # to the TCCFLAGS variable. |
| 56 | -# For more thorouth (but also slower) investigation | |
| 56 | +# For more thorough (but also slower) investigation | |
| 57 | 57 | # -fsanitize=fuzzer,undefined,address |
| 58 | 58 | # might be more useful. |
| 59 | 59 | |
| 60 | 60 | INSTALLDIR = $(DESTDIR)@prefix@/bin |
| 61 | 61 | USE_SYSTEM_SQLITE = @USE_SYSTEM_SQLITE@ |
| 62 | 62 |
| --- Makefile.in | |
| +++ Makefile.in | |
| @@ -51,11 +51,11 @@ | |
| 51 | BCCFLAGS = @CPPFLAGS@ $(CFLAGS) |
| 52 | TCCFLAGS = @EXTRA_CFLAGS@ @CPPFLAGS@ $(CFLAGS) -DHAVE_AUTOCONFIG_H |
| 53 | # |
| 54 | # Fuzzing may be enable by appending -fsanitize=fuzzer -DFOSSIL_FUZZ |
| 55 | # to the TCCFLAGS variable. |
| 56 | # For more thorouth (but also slower) investigation |
| 57 | # -fsanitize=fuzzer,undefined,address |
| 58 | # might be more useful. |
| 59 | |
| 60 | INSTALLDIR = $(DESTDIR)@prefix@/bin |
| 61 | USE_SYSTEM_SQLITE = @USE_SYSTEM_SQLITE@ |
| 62 |
| --- Makefile.in | |
| +++ Makefile.in | |
| @@ -51,11 +51,11 @@ | |
| 51 | BCCFLAGS = @CPPFLAGS@ $(CFLAGS) |
| 52 | TCCFLAGS = @EXTRA_CFLAGS@ @CPPFLAGS@ $(CFLAGS) -DHAVE_AUTOCONFIG_H |
| 53 | # |
| 54 | # Fuzzing may be enable by appending -fsanitize=fuzzer -DFOSSIL_FUZZ |
| 55 | # to the TCCFLAGS variable. |
| 56 | # For more thorough (but also slower) investigation |
| 57 | # -fsanitize=fuzzer,undefined,address |
| 58 | # might be more useful. |
| 59 | |
| 60 | INSTALLDIR = $(DESTDIR)@prefix@/bin |
| 61 | USE_SYSTEM_SQLITE = @USE_SYSTEM_SQLITE@ |
| 62 |
+1
-1
| --- src/checkin.c | ||
| +++ src/checkin.c | ||
| @@ -501,11 +501,11 @@ | ||
| 501 | 501 | /* The --brief or -b option is special. It cannot be used with any |
| 502 | 502 | ** other options. It outputs a single keyword which indicates the |
| 503 | 503 | ** fossil status, for use by shell scripts. The output might be |
| 504 | 504 | ** one of: |
| 505 | 505 | ** |
| 506 | - ** clean The current working directory is within a | |
| 506 | + ** clean The current working directory is within an | |
| 507 | 507 | ** unmodified fossil check-out. |
| 508 | 508 | ** |
| 509 | 509 | ** dirty The pwd is within a fossil check-out that has |
| 510 | 510 | ** uncommitted changes |
| 511 | 511 | ** |
| 512 | 512 |
| --- src/checkin.c | |
| +++ src/checkin.c | |
| @@ -501,11 +501,11 @@ | |
| 501 | /* The --brief or -b option is special. It cannot be used with any |
| 502 | ** other options. It outputs a single keyword which indicates the |
| 503 | ** fossil status, for use by shell scripts. The output might be |
| 504 | ** one of: |
| 505 | ** |
| 506 | ** clean The current working directory is within a |
| 507 | ** unmodified fossil check-out. |
| 508 | ** |
| 509 | ** dirty The pwd is within a fossil check-out that has |
| 510 | ** uncommitted changes |
| 511 | ** |
| 512 |
| --- src/checkin.c | |
| +++ src/checkin.c | |
| @@ -501,11 +501,11 @@ | |
| 501 | /* The --brief or -b option is special. It cannot be used with any |
| 502 | ** other options. It outputs a single keyword which indicates the |
| 503 | ** fossil status, for use by shell scripts. The output might be |
| 504 | ** one of: |
| 505 | ** |
| 506 | ** clean The current working directory is within an |
| 507 | ** unmodified fossil check-out. |
| 508 | ** |
| 509 | ** dirty The pwd is within a fossil check-out that has |
| 510 | ** uncommitted changes |
| 511 | ** |
| 512 |
+1
-1
| --- www/history.md | ||
| +++ www/history.md | ||
| @@ -16,11 +16,11 @@ | ||
| 16 | 16 | |
| 17 | 17 | [120]: /reports?type=ci&view=byuser |
| 18 | 18 | |
| 19 | 19 | ## History |
| 20 | 20 | |
| 21 | -The SQLite project start out using [CVS][300], as CVS was the most | |
| 21 | +The SQLite project started out using [CVS][300], as CVS was the most | |
| 22 | 22 | commonly used version control system in that era (circa 2000). CVS |
| 23 | 23 | was an amazing version control system for its day in that it allowed |
| 24 | 24 | multiple developers to be editing the same file at the same time. |
| 25 | 25 | |
| 26 | 26 | [300]: https://en.wikipedia.org/wiki/Concurrent_Versions_System |
| 27 | 27 |
| --- www/history.md | |
| +++ www/history.md | |
| @@ -16,11 +16,11 @@ | |
| 16 | |
| 17 | [120]: /reports?type=ci&view=byuser |
| 18 | |
| 19 | ## History |
| 20 | |
| 21 | The SQLite project start out using [CVS][300], as CVS was the most |
| 22 | commonly used version control system in that era (circa 2000). CVS |
| 23 | was an amazing version control system for its day in that it allowed |
| 24 | multiple developers to be editing the same file at the same time. |
| 25 | |
| 26 | [300]: https://en.wikipedia.org/wiki/Concurrent_Versions_System |
| 27 |
| --- www/history.md | |
| +++ www/history.md | |
| @@ -16,11 +16,11 @@ | |
| 16 | |
| 17 | [120]: /reports?type=ci&view=byuser |
| 18 | |
| 19 | ## History |
| 20 | |
| 21 | The SQLite project started out using [CVS][300], as CVS was the most |
| 22 | commonly used version control system in that era (circa 2000). CVS |
| 23 | was an amazing version control system for its day in that it allowed |
| 24 | multiple developers to be editing the same file at the same time. |
| 25 | |
| 26 | [300]: https://en.wikipedia.org/wiki/Concurrent_Versions_System |
| 27 |
+4
-4
| --- www/hooks.md | ||
| +++ www/hooks.md | ||
| @@ -5,11 +5,11 @@ | ||
| 5 | 5 | a continuous integration (CI) system. |
| 6 | 6 | |
| 7 | 7 | ## Interim Documentation. |
| 8 | 8 | |
| 9 | 9 | * This is a work-in-progress. The interface is in flux. |
| 10 | - For the time being, the documentation as a list of | |
| 10 | + For the time being, the documentation is a list of | |
| 11 | 11 | bullet points. We hope to transform this into a proper document |
| 12 | 12 | later, after things settle down. |
| 13 | 13 | |
| 14 | 14 | * Contributions and suggestions to the hook system and/or the |
| 15 | 15 | documentation are welcomed. |
| @@ -35,14 +35,14 @@ | ||
| 35 | 35 | that the original script can return. |
| 36 | 36 | |
| 37 | 37 | * The "%F" sequence inside the script is translated into the |
| 38 | 38 | name of the fossil executable. |
| 39 | 39 | |
| 40 | - * The "%R" sequence in the script is translated in to the name of | |
| 40 | + * The "%R" sequence in the script is translated into the name of | |
| 41 | 41 | the repository. |
| 42 | 42 | |
| 43 | - * The "%A" sequence becomes the name of an auxiliary input files, | |
| 43 | + * The "%A" sequence becomes the name of an auxiliary input file, | |
| 44 | 44 | the meaning of which depends on the hook type. The auxiliary filename |
| 45 | 45 | might be an empty string. Take care to use appropriate quoting! |
| 46 | 46 | |
| 47 | 47 | ## Disabled Hooks |
| 48 | 48 | |
| @@ -144,11 +144,11 @@ | ||
| 144 | 144 | ## Commit-Msg Hooks |
| 145 | 145 | |
| 146 | 146 | * Commit-msg hooks are not yet implemented. |
| 147 | 147 | |
| 148 | 148 | * The commit-msg hooks run during "fossil commit" after the check-in |
| 149 | - messages has been entered by the user. The "%A" argument to the | |
| 149 | + message has been entered by the user. The "%A" argument to the | |
| 150 | 150 | commit-msg hook is the text of the commit message. The intent |
| 151 | 151 | of the commit-msg hook is to validate the text of the commit |
| 152 | 152 | message to (for example) check for typos or ensure that it |
| 153 | 153 | conforms to standards. |
| 154 | 154 | |
| 155 | 155 |
| --- www/hooks.md | |
| +++ www/hooks.md | |
| @@ -5,11 +5,11 @@ | |
| 5 | a continuous integration (CI) system. |
| 6 | |
| 7 | ## Interim Documentation. |
| 8 | |
| 9 | * This is a work-in-progress. The interface is in flux. |
| 10 | For the time being, the documentation as a list of |
| 11 | bullet points. We hope to transform this into a proper document |
| 12 | later, after things settle down. |
| 13 | |
| 14 | * Contributions and suggestions to the hook system and/or the |
| 15 | documentation are welcomed. |
| @@ -35,14 +35,14 @@ | |
| 35 | that the original script can return. |
| 36 | |
| 37 | * The "%F" sequence inside the script is translated into the |
| 38 | name of the fossil executable. |
| 39 | |
| 40 | * The "%R" sequence in the script is translated in to the name of |
| 41 | the repository. |
| 42 | |
| 43 | * The "%A" sequence becomes the name of an auxiliary input files, |
| 44 | the meaning of which depends on the hook type. The auxiliary filename |
| 45 | might be an empty string. Take care to use appropriate quoting! |
| 46 | |
| 47 | ## Disabled Hooks |
| 48 | |
| @@ -144,11 +144,11 @@ | |
| 144 | ## Commit-Msg Hooks |
| 145 | |
| 146 | * Commit-msg hooks are not yet implemented. |
| 147 | |
| 148 | * The commit-msg hooks run during "fossil commit" after the check-in |
| 149 | messages has been entered by the user. The "%A" argument to the |
| 150 | commit-msg hook is the text of the commit message. The intent |
| 151 | of the commit-msg hook is to validate the text of the commit |
| 152 | message to (for example) check for typos or ensure that it |
| 153 | conforms to standards. |
| 154 | |
| 155 |
| --- www/hooks.md | |
| +++ www/hooks.md | |
| @@ -5,11 +5,11 @@ | |
| 5 | a continuous integration (CI) system. |
| 6 | |
| 7 | ## Interim Documentation. |
| 8 | |
| 9 | * This is a work-in-progress. The interface is in flux. |
| 10 | For the time being, the documentation is a list of |
| 11 | bullet points. We hope to transform this into a proper document |
| 12 | later, after things settle down. |
| 13 | |
| 14 | * Contributions and suggestions to the hook system and/or the |
| 15 | documentation are welcomed. |
| @@ -35,14 +35,14 @@ | |
| 35 | that the original script can return. |
| 36 | |
| 37 | * The "%F" sequence inside the script is translated into the |
| 38 | name of the fossil executable. |
| 39 | |
| 40 | * The "%R" sequence in the script is translated into the name of |
| 41 | the repository. |
| 42 | |
| 43 | * The "%A" sequence becomes the name of an auxiliary input file, |
| 44 | the meaning of which depends on the hook type. The auxiliary filename |
| 45 | might be an empty string. Take care to use appropriate quoting! |
| 46 | |
| 47 | ## Disabled Hooks |
| 48 | |
| @@ -144,11 +144,11 @@ | |
| 144 | ## Commit-Msg Hooks |
| 145 | |
| 146 | * Commit-msg hooks are not yet implemented. |
| 147 | |
| 148 | * The commit-msg hooks run during "fossil commit" after the check-in |
| 149 | message has been entered by the user. The "%A" argument to the |
| 150 | commit-msg hook is the text of the commit message. The intent |
| 151 | of the commit-msg hook is to validate the text of the commit |
| 152 | message to (for example) check for typos or ensure that it |
| 153 | conforms to standards. |
| 154 | |
| 155 |
+2
-2
| --- www/inout.wiki | ||
| +++ www/inout.wiki | ||
| @@ -48,11 +48,11 @@ | ||
| 48 | 48 | emitted by "<tt>git fast-export</tt>" before sending it along to Fossil, |
| 49 | 49 | but we've seen the problem recur on multiple machines. |
| 50 | 50 | |
| 51 | 51 | While one workaround is to fall back to <tt>cmd.exe</tt> — which doesn't |
| 52 | 52 | seem to be affected by this problem — we instead recommend using |
| 53 | -Mirosoft's own [https://learn.microsoft.com/en-us/windows/wsl/ | Windows | |
| 53 | +Microsoft's own [https://learn.microsoft.com/en-us/windows/wsl/ | Windows | |
| 54 | 54 | Subsystem for Linux] or either of the two popular "Git for Windows" |
| 55 | 55 | distributions based on MSYS2. They handle pipes the POSIX way, avoiding |
| 56 | 56 | any dependency on the amount of data involved. |
| 57 | 57 | |
| 58 | 58 | <h2>Fossil → Git</h2> |
| @@ -76,11 +76,11 @@ | ||
| 76 | 76 | As with the "import" command, the --git option is not required |
| 77 | 77 | since the git-fast-export file format is currently the only VCS interchange |
| 78 | 78 | format that Fossil will generate. However, |
| 79 | 79 | future versions of Fossil might add the ability to generate other |
| 80 | 80 | VCS interchange formats, and so for compatibility, the use of the --git |
| 81 | -option recommended. | |
| 81 | +option is recommended. | |
| 82 | 82 | |
| 83 | 83 | <h2>Mirror A Fossil Repository In Git</h2> |
| 84 | 84 | |
| 85 | 85 | Fossil version 2.9 and later supports a simple mechanism for |
| 86 | 86 | doing a Git or |
| 87 | 87 |
| --- www/inout.wiki | |
| +++ www/inout.wiki | |
| @@ -48,11 +48,11 @@ | |
| 48 | emitted by "<tt>git fast-export</tt>" before sending it along to Fossil, |
| 49 | but we've seen the problem recur on multiple machines. |
| 50 | |
| 51 | While one workaround is to fall back to <tt>cmd.exe</tt> — which doesn't |
| 52 | seem to be affected by this problem — we instead recommend using |
| 53 | Mirosoft's own [https://learn.microsoft.com/en-us/windows/wsl/ | Windows |
| 54 | Subsystem for Linux] or either of the two popular "Git for Windows" |
| 55 | distributions based on MSYS2. They handle pipes the POSIX way, avoiding |
| 56 | any dependency on the amount of data involved. |
| 57 | |
| 58 | <h2>Fossil → Git</h2> |
| @@ -76,11 +76,11 @@ | |
| 76 | As with the "import" command, the --git option is not required |
| 77 | since the git-fast-export file format is currently the only VCS interchange |
| 78 | format that Fossil will generate. However, |
| 79 | future versions of Fossil might add the ability to generate other |
| 80 | VCS interchange formats, and so for compatibility, the use of the --git |
| 81 | option recommended. |
| 82 | |
| 83 | <h2>Mirror A Fossil Repository In Git</h2> |
| 84 | |
| 85 | Fossil version 2.9 and later supports a simple mechanism for |
| 86 | doing a Git or |
| 87 |
| --- www/inout.wiki | |
| +++ www/inout.wiki | |
| @@ -48,11 +48,11 @@ | |
| 48 | emitted by "<tt>git fast-export</tt>" before sending it along to Fossil, |
| 49 | but we've seen the problem recur on multiple machines. |
| 50 | |
| 51 | While one workaround is to fall back to <tt>cmd.exe</tt> — which doesn't |
| 52 | seem to be affected by this problem — we instead recommend using |
| 53 | Microsoft's own [https://learn.microsoft.com/en-us/windows/wsl/ | Windows |
| 54 | Subsystem for Linux] or either of the two popular "Git for Windows" |
| 55 | distributions based on MSYS2. They handle pipes the POSIX way, avoiding |
| 56 | any dependency on the amount of data involved. |
| 57 | |
| 58 | <h2>Fossil → Git</h2> |
| @@ -76,11 +76,11 @@ | |
| 76 | As with the "import" command, the --git option is not required |
| 77 | since the git-fast-export file format is currently the only VCS interchange |
| 78 | format that Fossil will generate. However, |
| 79 | future versions of Fossil might add the ability to generate other |
| 80 | VCS interchange formats, and so for compatibility, the use of the --git |
| 81 | option is recommended. |
| 82 | |
| 83 | <h2>Mirror A Fossil Repository In Git</h2> |
| 84 | |
| 85 | Fossil version 2.9 and later supports a simple mechanism for |
| 86 | doing a Git or |
| 87 |
+5
-5
| --- www/interwiki.md | ||
| +++ www/interwiki.md | ||
| @@ -50,11 +50,11 @@ | ||
| 50 | 50 | or is an empty string. |
| 51 | 51 | |
| 52 | 52 | 2. <b>Hash Links</b> → the PageName is a hexadecimal number with |
| 53 | 53 | at least four digits. |
| 54 | 54 | |
| 55 | - 3. <b>Wiki Links</b> → An PageName that is not a Path or Hash. | |
| 55 | + 3. <b>Wiki Links</b> → A PageName that is not a Path or Hash. | |
| 56 | 56 | |
| 57 | 57 | The Intermap defines a base URL for each Tag. Path links are appended |
| 58 | 58 | directly to the URL contained in the Intermap. The Intermap can define |
| 59 | 59 | additional text to put in between the base URL and the PageName for |
| 60 | 60 | Hash and Wiki links, respectively. |
| @@ -62,11 +62,11 @@ | ||
| 62 | 62 | <a id="intermap"></a> |
| 63 | 63 | ## Intermap |
| 64 | 64 | |
| 65 | 65 | The intermap defines a mapping from interwiki Tags to full URLs. The |
| 66 | 66 | Intermap can be viewed and managed using the [fossil interwiki][iwiki] |
| 67 | -command or the [/intermap][imap] webpages. | |
| 67 | +command or the [/intermap][imap] webpage. | |
| 68 | 68 | |
| 69 | 69 | [iwiki]: /help?cmd=interwiki |
| 70 | 70 | [imap]: /intermap |
| 71 | 71 | |
| 72 | 72 | The current intermap for a server is seen on the [/intermap][imap] page |
| @@ -77,19 +77,19 @@ | ||
| 77 | 77 | Each intermap entry stores, at a minimum, the base URL for the remote |
| 78 | 78 | wiki. The intermap entry might also store additional path text that |
| 79 | 79 | is used for Hash and Wiki links. If only the base URL is provided, |
| 80 | 80 | then the intermap will only allow Path style interwiki links. The |
| 81 | 81 | Hash and Wiki style interwiki links are only allowed if the necessary |
| 82 | -extensions for provided in the intermap. | |
| 82 | +extensions are provided in the intermap. | |
| 83 | 83 | |
| 84 | 84 | |
| 85 | 85 | ## Disadvantages and Limitations |
| 86 | 86 | |
| 87 | 87 | * Configuration is required. The intermap must be set up correctly |
| 88 | 88 | before interwiki links will work. This contrasts with ordinary |
| 89 | 89 | links that just work without any configuration. Cloning a repository |
| 90 | - copies the intermap, but normal syncs to not keep the intermap in | |
| 90 | + copies the intermap, but normal syncs do not keep the intermap in | |
| 91 | 91 | sync. Use the "[fossil config pull interwiki][fcfg]" command to |
| 92 | 92 | synchronize the intermap. |
| 93 | 93 | |
| 94 | 94 | * The is no backlink tracking. For ordinary intrawiki links, Fossil keeps |
| 95 | 95 | track of both the source and target, and when displaying targets it |
| @@ -96,11 +96,11 @@ | ||
| 96 | 96 | commonly shows links to that target. For example, if you mention a |
| 97 | 97 | check-in as part of a comment of another check-in, that new check-in |
| 98 | 98 | shows up in the "References" section of the target check-in. |
| 99 | 99 | ([example](31af805348690958). In other words, Fossil tracks not just |
| 100 | 100 | "_source→target_", but it also tracks "_target→source_". |
| 101 | - But backtracking do not work for interwiki links, since the Fossil | |
| 101 | + But backtracking does not work for interwiki links, since the Fossil | |
| 102 | 102 | running on the target has no way of scanning the source text and |
| 103 | 103 | hence has no way of knowing that it is a target of a link from the source. |
| 104 | 104 | |
| 105 | 105 | [fcfg]: /help?cmd=config |
| 106 | 106 | |
| 107 | 107 |
| --- www/interwiki.md | |
| +++ www/interwiki.md | |
| @@ -50,11 +50,11 @@ | |
| 50 | or is an empty string. |
| 51 | |
| 52 | 2. <b>Hash Links</b> → the PageName is a hexadecimal number with |
| 53 | at least four digits. |
| 54 | |
| 55 | 3. <b>Wiki Links</b> → An PageName that is not a Path or Hash. |
| 56 | |
| 57 | The Intermap defines a base URL for each Tag. Path links are appended |
| 58 | directly to the URL contained in the Intermap. The Intermap can define |
| 59 | additional text to put in between the base URL and the PageName for |
| 60 | Hash and Wiki links, respectively. |
| @@ -62,11 +62,11 @@ | |
| 62 | <a id="intermap"></a> |
| 63 | ## Intermap |
| 64 | |
| 65 | The intermap defines a mapping from interwiki Tags to full URLs. The |
| 66 | Intermap can be viewed and managed using the [fossil interwiki][iwiki] |
| 67 | command or the [/intermap][imap] webpages. |
| 68 | |
| 69 | [iwiki]: /help?cmd=interwiki |
| 70 | [imap]: /intermap |
| 71 | |
| 72 | The current intermap for a server is seen on the [/intermap][imap] page |
| @@ -77,19 +77,19 @@ | |
| 77 | Each intermap entry stores, at a minimum, the base URL for the remote |
| 78 | wiki. The intermap entry might also store additional path text that |
| 79 | is used for Hash and Wiki links. If only the base URL is provided, |
| 80 | then the intermap will only allow Path style interwiki links. The |
| 81 | Hash and Wiki style interwiki links are only allowed if the necessary |
| 82 | extensions for provided in the intermap. |
| 83 | |
| 84 | |
| 85 | ## Disadvantages and Limitations |
| 86 | |
| 87 | * Configuration is required. The intermap must be set up correctly |
| 88 | before interwiki links will work. This contrasts with ordinary |
| 89 | links that just work without any configuration. Cloning a repository |
| 90 | copies the intermap, but normal syncs to not keep the intermap in |
| 91 | sync. Use the "[fossil config pull interwiki][fcfg]" command to |
| 92 | synchronize the intermap. |
| 93 | |
| 94 | * The is no backlink tracking. For ordinary intrawiki links, Fossil keeps |
| 95 | track of both the source and target, and when displaying targets it |
| @@ -96,11 +96,11 @@ | |
| 96 | commonly shows links to that target. For example, if you mention a |
| 97 | check-in as part of a comment of another check-in, that new check-in |
| 98 | shows up in the "References" section of the target check-in. |
| 99 | ([example](31af805348690958). In other words, Fossil tracks not just |
| 100 | "_source→target_", but it also tracks "_target→source_". |
| 101 | But backtracking do not work for interwiki links, since the Fossil |
| 102 | running on the target has no way of scanning the source text and |
| 103 | hence has no way of knowing that it is a target of a link from the source. |
| 104 | |
| 105 | [fcfg]: /help?cmd=config |
| 106 | |
| 107 |
| --- www/interwiki.md | |
| +++ www/interwiki.md | |
| @@ -50,11 +50,11 @@ | |
| 50 | or is an empty string. |
| 51 | |
| 52 | 2. <b>Hash Links</b> → the PageName is a hexadecimal number with |
| 53 | at least four digits. |
| 54 | |
| 55 | 3. <b>Wiki Links</b> → A PageName that is not a Path or Hash. |
| 56 | |
| 57 | The Intermap defines a base URL for each Tag. Path links are appended |
| 58 | directly to the URL contained in the Intermap. The Intermap can define |
| 59 | additional text to put in between the base URL and the PageName for |
| 60 | Hash and Wiki links, respectively. |
| @@ -62,11 +62,11 @@ | |
| 62 | <a id="intermap"></a> |
| 63 | ## Intermap |
| 64 | |
| 65 | The intermap defines a mapping from interwiki Tags to full URLs. The |
| 66 | Intermap can be viewed and managed using the [fossil interwiki][iwiki] |
| 67 | command or the [/intermap][imap] webpage. |
| 68 | |
| 69 | [iwiki]: /help?cmd=interwiki |
| 70 | [imap]: /intermap |
| 71 | |
| 72 | The current intermap for a server is seen on the [/intermap][imap] page |
| @@ -77,19 +77,19 @@ | |
| 77 | Each intermap entry stores, at a minimum, the base URL for the remote |
| 78 | wiki. The intermap entry might also store additional path text that |
| 79 | is used for Hash and Wiki links. If only the base URL is provided, |
| 80 | then the intermap will only allow Path style interwiki links. The |
| 81 | Hash and Wiki style interwiki links are only allowed if the necessary |
| 82 | extensions are provided in the intermap. |
| 83 | |
| 84 | |
| 85 | ## Disadvantages and Limitations |
| 86 | |
| 87 | * Configuration is required. The intermap must be set up correctly |
| 88 | before interwiki links will work. This contrasts with ordinary |
| 89 | links that just work without any configuration. Cloning a repository |
| 90 | copies the intermap, but normal syncs do not keep the intermap in |
| 91 | sync. Use the "[fossil config pull interwiki][fcfg]" command to |
| 92 | synchronize the intermap. |
| 93 | |
| 94 | * The is no backlink tracking. For ordinary intrawiki links, Fossil keeps |
| 95 | track of both the source and target, and when displaying targets it |
| @@ -96,11 +96,11 @@ | |
| 96 | commonly shows links to that target. For example, if you mention a |
| 97 | check-in as part of a comment of another check-in, that new check-in |
| 98 | shows up in the "References" section of the target check-in. |
| 99 | ([example](31af805348690958). In other words, Fossil tracks not just |
| 100 | "_source→target_", but it also tracks "_target→source_". |
| 101 | But backtracking does not work for interwiki links, since the Fossil |
| 102 | running on the target has no way of scanning the source text and |
| 103 | hence has no way of knowing that it is a target of a link from the source. |
| 104 | |
| 105 | [fcfg]: /help?cmd=config |
| 106 | |
| 107 |
+10
-9
| --- www/makefile.wiki | ||
| +++ www/makefile.wiki | ||
| @@ -7,11 +7,11 @@ | ||
| 7 | 7 | before it is compiled. Most users will download a |
| 8 | 8 | [https://fossil-scm.org/home/uv/download.html | precompiled binary] |
| 9 | 9 | so this is of no consequence to them, and even those who |
| 10 | 10 | want to compile the code themselves can use one of the |
| 11 | 11 | [./build.wiki | existing makefiles]. |
| 12 | -So must people do not need to be concerned with the | |
| 12 | +So most people do not need to be concerned with the | |
| 13 | 13 | build complexities of Fossil. But hard-core developers who desire |
| 14 | 14 | a deep understanding of how Fossil is put together can benefit |
| 15 | 15 | from reviewing this article. |
| 16 | 16 | |
| 17 | 17 | <h1 id="srctour">2.0 Source Code Tour</h1> |
| @@ -56,21 +56,21 @@ | ||
| 56 | 56 | The TH1 script engine is implemented using files: |
| 57 | 57 | |
| 58 | 58 | 9. th.c |
| 59 | 59 | 10. th.h |
| 60 | 60 | |
| 61 | -The proprocessing steps are omitted for all of these imported | |
| 61 | +The preprocessing steps are omitted for all of these imported | |
| 62 | 62 | files. |
| 63 | 63 | |
| 64 | 64 | The VERSION.h header file is generated from other information sources |
| 65 | 65 | using a small program called: |
| 66 | 66 | |
| 67 | 67 | 11. [/file/tools/mkversion.c | mkversion.c] |
| 68 | 68 | |
| 69 | 69 | The builtin_data.h header file contains the definitions of C-language |
| 70 | 70 | byte-array constants that contain various resources such as scripts and |
| 71 | -images. The builtin_data.h header file is generate from the original | |
| 71 | +images. The builtin_data.h header file is generated from the original | |
| 72 | 72 | resource files using a small program called: |
| 73 | 73 | |
| 74 | 74 | 12 [/file/tools/mkbuiltin.c | mkbuiltin.c] |
| 75 | 75 | |
| 76 | 76 | Examples of built-in resources include the [/file/src/diff.tcl | diff.tcl] |
| @@ -132,11 +132,11 @@ | ||
| 132 | 132 | the exceptions described above. |
| 133 | 133 | |
| 134 | 134 | <h1>3.0 Automatically generated files</h1> |
| 135 | 135 | |
| 136 | 136 | The "VERSION.h" header file contains some C preprocessor macros that |
| 137 | -identify the version of Fossil that is to be build. The VERSION.h file is | |
| 137 | +identify the version of Fossil that is to be built. The VERSION.h file is | |
| 138 | 138 | generated automatically from information extracted from the "manifest", |
| 139 | 139 | "manifest.uuid", and "VERSION" source files in the root directory of the |
| 140 | 140 | source tree. |
| 141 | 141 | (The "manifest" and "manifest.uuid" files are automatically generated and |
| 142 | 142 | updated by Fossil itself. See the [/help/setting | fossil set manifest] |
| @@ -294,12 +294,12 @@ | ||
| 294 | 294 | link against the standard C library. No other libraries or external |
| 295 | 295 | dependences are used. |
| 296 | 296 | |
| 297 | 297 | <h1>7.0 Debugging</h1> |
| 298 | 298 | |
| 299 | -Debug mode is controlled via FOSSIL_DEBUG preprocessor macro which could be | |
| 300 | -set explicitly at the make command for the target platform. | |
| 299 | +Debug mode is controlled via a FOSSIL_DEBUG preprocessor macro. This can be | |
| 300 | +set explicitly with the make command for the target platform. | |
| 301 | 301 | |
| 302 | 302 | However, in practice it is instead recommended to add a respective configure |
| 303 | 303 | option for the target platform and then perform a clean build. This way the |
| 304 | 304 | Debug flags are consistently applied across the whole build process. For |
| 305 | 305 | example, use these Debug flags in addition to other flags passed to the |
| @@ -313,14 +313,15 @@ | ||
| 313 | 313 | On Windows: |
| 314 | 314 | <pre> |
| 315 | 315 | win\buildmsvc.bat FOSSIL_DEBUG=1 |
| 316 | 316 | </pre> |
| 317 | 317 | |
| 318 | -The resulting fossil binary could then be loaded into a platform-specific | |
| 318 | +The resulting fossil binary can then be loaded into a platform-specific | |
| 319 | 319 | debugger. Source files displayed in the debugger correspond to the ones |
| 320 | -generated from the translation stage of the build process, that is what was | |
| 321 | -actually compiled into the object files. | |
| 320 | +generated from the translation stage of the build process, as that is what | |
| 321 | +was actually compiled into the respective object files that make up the | |
| 322 | +fossil binary. | |
| 322 | 323 | |
| 323 | 324 | <h1>8.0 See Also</h1> |
| 324 | 325 | |
| 325 | 326 | * [./tech_overview.wiki | A Technical Overview Of Fossil] |
| 326 | 327 | * [./adding_code.wiki | How To Add Features To Fossil] |
| 327 | 328 |
| --- www/makefile.wiki | |
| +++ www/makefile.wiki | |
| @@ -7,11 +7,11 @@ | |
| 7 | before it is compiled. Most users will download a |
| 8 | [https://fossil-scm.org/home/uv/download.html | precompiled binary] |
| 9 | so this is of no consequence to them, and even those who |
| 10 | want to compile the code themselves can use one of the |
| 11 | [./build.wiki | existing makefiles]. |
| 12 | So must people do not need to be concerned with the |
| 13 | build complexities of Fossil. But hard-core developers who desire |
| 14 | a deep understanding of how Fossil is put together can benefit |
| 15 | from reviewing this article. |
| 16 | |
| 17 | <h1 id="srctour">2.0 Source Code Tour</h1> |
| @@ -56,21 +56,21 @@ | |
| 56 | The TH1 script engine is implemented using files: |
| 57 | |
| 58 | 9. th.c |
| 59 | 10. th.h |
| 60 | |
| 61 | The proprocessing steps are omitted for all of these imported |
| 62 | files. |
| 63 | |
| 64 | The VERSION.h header file is generated from other information sources |
| 65 | using a small program called: |
| 66 | |
| 67 | 11. [/file/tools/mkversion.c | mkversion.c] |
| 68 | |
| 69 | The builtin_data.h header file contains the definitions of C-language |
| 70 | byte-array constants that contain various resources such as scripts and |
| 71 | images. The builtin_data.h header file is generate from the original |
| 72 | resource files using a small program called: |
| 73 | |
| 74 | 12 [/file/tools/mkbuiltin.c | mkbuiltin.c] |
| 75 | |
| 76 | Examples of built-in resources include the [/file/src/diff.tcl | diff.tcl] |
| @@ -132,11 +132,11 @@ | |
| 132 | the exceptions described above. |
| 133 | |
| 134 | <h1>3.0 Automatically generated files</h1> |
| 135 | |
| 136 | The "VERSION.h" header file contains some C preprocessor macros that |
| 137 | identify the version of Fossil that is to be build. The VERSION.h file is |
| 138 | generated automatically from information extracted from the "manifest", |
| 139 | "manifest.uuid", and "VERSION" source files in the root directory of the |
| 140 | source tree. |
| 141 | (The "manifest" and "manifest.uuid" files are automatically generated and |
| 142 | updated by Fossil itself. See the [/help/setting | fossil set manifest] |
| @@ -294,12 +294,12 @@ | |
| 294 | link against the standard C library. No other libraries or external |
| 295 | dependences are used. |
| 296 | |
| 297 | <h1>7.0 Debugging</h1> |
| 298 | |
| 299 | Debug mode is controlled via FOSSIL_DEBUG preprocessor macro which could be |
| 300 | set explicitly at the make command for the target platform. |
| 301 | |
| 302 | However, in practice it is instead recommended to add a respective configure |
| 303 | option for the target platform and then perform a clean build. This way the |
| 304 | Debug flags are consistently applied across the whole build process. For |
| 305 | example, use these Debug flags in addition to other flags passed to the |
| @@ -313,14 +313,15 @@ | |
| 313 | On Windows: |
| 314 | <pre> |
| 315 | win\buildmsvc.bat FOSSIL_DEBUG=1 |
| 316 | </pre> |
| 317 | |
| 318 | The resulting fossil binary could then be loaded into a platform-specific |
| 319 | debugger. Source files displayed in the debugger correspond to the ones |
| 320 | generated from the translation stage of the build process, that is what was |
| 321 | actually compiled into the object files. |
| 322 | |
| 323 | <h1>8.0 See Also</h1> |
| 324 | |
| 325 | * [./tech_overview.wiki | A Technical Overview Of Fossil] |
| 326 | * [./adding_code.wiki | How To Add Features To Fossil] |
| 327 |
| --- www/makefile.wiki | |
| +++ www/makefile.wiki | |
| @@ -7,11 +7,11 @@ | |
| 7 | before it is compiled. Most users will download a |
| 8 | [https://fossil-scm.org/home/uv/download.html | precompiled binary] |
| 9 | so this is of no consequence to them, and even those who |
| 10 | want to compile the code themselves can use one of the |
| 11 | [./build.wiki | existing makefiles]. |
| 12 | So most people do not need to be concerned with the |
| 13 | build complexities of Fossil. But hard-core developers who desire |
| 14 | a deep understanding of how Fossil is put together can benefit |
| 15 | from reviewing this article. |
| 16 | |
| 17 | <h1 id="srctour">2.0 Source Code Tour</h1> |
| @@ -56,21 +56,21 @@ | |
| 56 | The TH1 script engine is implemented using files: |
| 57 | |
| 58 | 9. th.c |
| 59 | 10. th.h |
| 60 | |
| 61 | The preprocessing steps are omitted for all of these imported |
| 62 | files. |
| 63 | |
| 64 | The VERSION.h header file is generated from other information sources |
| 65 | using a small program called: |
| 66 | |
| 67 | 11. [/file/tools/mkversion.c | mkversion.c] |
| 68 | |
| 69 | The builtin_data.h header file contains the definitions of C-language |
| 70 | byte-array constants that contain various resources such as scripts and |
| 71 | images. The builtin_data.h header file is generated from the original |
| 72 | resource files using a small program called: |
| 73 | |
| 74 | 12 [/file/tools/mkbuiltin.c | mkbuiltin.c] |
| 75 | |
| 76 | Examples of built-in resources include the [/file/src/diff.tcl | diff.tcl] |
| @@ -132,11 +132,11 @@ | |
| 132 | the exceptions described above. |
| 133 | |
| 134 | <h1>3.0 Automatically generated files</h1> |
| 135 | |
| 136 | The "VERSION.h" header file contains some C preprocessor macros that |
| 137 | identify the version of Fossil that is to be built. The VERSION.h file is |
| 138 | generated automatically from information extracted from the "manifest", |
| 139 | "manifest.uuid", and "VERSION" source files in the root directory of the |
| 140 | source tree. |
| 141 | (The "manifest" and "manifest.uuid" files are automatically generated and |
| 142 | updated by Fossil itself. See the [/help/setting | fossil set manifest] |
| @@ -294,12 +294,12 @@ | |
| 294 | link against the standard C library. No other libraries or external |
| 295 | dependences are used. |
| 296 | |
| 297 | <h1>7.0 Debugging</h1> |
| 298 | |
| 299 | Debug mode is controlled via a FOSSIL_DEBUG preprocessor macro. This can be |
| 300 | set explicitly with the make command for the target platform. |
| 301 | |
| 302 | However, in practice it is instead recommended to add a respective configure |
| 303 | option for the target platform and then perform a clean build. This way the |
| 304 | Debug flags are consistently applied across the whole build process. For |
| 305 | example, use these Debug flags in addition to other flags passed to the |
| @@ -313,14 +313,15 @@ | |
| 313 | On Windows: |
| 314 | <pre> |
| 315 | win\buildmsvc.bat FOSSIL_DEBUG=1 |
| 316 | </pre> |
| 317 | |
| 318 | The resulting fossil binary can then be loaded into a platform-specific |
| 319 | debugger. Source files displayed in the debugger correspond to the ones |
| 320 | generated from the translation stage of the build process, as that is what |
| 321 | was actually compiled into the respective object files that make up the |
| 322 | fossil binary. |
| 323 | |
| 324 | <h1>8.0 See Also</h1> |
| 325 | |
| 326 | * [./tech_overview.wiki | A Technical Overview Of Fossil] |
| 327 | * [./adding_code.wiki | How To Add Features To Fossil] |
| 328 |
+2
-1
| --- www/newrepo.wiki | ||
| +++ www/newrepo.wiki | ||
| @@ -57,11 +57,12 @@ | ||
| 57 | 57 | $ fossil open ../demo.fossil |
| 58 | 58 | </verbatim> |
| 59 | 59 | |
| 60 | 60 | That creates a file called <tt>_FOSSIL_</tt> in the current |
| 61 | 61 | directory, and this file contains all kinds of fossil-related |
| 62 | -information about your local repository. You can ignore it | |
| 62 | +information about your local repository. Under Linux, the BSDs or | |
| 63 | +macOS, this will instead be called <tt>.fslckout</tt>. You can ignore it | |
| 63 | 64 | for all purposes, but be sure not to accidentally remove it |
| 64 | 65 | or otherwise damage it - it belongs to fossil, not you. |
| 65 | 66 | |
| 66 | 67 | The next thing we need to do is add files to our repository. As it |
| 67 | 68 | happens, we have a few C source files lying around, which we'll |
| 68 | 69 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -57,11 +57,12 @@ | |
| 57 | $ fossil open ../demo.fossil |
| 58 | </verbatim> |
| 59 | |
| 60 | That creates a file called <tt>_FOSSIL_</tt> in the current |
| 61 | directory, and this file contains all kinds of fossil-related |
| 62 | information about your local repository. You can ignore it |
| 63 | for all purposes, but be sure not to accidentally remove it |
| 64 | or otherwise damage it - it belongs to fossil, not you. |
| 65 | |
| 66 | The next thing we need to do is add files to our repository. As it |
| 67 | happens, we have a few C source files lying around, which we'll |
| 68 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -57,11 +57,12 @@ | |
| 57 | $ fossil open ../demo.fossil |
| 58 | </verbatim> |
| 59 | |
| 60 | That creates a file called <tt>_FOSSIL_</tt> in the current |
| 61 | directory, and this file contains all kinds of fossil-related |
| 62 | information about your local repository. Under Linux, the BSDs or |
| 63 | macOS, this will instead be called <tt>.fslckout</tt>. You can ignore it |
| 64 | for all purposes, but be sure not to accidentally remove it |
| 65 | or otherwise damage it - it belongs to fossil, not you. |
| 66 | |
| 67 | The next thing we need to do is add files to our repository. As it |
| 68 | happens, we have a few C source files lying around, which we'll |
| 69 |
+1
-1
| --- www/password.wiki | ||
| +++ www/password.wiki | ||
| @@ -123,11 +123,11 @@ | ||
| 123 | 123 | </pre> |
| 124 | 124 | |
| 125 | 125 | For older clients, the password is used for the shared secret as stated |
| 126 | 126 | in the URL and with no encoding. |
| 127 | 127 | For newer clients, the shared secret is derived from the password |
| 128 | -by transformed the password using the SHA1 hash encoding | |
| 128 | +by transforming the password using the SHA1 hash encoding | |
| 129 | 129 | described above. However, if the first character of the password is |
| 130 | 130 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 131 | 131 | is used directly as the share secret without the SHA1 encoding. |
| 132 | 132 | |
| 133 | 133 | <pre> |
| 134 | 134 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -123,11 +123,11 @@ | |
| 123 | </pre> |
| 124 | |
| 125 | For older clients, the password is used for the shared secret as stated |
| 126 | in the URL and with no encoding. |
| 127 | For newer clients, the shared secret is derived from the password |
| 128 | by transformed the password using the SHA1 hash encoding |
| 129 | described above. However, if the first character of the password is |
| 130 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 131 | is used directly as the share secret without the SHA1 encoding. |
| 132 | |
| 133 | <pre> |
| 134 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -123,11 +123,11 @@ | |
| 123 | </pre> |
| 124 | |
| 125 | For older clients, the password is used for the shared secret as stated |
| 126 | in the URL and with no encoding. |
| 127 | For newer clients, the shared secret is derived from the password |
| 128 | by transforming the password using the SHA1 hash encoding |
| 129 | described above. However, if the first character of the password is |
| 130 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 131 | is used directly as the share secret without the SHA1 encoding. |
| 132 | |
| 133 | <pre> |
| 134 |
+4
-4
| --- www/patchcmd.md | ||
| +++ www/patchcmd.md | ||
| @@ -9,11 +9,11 @@ | ||
| 9 | 9 | "fossil patch push" command to make a copy of all your changes on the |
| 10 | 10 | remote Linux server: |
| 11 | 11 | |
| 12 | 12 | fossil patch push linuxserver:/path/to/checkout |
| 13 | 13 | |
| 14 | -In the previous "linuxserver" is the name of the remote machine and | |
| 14 | +In the previous line "linuxserver" is the name of the remote machine and | |
| 15 | 15 | "/path/to/checkout" is an existing checkout directory for the same project |
| 16 | 16 | on the remote machine. |
| 17 | 17 | |
| 18 | 18 | The "fossil patch push" command works by first creating a patch file, |
| 19 | 19 | then transfering that patch file to the remote machine using "ssh", then |
| @@ -85,11 +85,11 @@ | ||
| 85 | 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | 86 | changes in an SQLite database file. If the argument to "fossil patch create" |
| 87 | 87 | is a filename, then the patch-file database is written into that file. |
| 88 | 88 | If the argument is "-" then the database is written on standard output. |
| 89 | 89 | |
| 90 | -The "fossil patch apply" command reads the database that is the patch file | |
| 90 | +The "fossil patch apply" command reads the patch-file database | |
| 91 | 91 | and applies it to the local check-out. If a filename is given as an |
| 92 | 92 | argument, then the database is read from that file. If the argument is "-" |
| 93 | 93 | then the database is read from standard input. |
| 94 | 94 | |
| 95 | 95 | Hence the command: |
| @@ -102,11 +102,11 @@ | ||
| 102 | 102 | |
| 103 | 103 | Likewise, a command like this: |
| 104 | 104 | |
| 105 | 105 | fossil patch pull remote:projB |
| 106 | 106 | |
| 107 | -Could be entered like this: | |
| 107 | +could be entered like this: | |
| 108 | 108 | |
| 109 | 109 | ssh -T remote 'cd projB;fossil patch create -' | fossil patch apply - |
| 110 | 110 | |
| 111 | -The "fossil patch view" command just opens the database file and prints | |
| 111 | +The "fossil patch view" command just opens the patch-file database and prints | |
| 112 | 112 | a summary of its contents on standard output. |
| 113 | 113 |
| --- www/patchcmd.md | |
| +++ www/patchcmd.md | |
| @@ -9,11 +9,11 @@ | |
| 9 | "fossil patch push" command to make a copy of all your changes on the |
| 10 | remote Linux server: |
| 11 | |
| 12 | fossil patch push linuxserver:/path/to/checkout |
| 13 | |
| 14 | In the previous "linuxserver" is the name of the remote machine and |
| 15 | "/path/to/checkout" is an existing checkout directory for the same project |
| 16 | on the remote machine. |
| 17 | |
| 18 | The "fossil patch push" command works by first creating a patch file, |
| 19 | then transfering that patch file to the remote machine using "ssh", then |
| @@ -85,11 +85,11 @@ | |
| 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | changes in an SQLite database file. If the argument to "fossil patch create" |
| 87 | is a filename, then the patch-file database is written into that file. |
| 88 | If the argument is "-" then the database is written on standard output. |
| 89 | |
| 90 | The "fossil patch apply" command reads the database that is the patch file |
| 91 | and applies it to the local check-out. If a filename is given as an |
| 92 | argument, then the database is read from that file. If the argument is "-" |
| 93 | then the database is read from standard input. |
| 94 | |
| 95 | Hence the command: |
| @@ -102,11 +102,11 @@ | |
| 102 | |
| 103 | Likewise, a command like this: |
| 104 | |
| 105 | fossil patch pull remote:projB |
| 106 | |
| 107 | Could be entered like this: |
| 108 | |
| 109 | ssh -T remote 'cd projB;fossil patch create -' | fossil patch apply - |
| 110 | |
| 111 | The "fossil patch view" command just opens the database file and prints |
| 112 | a summary of its contents on standard output. |
| 113 |
| --- www/patchcmd.md | |
| +++ www/patchcmd.md | |
| @@ -9,11 +9,11 @@ | |
| 9 | "fossil patch push" command to make a copy of all your changes on the |
| 10 | remote Linux server: |
| 11 | |
| 12 | fossil patch push linuxserver:/path/to/checkout |
| 13 | |
| 14 | In the previous line "linuxserver" is the name of the remote machine and |
| 15 | "/path/to/checkout" is an existing checkout directory for the same project |
| 16 | on the remote machine. |
| 17 | |
| 18 | The "fossil patch push" command works by first creating a patch file, |
| 19 | then transfering that patch file to the remote machine using "ssh", then |
| @@ -85,11 +85,11 @@ | |
| 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | changes in an SQLite database file. If the argument to "fossil patch create" |
| 87 | is a filename, then the patch-file database is written into that file. |
| 88 | If the argument is "-" then the database is written on standard output. |
| 89 | |
| 90 | The "fossil patch apply" command reads the patch-file database |
| 91 | and applies it to the local check-out. If a filename is given as an |
| 92 | argument, then the database is read from that file. If the argument is "-" |
| 93 | then the database is read from standard input. |
| 94 | |
| 95 | Hence the command: |
| @@ -102,11 +102,11 @@ | |
| 102 | |
| 103 | Likewise, a command like this: |
| 104 | |
| 105 | fossil patch pull remote:projB |
| 106 | |
| 107 | could be entered like this: |
| 108 | |
| 109 | ssh -T remote 'cd projB;fossil patch create -' | fossil patch apply - |
| 110 | |
| 111 | The "fossil patch view" command just opens the patch-file database and prints |
| 112 | a summary of its contents on standard output. |
| 113 |
+2
-2
| --- www/pikchr.md | ||
| +++ www/pikchr.md | ||
| @@ -1,9 +1,9 @@ | ||
| 1 | 1 | # The Pikchr Diagram Language |
| 2 | 2 | |
| 3 | 3 | Pikchr (pronounced "picture") is a [PIC][1]-like markup language for creating |
| 4 | -diagrams in technical documentation. Pikchr diagrams source text | |
| 4 | +diagrams in technical documentation. Source text for Pikchr diagrams | |
| 5 | 5 | can be embedded directly in either [Markdown][2] or [Fossil Wiki][3]. |
| 6 | 6 | Fossil translates the Pikchr source text into SVG which is displayed as |
| 7 | 7 | part of the rendered wiki. |
| 8 | 8 | |
| 9 | 9 | [1]: wikipedia:/wiki/Pic_language |
| @@ -134,6 +134,6 @@ | ||
| 134 | 134 | |
| 135 | 135 | * **float-right** → The diagram is shown at the right margin and |
| 136 | 136 | text fills in around the diagram. |
| 137 | 137 | |
| 138 | 138 | * **source** → The display starts out showing the Pikchr source text. |
| 139 | - The reader must click (or Alt-click or Ctrl-click) to set the diagram. | |
| 139 | + The reader must click (or Alt-click or Ctrl-click) to show the diagram. | |
| 140 | 140 |
| --- www/pikchr.md | |
| +++ www/pikchr.md | |
| @@ -1,9 +1,9 @@ | |
| 1 | # The Pikchr Diagram Language |
| 2 | |
| 3 | Pikchr (pronounced "picture") is a [PIC][1]-like markup language for creating |
| 4 | diagrams in technical documentation. Pikchr diagrams source text |
| 5 | can be embedded directly in either [Markdown][2] or [Fossil Wiki][3]. |
| 6 | Fossil translates the Pikchr source text into SVG which is displayed as |
| 7 | part of the rendered wiki. |
| 8 | |
| 9 | [1]: wikipedia:/wiki/Pic_language |
| @@ -134,6 +134,6 @@ | |
| 134 | |
| 135 | * **float-right** → The diagram is shown at the right margin and |
| 136 | text fills in around the diagram. |
| 137 | |
| 138 | * **source** → The display starts out showing the Pikchr source text. |
| 139 | The reader must click (or Alt-click or Ctrl-click) to set the diagram. |
| 140 |
| --- www/pikchr.md | |
| +++ www/pikchr.md | |
| @@ -1,9 +1,9 @@ | |
| 1 | # The Pikchr Diagram Language |
| 2 | |
| 3 | Pikchr (pronounced "picture") is a [PIC][1]-like markup language for creating |
| 4 | diagrams in technical documentation. Source text for Pikchr diagrams |
| 5 | can be embedded directly in either [Markdown][2] or [Fossil Wiki][3]. |
| 6 | Fossil translates the Pikchr source text into SVG which is displayed as |
| 7 | part of the rendered wiki. |
| 8 | |
| 9 | [1]: wikipedia:/wiki/Pic_language |
| @@ -134,6 +134,6 @@ | |
| 134 | |
| 135 | * **float-right** → The diagram is shown at the right margin and |
| 136 | text fills in around the diagram. |
| 137 | |
| 138 | * **source** → The display starts out showing the Pikchr source text. |
| 139 | The reader must click (or Alt-click or Ctrl-click) to show the diagram. |
| 140 |
+1
-1
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -364,11 +364,11 @@ | ||
| 364 | 364 | abbreviation to the 40-character |
| 365 | 365 | artifact identifier for a particular check-in, or it can be a |
| 366 | 366 | date/time stamp. ([./checkin_names.wiki | more info]) |
| 367 | 367 | If you omit |
| 368 | 368 | the <i>VERSION</i>, then fossil moves you to the |
| 369 | -latest version of the branch your are currently on. | |
| 369 | +latest version of the branch you are currently on. | |
| 370 | 370 | |
| 371 | 371 | The default behavior is for [./concepts.wiki#workflow|autosync] to |
| 372 | 372 | be turned on. That means that a [/help/pull|pull] automatically occurs |
| 373 | 373 | when you run [/help/update|update] and a [/help/push|push] happens |
| 374 | 374 | automatically after you [/help/commit|commit]. So in normal practice, |
| 375 | 375 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -364,11 +364,11 @@ | |
| 364 | abbreviation to the 40-character |
| 365 | artifact identifier for a particular check-in, or it can be a |
| 366 | date/time stamp. ([./checkin_names.wiki | more info]) |
| 367 | If you omit |
| 368 | the <i>VERSION</i>, then fossil moves you to the |
| 369 | latest version of the branch your are currently on. |
| 370 | |
| 371 | The default behavior is for [./concepts.wiki#workflow|autosync] to |
| 372 | be turned on. That means that a [/help/pull|pull] automatically occurs |
| 373 | when you run [/help/update|update] and a [/help/push|push] happens |
| 374 | automatically after you [/help/commit|commit]. So in normal practice, |
| 375 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -364,11 +364,11 @@ | |
| 364 | abbreviation to the 40-character |
| 365 | artifact identifier for a particular check-in, or it can be a |
| 366 | date/time stamp. ([./checkin_names.wiki | more info]) |
| 367 | If you omit |
| 368 | the <i>VERSION</i>, then fossil moves you to the |
| 369 | latest version of the branch you are currently on. |
| 370 | |
| 371 | The default behavior is for [./concepts.wiki#workflow|autosync] to |
| 372 | be turned on. That means that a [/help/pull|pull] automatically occurs |
| 373 | when you run [/help/update|update] and a [/help/push|push] happens |
| 374 | automatically after you [/help/commit|commit]. So in normal practice, |
| 375 |
+2
-2
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -224,16 +224,16 @@ | ||
| 224 | 224 | you are keeping private branches. Or, to put it another way, you are |
| 225 | 225 | doing siloed development. You are not sharing your intermediate work |
| 226 | 226 | with collaborators. This is not good for product quality. |
| 227 | 227 | |
| 228 | 228 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 229 | -that best predictor of bugs is the distance on the org-chart between | |
| 229 | +that the best predictor of bugs is the distance on the org-chart between | |
| 230 | 230 | the stake-holders. The bug rate is inversely related to the |
| 231 | 231 | amount of communication among the engineers. |
| 232 | 232 | Similar findings arise in other disciplines. Keeping |
| 233 | 233 | private branches does not prove that developers are communicating |
| 234 | -insufficiently, but it is a key symptom that problem. | |
| 234 | +insufficiently, but it is a key symptom of that problem. | |
| 235 | 235 | |
| 236 | 236 | [Weinberg][weinberg] argues programming should be "egoless." That |
| 237 | 237 | is to say, programmers should avoid linking their code with their sense of |
| 238 | 238 | self, as that makes it more difficult for them to find and respond |
| 239 | 239 | to bugs, and hence makes them less productive. Many developers are |
| 240 | 240 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -224,16 +224,16 @@ | |
| 224 | you are keeping private branches. Or, to put it another way, you are |
| 225 | doing siloed development. You are not sharing your intermediate work |
| 226 | with collaborators. This is not good for product quality. |
| 227 | |
| 228 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 229 | that best predictor of bugs is the distance on the org-chart between |
| 230 | the stake-holders. The bug rate is inversely related to the |
| 231 | amount of communication among the engineers. |
| 232 | Similar findings arise in other disciplines. Keeping |
| 233 | private branches does not prove that developers are communicating |
| 234 | insufficiently, but it is a key symptom that problem. |
| 235 | |
| 236 | [Weinberg][weinberg] argues programming should be "egoless." That |
| 237 | is to say, programmers should avoid linking their code with their sense of |
| 238 | self, as that makes it more difficult for them to find and respond |
| 239 | to bugs, and hence makes them less productive. Many developers are |
| 240 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -224,16 +224,16 @@ | |
| 224 | you are keeping private branches. Or, to put it another way, you are |
| 225 | doing siloed development. You are not sharing your intermediate work |
| 226 | with collaborators. This is not good for product quality. |
| 227 | |
| 228 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 229 | that the best predictor of bugs is the distance on the org-chart between |
| 230 | the stake-holders. The bug rate is inversely related to the |
| 231 | amount of communication among the engineers. |
| 232 | Similar findings arise in other disciplines. Keeping |
| 233 | private branches does not prove that developers are communicating |
| 234 | insufficiently, but it is a key symptom of that problem. |
| 235 | |
| 236 | [Weinberg][weinberg] argues programming should be "egoless." That |
| 237 | is to say, programmers should avoid linking their code with their sense of |
| 238 | self, as that makes it more difficult for them to find and respond |
| 239 | to bugs, and hence makes them less productive. Many developers are |
| 240 |
+1
-1
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -13,11 +13,11 @@ | ||
| 13 | 13 | |
| 14 | 14 | <h2>Atomic Check-ins With Rollback</h2> |
| 15 | 15 | |
| 16 | 16 | The Fossil repository is stored in an |
| 17 | 17 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 18 | -([./tech_overview.wiki | Addition information] about the repository | |
| 18 | +([./tech_overview.wiki | Additional information] about the repository | |
| 19 | 19 | file format.) |
| 20 | 20 | SQLite is very mature and stable and has been in wide-spread use for many |
| 21 | 21 | years, so we are confident it will not cause repository |
| 22 | 22 | corruption. SQLite |
| 23 | 23 | databases do not corrupt even if a program or system crash or power |
| 24 | 24 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | |
| 14 | <h2>Atomic Check-ins With Rollback</h2> |
| 15 | |
| 16 | The Fossil repository is stored in an |
| 17 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 18 | ([./tech_overview.wiki | Addition information] about the repository |
| 19 | file format.) |
| 20 | SQLite is very mature and stable and has been in wide-spread use for many |
| 21 | years, so we are confident it will not cause repository |
| 22 | corruption. SQLite |
| 23 | databases do not corrupt even if a program or system crash or power |
| 24 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | |
| 14 | <h2>Atomic Check-ins With Rollback</h2> |
| 15 | |
| 16 | The Fossil repository is stored in an |
| 17 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 18 | ([./tech_overview.wiki | Additional information] about the repository |
| 19 | file format.) |
| 20 | SQLite is very mature and stable and has been in wide-spread use for many |
| 21 | years, so we are confident it will not cause repository |
| 22 | corruption. SQLite |
| 23 | databases do not corrupt even if a program or system crash or power |
| 24 |
+1
-1
| --- www/selfhost.wiki | ||
| +++ www/selfhost.wiki | ||
| @@ -27,11 +27,11 @@ | ||
| 27 | 27 | hosts <a href="http://www.sqlite.org/">SQLite</a> and over a |
| 28 | 28 | dozen other smaller projects. This demonstrates that Fossil can run on |
| 29 | 29 | a low-power host processor. |
| 30 | 30 | Multiple fossil-based projects can easily be hosted on the same machine, |
| 31 | 31 | even if that machine is itself one of several dozen virtual machines on |
| 32 | -single physical box. The CGI script that runs the canonical Fossil | |
| 32 | +a single physical box. The CGI script that runs the canonical Fossil | |
| 33 | 33 | self-hosting repository is as follows: |
| 34 | 34 | |
| 35 | 35 | <pre> |
| 36 | 36 | #!/usr/bin/fossil |
| 37 | 37 | repository: /fossil/fossil.fossil |
| 38 | 38 |
| --- www/selfhost.wiki | |
| +++ www/selfhost.wiki | |
| @@ -27,11 +27,11 @@ | |
| 27 | hosts <a href="http://www.sqlite.org/">SQLite</a> and over a |
| 28 | dozen other smaller projects. This demonstrates that Fossil can run on |
| 29 | a low-power host processor. |
| 30 | Multiple fossil-based projects can easily be hosted on the same machine, |
| 31 | even if that machine is itself one of several dozen virtual machines on |
| 32 | single physical box. The CGI script that runs the canonical Fossil |
| 33 | self-hosting repository is as follows: |
| 34 | |
| 35 | <pre> |
| 36 | #!/usr/bin/fossil |
| 37 | repository: /fossil/fossil.fossil |
| 38 |
| --- www/selfhost.wiki | |
| +++ www/selfhost.wiki | |
| @@ -27,11 +27,11 @@ | |
| 27 | hosts <a href="http://www.sqlite.org/">SQLite</a> and over a |
| 28 | dozen other smaller projects. This demonstrates that Fossil can run on |
| 29 | a low-power host processor. |
| 30 | Multiple fossil-based projects can easily be hosted on the same machine, |
| 31 | even if that machine is itself one of several dozen virtual machines on |
| 32 | a single physical box. The CGI script that runs the canonical Fossil |
| 33 | self-hosting repository is as follows: |
| 34 | |
| 35 | <pre> |
| 36 | #!/usr/bin/fossil |
| 37 | repository: /fossil/fossil.fossil |
| 38 |