Fossil SCM
Fix many typos in the documentation. Also capitalize words like "Unix", "Unicode", "Windows", and "Boolean". (FWIW: Except in the case of "Windows", I'm dubious about the capitalization, but I appreciate the typo fixes so we'll just go with the whole package.)
Commit
fe38a768db2ccfefb7188c2c3ef9c782ee53dc0f
Parent
e7ec49815b98881…
29 files changed
+1
-1
+1
-1
+1
-1
+4
-4
+15
-15
+9
-9
+1
-1
+2
-2
+2
-2
+1
-1
+2
-2
+2
-2
+3
-3
+8
-8
+5
-5
+1
-1
+1
-1
+1
-1
+3
-3
+4
-4
+2
-2
+1
-1
+1
-1
+4
-4
+3
-3
+2
-2
+7
-7
+4
-4
+5
-5
~
www/adding_code.wiki
~
www/antibot.wiki
~
www/branching.wiki
~
www/build.wiki
~
www/changes.wiki
~
www/checkin_names.wiki
~
www/concepts.wiki
~
www/contribute.wiki
~
www/copyright-release.html
~
www/delta_format.wiki
~
www/faq.tcl
~
www/faq.wiki
~
www/fileformat.wiki
~
www/fiveminutes.wiki
~
www/fossil-v-git.wiki
~
www/hints.wiki
~
www/inout.wiki
~
www/mkindex.tcl
~
www/permutedindex.html
~
www/private.wiki
~
www/quickstart.wiki
~
www/quotes.wiki
~
www/selfcheck.wiki
~
www/server.wiki
~
www/stats.wiki
~
www/style.wiki
~
www/tech_overview.wiki
~
www/th1.md
~
www/webui.wiki
+1
-1
| --- www/adding_code.wiki | ||
| +++ www/adding_code.wiki | ||
| @@ -150,11 +150,11 @@ | ||
| 150 | 150 | "<i>commandname</i><b>_cmd</b>", as is done in the example. |
| 151 | 151 | |
| 152 | 152 | You could also use "printf()" instead of "fossil_print()" to generate |
| 153 | 153 | the output text, if desired. But "fossil_print()" is recommended as |
| 154 | 154 | it has extra logic to insert \r characters at the right times on |
| 155 | -windows systems. | |
| 155 | +Windows systems. | |
| 156 | 156 | |
| 157 | 157 | Once you have the command running, you can then start adding code to |
| 158 | 158 | make it do useful things. There are lots of utility functions in |
| 159 | 159 | Fossil for parsing command-line options and for |
| 160 | 160 | opening and accessing and manipulating the repository and |
| 161 | 161 |
| --- www/adding_code.wiki | |
| +++ www/adding_code.wiki | |
| @@ -150,11 +150,11 @@ | |
| 150 | "<i>commandname</i><b>_cmd</b>", as is done in the example. |
| 151 | |
| 152 | You could also use "printf()" instead of "fossil_print()" to generate |
| 153 | the output text, if desired. But "fossil_print()" is recommended as |
| 154 | it has extra logic to insert \r characters at the right times on |
| 155 | windows systems. |
| 156 | |
| 157 | Once you have the command running, you can then start adding code to |
| 158 | make it do useful things. There are lots of utility functions in |
| 159 | Fossil for parsing command-line options and for |
| 160 | opening and accessing and manipulating the repository and |
| 161 |
| --- www/adding_code.wiki | |
| +++ www/adding_code.wiki | |
| @@ -150,11 +150,11 @@ | |
| 150 | "<i>commandname</i><b>_cmd</b>", as is done in the example. |
| 151 | |
| 152 | You could also use "printf()" instead of "fossil_print()" to generate |
| 153 | the output text, if desired. But "fossil_print()" is recommended as |
| 154 | it has extra logic to insert \r characters at the right times on |
| 155 | Windows systems. |
| 156 | |
| 157 | Once you have the command running, you can then start adding code to |
| 158 | make it do useful things. There are lots of utility functions in |
| 159 | Fossil for parsing command-line options and for |
| 160 | opening and accessing and manipulating the repository and |
| 161 |
+1
-1
| --- www/antibot.wiki | ||
| +++ www/antibot.wiki | ||
| @@ -59,11 +59,11 @@ | ||
| 59 | 59 | <li> Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) |
| 60 | 60 | <li> Wget/1.12 (openbsd4.9) |
| 61 | 61 | </ul> |
| 62 | 62 | |
| 63 | 63 | The first two UserAgent strings above identify Firefox 19 and |
| 64 | -Internet Explorer 8.0, both running on windows NT. The third | |
| 64 | +Internet Explorer 8.0, both running on Windows NT. The third | |
| 65 | 65 | example is the spider used by Google to index the internet. |
| 66 | 66 | The fourth example is the "wget" utility running on OpenBSD. |
| 67 | 67 | Thus the first two UserAgent strings above identify the requestor |
| 68 | 68 | as human whereas the second two identify the requestor as a spider. |
| 69 | 69 | Note that the UserAgent string is completely under the control |
| 70 | 70 |
| --- www/antibot.wiki | |
| +++ www/antibot.wiki | |
| @@ -59,11 +59,11 @@ | |
| 59 | <li> Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) |
| 60 | <li> Wget/1.12 (openbsd4.9) |
| 61 | </ul> |
| 62 | |
| 63 | The first two UserAgent strings above identify Firefox 19 and |
| 64 | Internet Explorer 8.0, both running on windows NT. The third |
| 65 | example is the spider used by Google to index the internet. |
| 66 | The fourth example is the "wget" utility running on OpenBSD. |
| 67 | Thus the first two UserAgent strings above identify the requestor |
| 68 | as human whereas the second two identify the requestor as a spider. |
| 69 | Note that the UserAgent string is completely under the control |
| 70 |
| --- www/antibot.wiki | |
| +++ www/antibot.wiki | |
| @@ -59,11 +59,11 @@ | |
| 59 | <li> Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) |
| 60 | <li> Wget/1.12 (openbsd4.9) |
| 61 | </ul> |
| 62 | |
| 63 | The first two UserAgent strings above identify Firefox 19 and |
| 64 | Internet Explorer 8.0, both running on Windows NT. The third |
| 65 | example is the spider used by Google to index the internet. |
| 66 | The fourth example is the "wget" utility running on OpenBSD. |
| 67 | Thus the first two UserAgent strings above identify the requestor |
| 68 | as human whereas the second two identify the requestor as a spider. |
| 69 | Note that the UserAgent string is completely under the control |
| 70 |
+1
-1
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -187,11 +187,11 @@ | ||
| 187 | 187 | as it encounters another check-in with the same tag. A cancellation tag |
| 188 | 188 | is attached to a single check-in in order to either override a one-time |
| 189 | 189 | tag that was previously placed on that same check-in, or to block |
| 190 | 190 | tag propagation from an ancestor. |
| 191 | 191 | |
| 192 | -The initial checkin of every repository has two propagating tags. In | |
| 192 | +The initial check-in of every repository has two propagating tags. In | |
| 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 | 198 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -187,11 +187,11 @@ | |
| 187 | as it encounters another check-in with the same tag. A cancellation tag |
| 188 | is attached to a single check-in in order to either override a one-time |
| 189 | tag that was previously placed on that same check-in, or to block |
| 190 | tag propagation from an ancestor. |
| 191 | |
| 192 | The initial checkin of every repository has two propagating tags. In |
| 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 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -187,11 +187,11 @@ | |
| 187 | as it encounters another check-in with the same tag. A cancellation tag |
| 188 | is attached to a single check-in in order to either override a one-time |
| 189 | tag that was previously placed on that same check-in, or to block |
| 190 | tag propagation from an ancestor. |
| 191 | |
| 192 | The initial check-in of every repository has two propagating tags. In |
| 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 |
+4
-4
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -78,11 +78,11 @@ | ||
| 78 | 78 | <ol> |
| 79 | 79 | <li value="5"> |
| 80 | 80 | <p>Unpack the ZIP or tarball you downloaded then |
| 81 | 81 | <b>cd</b> into the directory created.</p></li> |
| 82 | 82 | |
| 83 | -<li><i>(Optional, unix only)</i> | |
| 83 | +<li><i>(Optional, Unix only)</i> | |
| 84 | 84 | Run <b>./configure</b> to construct a makefile. |
| 85 | 85 | |
| 86 | 86 | <ol type="a"> |
| 87 | 87 | <li><p> |
| 88 | 88 | If you do not have the OpenSSL library installed on your system, then |
| @@ -100,11 +100,11 @@ | ||
| 100 | 100 | <li><p>Run "<b>make</b>" to build the "fossil" or "fossil.exe" executable. |
| 101 | 101 | The details depend on your platform and compiler. |
| 102 | 102 | |
| 103 | 103 | <ol type="a"> |
| 104 | 104 | <li><p><i>Unix</i> → the configure-generated Makefile should work on |
| 105 | -all unix and unix-like systems. Simply type "<b>make</b>". | |
| 105 | +all Unix and Unix-like systems. Simply type "<b>make</b>". | |
| 106 | 106 | |
| 107 | 107 | <li><p><i>Unix without running "configure"</i> → if you prefer to avoid running configure, you |
| 108 | 108 | can also use: <b>make -f Makefile.classic</b>. You may want to make minor |
| 109 | 109 | edits to Makefile.classic to configure the build for your system. |
| 110 | 110 | |
| @@ -132,11 +132,11 @@ | ||
| 132 | 132 | </pre></blockquote> |
| 133 | 133 | <blockquote><pre> |
| 134 | 134 | buildmsvc.bat FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin |
| 135 | 135 | </pre></blockquote> |
| 136 | 136 | |
| 137 | -<li><p><i>Cygwin</i> → The same as other unix-like systems. It is | |
| 137 | +<li><p><i>Cygwin</i> → The same as other Unix-like systems. It is | |
| 138 | 138 | recommended to configure using: "<b>configure --disable-internal-sqlite</b>", |
| 139 | 139 | making sure you have the "libsqlite3-devel" , "zlib-devel" and |
| 140 | 140 | "openssl-devel" packages installed first. |
| 141 | 141 | </ol> |
| 142 | 142 | </ol> |
| @@ -143,11 +143,11 @@ | ||
| 143 | 143 | |
| 144 | 144 | <h2>3.0 Installing</h2> |
| 145 | 145 | |
| 146 | 146 | <ol> |
| 147 | 147 | <li value="8"> |
| 148 | -<p>The finished binary is named "fossil" (or "fossil.exe" on windows). | |
| 148 | +<p>The finished binary is named "fossil" (or "fossil.exe" on Windows). | |
| 149 | 149 | Put this binary in a |
| 150 | 150 | directory that is somewhere on your PATH environment variable. |
| 151 | 151 | It does not matter where.</p> |
| 152 | 152 | |
| 153 | 153 | <li> |
| 154 | 154 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -78,11 +78,11 @@ | |
| 78 | <ol> |
| 79 | <li value="5"> |
| 80 | <p>Unpack the ZIP or tarball you downloaded then |
| 81 | <b>cd</b> into the directory created.</p></li> |
| 82 | |
| 83 | <li><i>(Optional, unix only)</i> |
| 84 | Run <b>./configure</b> to construct a makefile. |
| 85 | |
| 86 | <ol type="a"> |
| 87 | <li><p> |
| 88 | If you do not have the OpenSSL library installed on your system, then |
| @@ -100,11 +100,11 @@ | |
| 100 | <li><p>Run "<b>make</b>" to build the "fossil" or "fossil.exe" executable. |
| 101 | The details depend on your platform and compiler. |
| 102 | |
| 103 | <ol type="a"> |
| 104 | <li><p><i>Unix</i> → the configure-generated Makefile should work on |
| 105 | all unix and unix-like systems. Simply type "<b>make</b>". |
| 106 | |
| 107 | <li><p><i>Unix without running "configure"</i> → if you prefer to avoid running configure, you |
| 108 | can also use: <b>make -f Makefile.classic</b>. You may want to make minor |
| 109 | edits to Makefile.classic to configure the build for your system. |
| 110 | |
| @@ -132,11 +132,11 @@ | |
| 132 | </pre></blockquote> |
| 133 | <blockquote><pre> |
| 134 | buildmsvc.bat FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin |
| 135 | </pre></blockquote> |
| 136 | |
| 137 | <li><p><i>Cygwin</i> → The same as other unix-like systems. It is |
| 138 | recommended to configure using: "<b>configure --disable-internal-sqlite</b>", |
| 139 | making sure you have the "libsqlite3-devel" , "zlib-devel" and |
| 140 | "openssl-devel" packages installed first. |
| 141 | </ol> |
| 142 | </ol> |
| @@ -143,11 +143,11 @@ | |
| 143 | |
| 144 | <h2>3.0 Installing</h2> |
| 145 | |
| 146 | <ol> |
| 147 | <li value="8"> |
| 148 | <p>The finished binary is named "fossil" (or "fossil.exe" on windows). |
| 149 | Put this binary in a |
| 150 | directory that is somewhere on your PATH environment variable. |
| 151 | It does not matter where.</p> |
| 152 | |
| 153 | <li> |
| 154 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -78,11 +78,11 @@ | |
| 78 | <ol> |
| 79 | <li value="5"> |
| 80 | <p>Unpack the ZIP or tarball you downloaded then |
| 81 | <b>cd</b> into the directory created.</p></li> |
| 82 | |
| 83 | <li><i>(Optional, Unix only)</i> |
| 84 | Run <b>./configure</b> to construct a makefile. |
| 85 | |
| 86 | <ol type="a"> |
| 87 | <li><p> |
| 88 | If you do not have the OpenSSL library installed on your system, then |
| @@ -100,11 +100,11 @@ | |
| 100 | <li><p>Run "<b>make</b>" to build the "fossil" or "fossil.exe" executable. |
| 101 | The details depend on your platform and compiler. |
| 102 | |
| 103 | <ol type="a"> |
| 104 | <li><p><i>Unix</i> → the configure-generated Makefile should work on |
| 105 | all Unix and Unix-like systems. Simply type "<b>make</b>". |
| 106 | |
| 107 | <li><p><i>Unix without running "configure"</i> → if you prefer to avoid running configure, you |
| 108 | can also use: <b>make -f Makefile.classic</b>. You may want to make minor |
| 109 | edits to Makefile.classic to configure the build for your system. |
| 110 | |
| @@ -132,11 +132,11 @@ | |
| 132 | </pre></blockquote> |
| 133 | <blockquote><pre> |
| 134 | buildmsvc.bat FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1 PERLDIR=C:\full\path\to\Perl\bin |
| 135 | </pre></blockquote> |
| 136 | |
| 137 | <li><p><i>Cygwin</i> → The same as other Unix-like systems. It is |
| 138 | recommended to configure using: "<b>configure --disable-internal-sqlite</b>", |
| 139 | making sure you have the "libsqlite3-devel" , "zlib-devel" and |
| 140 | "openssl-devel" packages installed first. |
| 141 | </ol> |
| 142 | </ol> |
| @@ -143,11 +143,11 @@ | |
| 143 | |
| 144 | <h2>3.0 Installing</h2> |
| 145 | |
| 146 | <ol> |
| 147 | <li value="8"> |
| 148 | <p>The finished binary is named "fossil" (or "fossil.exe" on Windows). |
| 149 | Put this binary in a |
| 150 | directory that is somewhere on your PATH environment variable. |
| 151 | It does not matter where.</p> |
| 152 | |
| 153 | <li> |
| 154 |
+15
-15
| --- www/changes.wiki | ||
| +++ www/changes.wiki | ||
| @@ -95,11 +95,11 @@ | ||
| 95 | 95 | and [/help?cmd=/artifact|/artifact] pages. |
| 96 | 96 | * Most commands now issue errors rather than silently ignoring unrecognized |
| 97 | 97 | command-line options. |
| 98 | 98 | * Use full 40-character SHA1 hashes (instead of abbreviations) in most |
| 99 | 99 | internal URLs. |
| 100 | - * The "ssh:" sync method on windows now uses "plink.exe" instead of "ssh" as | |
| 100 | + * The "ssh:" sync method on Windows now uses "plink.exe" instead of "ssh" as | |
| 101 | 101 | the secure-shell client program. |
| 102 | 102 | * Prevent a partial clone when the connection is lost. |
| 103 | 103 | * Make the distinction between 301 and 302 redirects. |
| 104 | 104 | * Allow commits against a closed check-in as long as the commit goes onto |
| 105 | 105 | a different branch. |
| @@ -246,11 +246,11 @@ | ||
| 246 | 246 | * Renamed <tt>/stats_report</tt> page to [/reports]. Graph width is now |
| 247 | 247 | relative, not absolute. |
| 248 | 248 | * Added <tt>yw=YYYY-WW</tt> (year-week) filter to timeline to limit the results |
| 249 | 249 | to a specific year and calendar week number, e.g. [/timeline?yw=2013-01]. |
| 250 | 250 | * Updates to SQLite to prevent opening a repository file using file descriptors |
| 251 | - 1 or 2 on unix. This fixes a bug under which an assertion failure could | |
| 251 | + 1 or 2 on Unix. This fixes a bug under which an assertion failure could | |
| 252 | 252 | overwrite part of a repository database file, corrupting it. |
| 253 | 253 | * Added support for unlimited line lengths in side-by-side diffs. |
| 254 | 254 | * New --close option to [/help?cmd=commit | fossil commit], which |
| 255 | 255 | immediately closes the branch being committed. |
| 256 | 256 | * Added <tt>chart</tt> option to [/help?cmd=bisect | fossil bisect]. |
| @@ -269,11 +269,11 @@ | ||
| 269 | 269 | [/help?cmd=server | fossil server] commands can take an IP address in addition |
| 270 | 270 | to the port number, causing Fossil to bind to just that one IP address. |
| 271 | 271 | * After prompting for a password, also ask if that password should be |
| 272 | 272 | remembered. |
| 273 | 273 | * Performance improvements to the diff engine. |
| 274 | - * Fix the side-by-side diff engine to work better with multi-byte unicode text. | |
| 274 | + * Fix the side-by-side diff engine to work better with multi-byte Unicode text. | |
| 275 | 275 | * Color-coding in the web-based annotation (blame) display. Fix the annotation |
| 276 | 276 | engine so that it is no longer confused by time-warps. |
| 277 | 277 | * The markdown formatter is now available by default and can be used for |
| 278 | 278 | tickets, wiki, and embedded documentation. |
| 279 | 279 | * Add subcommands "fossil bisect log" and "fossil bisect status" to the |
| @@ -328,11 +328,11 @@ | ||
| 328 | 328 | sorts by the indicated column. |
| 329 | 329 | * Add the "fossil cat" command which is basically an alias for |
| 330 | 330 | "fossil finfo -p". |
| 331 | 331 | * Hyperlinks with the class "button" are rendered as submenu buttons |
| 332 | 332 | on embedded documentation. |
| 333 | - * The check-in comment editor on windows now defaults to NotePad.exe. | |
| 333 | + * The check-in comment editor on Windows now defaults to NotePad.exe. | |
| 334 | 334 | * Correctly deal with BOMs in check-in comments. Also attempt to convert |
| 335 | 335 | check-in comments to UTF8 from other encodings. |
| 336 | 336 | * Allow the deletion of multiple stash entries using multiple arguments |
| 337 | 337 | to the "fossil stash rm" command. |
| 338 | 338 | * Enhance the "fossil server DIRECTORY" command to serve static content |
| @@ -363,11 +363,11 @@ | ||
| 363 | 363 | --allow-conflict. |
| 364 | 364 | * Optionally require a CAPTCHA (controlled by a setting on the |
| 365 | 365 | Admin/Access webpage) when a user who is not logged in tries to |
| 366 | 366 | edit wiki, or a ticket, or an attachment. |
| 367 | 367 | * Improvements to the "ssh://" sync protocol, to help it move past |
| 368 | - noisey motd comments. | |
| 368 | + noisy motd comments. | |
| 369 | 369 | * Add the uf=FILE-SHA1-HASH query parameter to the timeline, causing the |
| 370 | 370 | timeline to show only check-ins that contain the specific file identified |
| 371 | 371 | by FILE-SHA1-HASH. ("uf" stands for "uses file".) |
| 372 | 372 | * Enhance the file change annotator so that it follows the file across |
| 373 | 373 | name changes. |
| @@ -382,11 +382,11 @@ | ||
| 382 | 382 | * Disallow invalid UTF8 characters (such as characters in the surrogate |
| 383 | 383 | pair range) in filenames. |
| 384 | 384 | * Judge the UserAgent strings issued by the NetSurf webbrowser to be |
| 385 | 385 | coming from a human, not from a bot. |
| 386 | 386 | * Add the zlib sources to the Fossil source tree (under compat/zlib) and |
| 387 | - use those sources when compiling on (windows) systems that do not have | |
| 387 | + use those sources when compiling on (Windows) systems that do not have | |
| 388 | 388 | a zlib library installed by default. |
| 389 | 389 | * Prompt the user with the option to convert non-UTF8 files into UTF8 |
| 390 | 390 | when committing. |
| 391 | 391 | * Allow the characters <nowiki>*[]?</nowiki> in filenames. |
| 392 | 392 | * Allow the --context option on diff commands to have a value of 0. |
| @@ -402,25 +402,25 @@ | ||
| 402 | 402 | * Allow style= attribute to occur in HTML markup on wiki pages. |
| 403 | 403 | * Added the --tk option to the "fossi diff" and "fossil stash diff" |
| 404 | 404 | commands, causing color-coded diff output to be displayed in a Tcl/Tk |
| 405 | 405 | GUI window. This option only works if Tcl/Tk is installed on the |
| 406 | 406 | host. |
| 407 | - * On windows, make the "gdiff" command default to use WinDiff.exe. | |
| 407 | + * On Windows, make the "gdiff" command default to use WinDiff.exe. | |
| 408 | 408 | * Update the "fossil stash" command so that it always prompts for a |
| 409 | 409 | comment if the -m option is omitted. |
| 410 | 410 | * Enhance the timeline webpages so that a=, b=, c=, d=, p=, and dp= |
| 411 | - query parameters (and others) can all accept any valid checkin name | |
| 411 | + query parameters (and others) can all accept any valid check-in name | |
| 412 | 412 | (such as branch names or labels) instead of just SHA1 hashes. |
| 413 | 413 | * Added the "fossil stash show" command. |
| 414 | 414 | * Added the "fileage" webpage with links to this page from the check-in |
| 415 | 415 | information page and from the file browser. |
| 416 | 416 | * Added --age and -t options to the "fossil ls" command. |
| 417 | 417 | * Added the --setmtime option to "fossil update". When used, the mtime |
| 418 | - of all mananged files is set to the time when the most recent version of | |
| 418 | + of all managed files is set to the time when the most recent version of | |
| 419 | 419 | the file was checked in. |
| 420 | 420 | * Changed the "vdiff" webpage to show the complete text of files that |
| 421 | - were added or removed (the equivelent of using the -N or --newfile | |
| 421 | + were added or removed (the equivalent of using the -N or --newfile | |
| 422 | 422 | options with the "fossil diff" command-line.) |
| 423 | 423 | * Added the --temp option to "fossil clean" and "fossil extra", causing |
| 424 | 424 | those commands to only look at temporary files generated by Fossil, |
| 425 | 425 | such as merge-conflict reports or aborted check-in messages. |
| 426 | 426 | * Enhance the raw page download so that it can guess the mimetype of |
| @@ -466,11 +466,11 @@ | ||
| 466 | 466 | * Merge the latest SQLite changes from upstream. |
| 467 | 467 | * Lots of minor bug fixes. |
| 468 | 468 | |
| 469 | 469 | <h2>Changes For Version 1.23 (2012-08-08)</h2> |
| 470 | 470 | * The default checkout database name is now ".fslckout" instead of |
| 471 | - "_FOSSIL_" on unix. Both names continue to work. | |
| 471 | + "_FOSSIL_" on Unix. Both names continue to work. | |
| 472 | 472 | * Added the "fossil all changes" command |
| 473 | 473 | * Added the --ckout option to the "fossil all list" command |
| 474 | 474 | * Added the "public-pages" glob pattern that can be configured to allow |
| 475 | 475 | anonymous users to see embedded documentation on sites where source |
| 476 | 476 | code should not be accessible to anonymous users. |
| @@ -563,11 +563,11 @@ | ||
| 563 | 563 | * Fixed constant prompting regarding previously-saved SSL |
| 564 | 564 | certificates. [636804745b] |
| 565 | 565 | * Other SSL improvements. |
| 566 | 566 | * Added -R REPOFILE support to several more CLI commands. [e080560378] |
| 567 | 567 | * Generated tarballs now have constant timestamps, so they are |
| 568 | - always identical for any given checkin. [e080560378] | |
| 568 | + always identical for any given check-in. [e080560378] | |
| 569 | 569 | * A number of minor HTML-related tweaks and fixes. |
| 570 | 570 | * Added --args FILENAME global CLI argument to import arbitrary |
| 571 | 571 | CLI arguments from a file (e.g. long file lists). [e080560378] |
| 572 | 572 | * Fixed significant memory leak in annotation of files with long |
| 573 | 573 | histories.[9929bab702] |
| @@ -587,15 +587,15 @@ | ||
| 587 | 587 | * Update the built-in SQLite to version 3.7.9 beta. |
| 588 | 588 | |
| 589 | 589 | <h2>Changes For Version 1.19 (2011-09-02)</h2> |
| 590 | 590 | * Added a ./configure script based on autosetup. |
| 591 | 591 | * Added the "[/help/winsrv | fossil winsrv]" command |
| 592 | - for creating a Fossil service on windows systems. | |
| 592 | + for creating a Fossil service on Windows systems. | |
| 593 | 593 | * Added "versionable settings" where settings that affect |
| 594 | 594 | the local tree can be stored in versioned files in the |
| 595 | 595 | .fossil-settings directory. |
| 596 | - * Background colors for branches are choosen automatically if no | |
| 596 | + * Background colors for branches are chosen automatically if no | |
| 597 | 597 | color is specified by the user. |
| 598 | 598 | * The status, changes and extras commands now show |
| 599 | 599 | pathnames relative to the current working directory, |
| 600 | 600 | unless overridden by command line options or the |
| 601 | 601 | "relative-paths" setting.<br><b>WARNING:</b> This |
| @@ -606,11 +606,11 @@ | ||
| 606 | 606 | * Added support for client-side SSL certificates with "ssl-identity" |
| 607 | 607 | setting and --ssl-identity option. |
| 608 | 608 | * Added "ssl-ca-location" setting to specify trusted root |
| 609 | 609 | SSL certificates. |
| 610 | 610 | * Added the --case-sensitive BOOLEAN command-line option to many commands. |
| 611 | - Default to true for unix and false for windows. | |
| 611 | + Default to true for Unix and false for Windows. | |
| 612 | 612 | * Added the "Color-Test" submenu button on the branch list web page. |
| 613 | 613 | * Compatibility improvements to the git-export feature. |
| 614 | 614 | * Performance improvements on SHA1 checksums |
| 615 | 615 | * Update to the latest SQLite version 3.7.8 alpha. |
| 616 | 616 | * Fix the tarball generator to work with very log pathnames |
| 617 | 617 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -95,11 +95,11 @@ | |
| 95 | and [/help?cmd=/artifact|/artifact] pages. |
| 96 | * Most commands now issue errors rather than silently ignoring unrecognized |
| 97 | command-line options. |
| 98 | * Use full 40-character SHA1 hashes (instead of abbreviations) in most |
| 99 | internal URLs. |
| 100 | * The "ssh:" sync method on windows now uses "plink.exe" instead of "ssh" as |
| 101 | the secure-shell client program. |
| 102 | * Prevent a partial clone when the connection is lost. |
| 103 | * Make the distinction between 301 and 302 redirects. |
| 104 | * Allow commits against a closed check-in as long as the commit goes onto |
| 105 | a different branch. |
| @@ -246,11 +246,11 @@ | |
| 246 | * Renamed <tt>/stats_report</tt> page to [/reports]. Graph width is now |
| 247 | relative, not absolute. |
| 248 | * Added <tt>yw=YYYY-WW</tt> (year-week) filter to timeline to limit the results |
| 249 | to a specific year and calendar week number, e.g. [/timeline?yw=2013-01]. |
| 250 | * Updates to SQLite to prevent opening a repository file using file descriptors |
| 251 | 1 or 2 on unix. This fixes a bug under which an assertion failure could |
| 252 | overwrite part of a repository database file, corrupting it. |
| 253 | * Added support for unlimited line lengths in side-by-side diffs. |
| 254 | * New --close option to [/help?cmd=commit | fossil commit], which |
| 255 | immediately closes the branch being committed. |
| 256 | * Added <tt>chart</tt> option to [/help?cmd=bisect | fossil bisect]. |
| @@ -269,11 +269,11 @@ | |
| 269 | [/help?cmd=server | fossil server] commands can take an IP address in addition |
| 270 | to the port number, causing Fossil to bind to just that one IP address. |
| 271 | * After prompting for a password, also ask if that password should be |
| 272 | remembered. |
| 273 | * Performance improvements to the diff engine. |
| 274 | * Fix the side-by-side diff engine to work better with multi-byte unicode text. |
| 275 | * Color-coding in the web-based annotation (blame) display. Fix the annotation |
| 276 | engine so that it is no longer confused by time-warps. |
| 277 | * The markdown formatter is now available by default and can be used for |
| 278 | tickets, wiki, and embedded documentation. |
| 279 | * Add subcommands "fossil bisect log" and "fossil bisect status" to the |
| @@ -328,11 +328,11 @@ | |
| 328 | sorts by the indicated column. |
| 329 | * Add the "fossil cat" command which is basically an alias for |
| 330 | "fossil finfo -p". |
| 331 | * Hyperlinks with the class "button" are rendered as submenu buttons |
| 332 | on embedded documentation. |
| 333 | * The check-in comment editor on windows now defaults to NotePad.exe. |
| 334 | * Correctly deal with BOMs in check-in comments. Also attempt to convert |
| 335 | check-in comments to UTF8 from other encodings. |
| 336 | * Allow the deletion of multiple stash entries using multiple arguments |
| 337 | to the "fossil stash rm" command. |
| 338 | * Enhance the "fossil server DIRECTORY" command to serve static content |
| @@ -363,11 +363,11 @@ | |
| 363 | --allow-conflict. |
| 364 | * Optionally require a CAPTCHA (controlled by a setting on the |
| 365 | Admin/Access webpage) when a user who is not logged in tries to |
| 366 | edit wiki, or a ticket, or an attachment. |
| 367 | * Improvements to the "ssh://" sync protocol, to help it move past |
| 368 | noisey motd comments. |
| 369 | * Add the uf=FILE-SHA1-HASH query parameter to the timeline, causing the |
| 370 | timeline to show only check-ins that contain the specific file identified |
| 371 | by FILE-SHA1-HASH. ("uf" stands for "uses file".) |
| 372 | * Enhance the file change annotator so that it follows the file across |
| 373 | name changes. |
| @@ -382,11 +382,11 @@ | |
| 382 | * Disallow invalid UTF8 characters (such as characters in the surrogate |
| 383 | pair range) in filenames. |
| 384 | * Judge the UserAgent strings issued by the NetSurf webbrowser to be |
| 385 | coming from a human, not from a bot. |
| 386 | * Add the zlib sources to the Fossil source tree (under compat/zlib) and |
| 387 | use those sources when compiling on (windows) systems that do not have |
| 388 | a zlib library installed by default. |
| 389 | * Prompt the user with the option to convert non-UTF8 files into UTF8 |
| 390 | when committing. |
| 391 | * Allow the characters <nowiki>*[]?</nowiki> in filenames. |
| 392 | * Allow the --context option on diff commands to have a value of 0. |
| @@ -402,25 +402,25 @@ | |
| 402 | * Allow style= attribute to occur in HTML markup on wiki pages. |
| 403 | * Added the --tk option to the "fossi diff" and "fossil stash diff" |
| 404 | commands, causing color-coded diff output to be displayed in a Tcl/Tk |
| 405 | GUI window. This option only works if Tcl/Tk is installed on the |
| 406 | host. |
| 407 | * On windows, make the "gdiff" command default to use WinDiff.exe. |
| 408 | * Update the "fossil stash" command so that it always prompts for a |
| 409 | comment if the -m option is omitted. |
| 410 | * Enhance the timeline webpages so that a=, b=, c=, d=, p=, and dp= |
| 411 | query parameters (and others) can all accept any valid checkin name |
| 412 | (such as branch names or labels) instead of just SHA1 hashes. |
| 413 | * Added the "fossil stash show" command. |
| 414 | * Added the "fileage" webpage with links to this page from the check-in |
| 415 | information page and from the file browser. |
| 416 | * Added --age and -t options to the "fossil ls" command. |
| 417 | * Added the --setmtime option to "fossil update". When used, the mtime |
| 418 | of all mananged files is set to the time when the most recent version of |
| 419 | the file was checked in. |
| 420 | * Changed the "vdiff" webpage to show the complete text of files that |
| 421 | were added or removed (the equivelent of using the -N or --newfile |
| 422 | options with the "fossil diff" command-line.) |
| 423 | * Added the --temp option to "fossil clean" and "fossil extra", causing |
| 424 | those commands to only look at temporary files generated by Fossil, |
| 425 | such as merge-conflict reports or aborted check-in messages. |
| 426 | * Enhance the raw page download so that it can guess the mimetype of |
| @@ -466,11 +466,11 @@ | |
| 466 | * Merge the latest SQLite changes from upstream. |
| 467 | * Lots of minor bug fixes. |
| 468 | |
| 469 | <h2>Changes For Version 1.23 (2012-08-08)</h2> |
| 470 | * The default checkout database name is now ".fslckout" instead of |
| 471 | "_FOSSIL_" on unix. Both names continue to work. |
| 472 | * Added the "fossil all changes" command |
| 473 | * Added the --ckout option to the "fossil all list" command |
| 474 | * Added the "public-pages" glob pattern that can be configured to allow |
| 475 | anonymous users to see embedded documentation on sites where source |
| 476 | code should not be accessible to anonymous users. |
| @@ -563,11 +563,11 @@ | |
| 563 | * Fixed constant prompting regarding previously-saved SSL |
| 564 | certificates. [636804745b] |
| 565 | * Other SSL improvements. |
| 566 | * Added -R REPOFILE support to several more CLI commands. [e080560378] |
| 567 | * Generated tarballs now have constant timestamps, so they are |
| 568 | always identical for any given checkin. [e080560378] |
| 569 | * A number of minor HTML-related tweaks and fixes. |
| 570 | * Added --args FILENAME global CLI argument to import arbitrary |
| 571 | CLI arguments from a file (e.g. long file lists). [e080560378] |
| 572 | * Fixed significant memory leak in annotation of files with long |
| 573 | histories.[9929bab702] |
| @@ -587,15 +587,15 @@ | |
| 587 | * Update the built-in SQLite to version 3.7.9 beta. |
| 588 | |
| 589 | <h2>Changes For Version 1.19 (2011-09-02)</h2> |
| 590 | * Added a ./configure script based on autosetup. |
| 591 | * Added the "[/help/winsrv | fossil winsrv]" command |
| 592 | for creating a Fossil service on windows systems. |
| 593 | * Added "versionable settings" where settings that affect |
| 594 | the local tree can be stored in versioned files in the |
| 595 | .fossil-settings directory. |
| 596 | * Background colors for branches are choosen automatically if no |
| 597 | color is specified by the user. |
| 598 | * The status, changes and extras commands now show |
| 599 | pathnames relative to the current working directory, |
| 600 | unless overridden by command line options or the |
| 601 | "relative-paths" setting.<br><b>WARNING:</b> This |
| @@ -606,11 +606,11 @@ | |
| 606 | * Added support for client-side SSL certificates with "ssl-identity" |
| 607 | setting and --ssl-identity option. |
| 608 | * Added "ssl-ca-location" setting to specify trusted root |
| 609 | SSL certificates. |
| 610 | * Added the --case-sensitive BOOLEAN command-line option to many commands. |
| 611 | Default to true for unix and false for windows. |
| 612 | * Added the "Color-Test" submenu button on the branch list web page. |
| 613 | * Compatibility improvements to the git-export feature. |
| 614 | * Performance improvements on SHA1 checksums |
| 615 | * Update to the latest SQLite version 3.7.8 alpha. |
| 616 | * Fix the tarball generator to work with very log pathnames |
| 617 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -95,11 +95,11 @@ | |
| 95 | and [/help?cmd=/artifact|/artifact] pages. |
| 96 | * Most commands now issue errors rather than silently ignoring unrecognized |
| 97 | command-line options. |
| 98 | * Use full 40-character SHA1 hashes (instead of abbreviations) in most |
| 99 | internal URLs. |
| 100 | * The "ssh:" sync method on Windows now uses "plink.exe" instead of "ssh" as |
| 101 | the secure-shell client program. |
| 102 | * Prevent a partial clone when the connection is lost. |
| 103 | * Make the distinction between 301 and 302 redirects. |
| 104 | * Allow commits against a closed check-in as long as the commit goes onto |
| 105 | a different branch. |
| @@ -246,11 +246,11 @@ | |
| 246 | * Renamed <tt>/stats_report</tt> page to [/reports]. Graph width is now |
| 247 | relative, not absolute. |
| 248 | * Added <tt>yw=YYYY-WW</tt> (year-week) filter to timeline to limit the results |
| 249 | to a specific year and calendar week number, e.g. [/timeline?yw=2013-01]. |
| 250 | * Updates to SQLite to prevent opening a repository file using file descriptors |
| 251 | 1 or 2 on Unix. This fixes a bug under which an assertion failure could |
| 252 | overwrite part of a repository database file, corrupting it. |
| 253 | * Added support for unlimited line lengths in side-by-side diffs. |
| 254 | * New --close option to [/help?cmd=commit | fossil commit], which |
| 255 | immediately closes the branch being committed. |
| 256 | * Added <tt>chart</tt> option to [/help?cmd=bisect | fossil bisect]. |
| @@ -269,11 +269,11 @@ | |
| 269 | [/help?cmd=server | fossil server] commands can take an IP address in addition |
| 270 | to the port number, causing Fossil to bind to just that one IP address. |
| 271 | * After prompting for a password, also ask if that password should be |
| 272 | remembered. |
| 273 | * Performance improvements to the diff engine. |
| 274 | * Fix the side-by-side diff engine to work better with multi-byte Unicode text. |
| 275 | * Color-coding in the web-based annotation (blame) display. Fix the annotation |
| 276 | engine so that it is no longer confused by time-warps. |
| 277 | * The markdown formatter is now available by default and can be used for |
| 278 | tickets, wiki, and embedded documentation. |
| 279 | * Add subcommands "fossil bisect log" and "fossil bisect status" to the |
| @@ -328,11 +328,11 @@ | |
| 328 | sorts by the indicated column. |
| 329 | * Add the "fossil cat" command which is basically an alias for |
| 330 | "fossil finfo -p". |
| 331 | * Hyperlinks with the class "button" are rendered as submenu buttons |
| 332 | on embedded documentation. |
| 333 | * The check-in comment editor on Windows now defaults to NotePad.exe. |
| 334 | * Correctly deal with BOMs in check-in comments. Also attempt to convert |
| 335 | check-in comments to UTF8 from other encodings. |
| 336 | * Allow the deletion of multiple stash entries using multiple arguments |
| 337 | to the "fossil stash rm" command. |
| 338 | * Enhance the "fossil server DIRECTORY" command to serve static content |
| @@ -363,11 +363,11 @@ | |
| 363 | --allow-conflict. |
| 364 | * Optionally require a CAPTCHA (controlled by a setting on the |
| 365 | Admin/Access webpage) when a user who is not logged in tries to |
| 366 | edit wiki, or a ticket, or an attachment. |
| 367 | * Improvements to the "ssh://" sync protocol, to help it move past |
| 368 | noisy motd comments. |
| 369 | * Add the uf=FILE-SHA1-HASH query parameter to the timeline, causing the |
| 370 | timeline to show only check-ins that contain the specific file identified |
| 371 | by FILE-SHA1-HASH. ("uf" stands for "uses file".) |
| 372 | * Enhance the file change annotator so that it follows the file across |
| 373 | name changes. |
| @@ -382,11 +382,11 @@ | |
| 382 | * Disallow invalid UTF8 characters (such as characters in the surrogate |
| 383 | pair range) in filenames. |
| 384 | * Judge the UserAgent strings issued by the NetSurf webbrowser to be |
| 385 | coming from a human, not from a bot. |
| 386 | * Add the zlib sources to the Fossil source tree (under compat/zlib) and |
| 387 | use those sources when compiling on (Windows) systems that do not have |
| 388 | a zlib library installed by default. |
| 389 | * Prompt the user with the option to convert non-UTF8 files into UTF8 |
| 390 | when committing. |
| 391 | * Allow the characters <nowiki>*[]?</nowiki> in filenames. |
| 392 | * Allow the --context option on diff commands to have a value of 0. |
| @@ -402,25 +402,25 @@ | |
| 402 | * Allow style= attribute to occur in HTML markup on wiki pages. |
| 403 | * Added the --tk option to the "fossi diff" and "fossil stash diff" |
| 404 | commands, causing color-coded diff output to be displayed in a Tcl/Tk |
| 405 | GUI window. This option only works if Tcl/Tk is installed on the |
| 406 | host. |
| 407 | * On Windows, make the "gdiff" command default to use WinDiff.exe. |
| 408 | * Update the "fossil stash" command so that it always prompts for a |
| 409 | comment if the -m option is omitted. |
| 410 | * Enhance the timeline webpages so that a=, b=, c=, d=, p=, and dp= |
| 411 | query parameters (and others) can all accept any valid check-in name |
| 412 | (such as branch names or labels) instead of just SHA1 hashes. |
| 413 | * Added the "fossil stash show" command. |
| 414 | * Added the "fileage" webpage with links to this page from the check-in |
| 415 | information page and from the file browser. |
| 416 | * Added --age and -t options to the "fossil ls" command. |
| 417 | * Added the --setmtime option to "fossil update". When used, the mtime |
| 418 | of all managed files is set to the time when the most recent version of |
| 419 | the file was checked in. |
| 420 | * Changed the "vdiff" webpage to show the complete text of files that |
| 421 | were added or removed (the equivalent of using the -N or --newfile |
| 422 | options with the "fossil diff" command-line.) |
| 423 | * Added the --temp option to "fossil clean" and "fossil extra", causing |
| 424 | those commands to only look at temporary files generated by Fossil, |
| 425 | such as merge-conflict reports or aborted check-in messages. |
| 426 | * Enhance the raw page download so that it can guess the mimetype of |
| @@ -466,11 +466,11 @@ | |
| 466 | * Merge the latest SQLite changes from upstream. |
| 467 | * Lots of minor bug fixes. |
| 468 | |
| 469 | <h2>Changes For Version 1.23 (2012-08-08)</h2> |
| 470 | * The default checkout database name is now ".fslckout" instead of |
| 471 | "_FOSSIL_" on Unix. Both names continue to work. |
| 472 | * Added the "fossil all changes" command |
| 473 | * Added the --ckout option to the "fossil all list" command |
| 474 | * Added the "public-pages" glob pattern that can be configured to allow |
| 475 | anonymous users to see embedded documentation on sites where source |
| 476 | code should not be accessible to anonymous users. |
| @@ -563,11 +563,11 @@ | |
| 563 | * Fixed constant prompting regarding previously-saved SSL |
| 564 | certificates. [636804745b] |
| 565 | * Other SSL improvements. |
| 566 | * Added -R REPOFILE support to several more CLI commands. [e080560378] |
| 567 | * Generated tarballs now have constant timestamps, so they are |
| 568 | always identical for any given check-in. [e080560378] |
| 569 | * A number of minor HTML-related tweaks and fixes. |
| 570 | * Added --args FILENAME global CLI argument to import arbitrary |
| 571 | CLI arguments from a file (e.g. long file lists). [e080560378] |
| 572 | * Fixed significant memory leak in annotation of files with long |
| 573 | histories.[9929bab702] |
| @@ -587,15 +587,15 @@ | |
| 587 | * Update the built-in SQLite to version 3.7.9 beta. |
| 588 | |
| 589 | <h2>Changes For Version 1.19 (2011-09-02)</h2> |
| 590 | * Added a ./configure script based on autosetup. |
| 591 | * Added the "[/help/winsrv | fossil winsrv]" command |
| 592 | for creating a Fossil service on Windows systems. |
| 593 | * Added "versionable settings" where settings that affect |
| 594 | the local tree can be stored in versioned files in the |
| 595 | .fossil-settings directory. |
| 596 | * Background colors for branches are chosen automatically if no |
| 597 | color is specified by the user. |
| 598 | * The status, changes and extras commands now show |
| 599 | pathnames relative to the current working directory, |
| 600 | unless overridden by command line options or the |
| 601 | "relative-paths" setting.<br><b>WARNING:</b> This |
| @@ -606,11 +606,11 @@ | |
| 606 | * Added support for client-side SSL certificates with "ssl-identity" |
| 607 | setting and --ssl-identity option. |
| 608 | * Added "ssl-ca-location" setting to specify trusted root |
| 609 | SSL certificates. |
| 610 | * Added the --case-sensitive BOOLEAN command-line option to many commands. |
| 611 | Default to true for Unix and false for Windows. |
| 612 | * Added the "Color-Test" submenu button on the branch list web page. |
| 613 | * Compatibility improvements to the git-export feature. |
| 614 | * Performance improvements on SHA1 checksums |
| 615 | * Update to the latest SQLite version 3.7.8 alpha. |
| 616 | * Fix the tarball generator to work with very log pathnames |
| 617 |
+9
-9
| --- www/checkin_names.wiki | ||
| +++ www/checkin_names.wiki | ||
| @@ -43,11 +43,11 @@ | ||
| 43 | 43 | Fossil provides a variety of ways to specify a check-in. This |
| 44 | 44 | document describes the various methods. |
| 45 | 45 | |
| 46 | 46 | <h2>Canonical Check-in Name</h2> |
| 47 | 47 | |
| 48 | -The canonical name of a checkin is the SHA1 hash of its | |
| 48 | +The canonical name of a check-in is the SHA1 hash of its | |
| 49 | 49 | [./fileformat.wiki#manifest | manifest] expressed as a 40-character |
| 50 | 50 | lowercase hexadecimal number. For example: |
| 51 | 51 | |
| 52 | 52 | <blockquote><pre> |
| 53 | 53 | fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9 |
| @@ -117,24 +117,24 @@ | ||
| 117 | 117 | tagged with "deed2" not to the |
| 118 | 118 | check-in whose canonical name begins with "deed2". |
| 119 | 119 | |
| 120 | 120 | <h2>Whole Branches</h2> |
| 121 | 121 | |
| 122 | -Usually whan a branch name is specified, it means the latest checkin on | |
| 122 | +Usually when a branch name is specified, it means the latest check-in on | |
| 123 | 123 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 124 | -on the argument means the earliest connected checkin on the branch. This | |
| 124 | +on the argument means the earliest connected check-in on the branch. This | |
| 125 | 125 | seems confusing when being explained here, but it works out to be intuitive |
| 126 | 126 | in practice. |
| 127 | 127 | |
| 128 | -For example, the command "fossil purge XYZ" means to purge the checkin XYZ | |
| 129 | -and all of its descendents. But when XYZ is in the form of a branch name, one | |
| 130 | -generally wants to purge the entire branch, not just the last checkin on the | |
| 128 | +For example, the command "fossil purge XYZ" means to purge the check-in XYZ | |
| 129 | +and all of its descendants. But when XYZ is in the form of a branch name, one | |
| 130 | +generally wants to purge the entire branch, not just the last check-in on the | |
| 131 | 131 | branch. And so for this reason, commands like purge will interpret a branch |
| 132 | -name to be the first checkin of the branch rather than the last. If there | |
| 132 | +name to be the first check-in of the branch rather than the last. If there | |
| 133 | 133 | are two or more branches with the same name, then these commands will select |
| 134 | -the first check-in of the branch that has the most recent checkin. What | |
| 135 | -happens is that Fossil searches for the most recent checkin with the given | |
| 134 | +the first check-in of the branch that has the most recent check-in. What | |
| 135 | +happens is that Fossil searches for the most recent check-in with the given | |
| 136 | 136 | tag, just as it always does. But if that tag is a branch name, it then walks |
| 137 | 137 | back down the branch looking for the first check-in of that branch. |
| 138 | 138 | |
| 139 | 139 | Again, this behavior only occurs on a few commands where it make sense. |
| 140 | 140 | |
| 141 | 141 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -43,11 +43,11 @@ | |
| 43 | Fossil provides a variety of ways to specify a check-in. This |
| 44 | document describes the various methods. |
| 45 | |
| 46 | <h2>Canonical Check-in Name</h2> |
| 47 | |
| 48 | The canonical name of a checkin is the SHA1 hash of its |
| 49 | [./fileformat.wiki#manifest | manifest] expressed as a 40-character |
| 50 | lowercase hexadecimal number. For example: |
| 51 | |
| 52 | <blockquote><pre> |
| 53 | fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9 |
| @@ -117,24 +117,24 @@ | |
| 117 | tagged with "deed2" not to the |
| 118 | check-in whose canonical name begins with "deed2". |
| 119 | |
| 120 | <h2>Whole Branches</h2> |
| 121 | |
| 122 | Usually whan a branch name is specified, it means the latest checkin on |
| 123 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 124 | on the argument means the earliest connected checkin on the branch. This |
| 125 | seems confusing when being explained here, but it works out to be intuitive |
| 126 | in practice. |
| 127 | |
| 128 | For example, the command "fossil purge XYZ" means to purge the checkin XYZ |
| 129 | and all of its descendents. But when XYZ is in the form of a branch name, one |
| 130 | generally wants to purge the entire branch, not just the last checkin on the |
| 131 | branch. And so for this reason, commands like purge will interpret a branch |
| 132 | name to be the first checkin of the branch rather than the last. If there |
| 133 | are two or more branches with the same name, then these commands will select |
| 134 | the first check-in of the branch that has the most recent checkin. What |
| 135 | happens is that Fossil searches for the most recent checkin with the given |
| 136 | tag, just as it always does. But if that tag is a branch name, it then walks |
| 137 | back down the branch looking for the first check-in of that branch. |
| 138 | |
| 139 | Again, this behavior only occurs on a few commands where it make sense. |
| 140 | |
| 141 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -43,11 +43,11 @@ | |
| 43 | Fossil provides a variety of ways to specify a check-in. This |
| 44 | document describes the various methods. |
| 45 | |
| 46 | <h2>Canonical Check-in Name</h2> |
| 47 | |
| 48 | The canonical name of a check-in is the SHA1 hash of its |
| 49 | [./fileformat.wiki#manifest | manifest] expressed as a 40-character |
| 50 | lowercase hexadecimal number. For example: |
| 51 | |
| 52 | <blockquote><pre> |
| 53 | fossil info e5a734a19a9826973e1d073b49dc2a16aa2308f9 |
| @@ -117,24 +117,24 @@ | |
| 117 | tagged with "deed2" not to the |
| 118 | check-in whose canonical name begins with "deed2". |
| 119 | |
| 120 | <h2>Whole Branches</h2> |
| 121 | |
| 122 | Usually when a branch name is specified, it means the latest check-in on |
| 123 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 124 | on the argument means the earliest connected check-in on the branch. This |
| 125 | seems confusing when being explained here, but it works out to be intuitive |
| 126 | in practice. |
| 127 | |
| 128 | For example, the command "fossil purge XYZ" means to purge the check-in XYZ |
| 129 | and all of its descendants. But when XYZ is in the form of a branch name, one |
| 130 | generally wants to purge the entire branch, not just the last check-in on the |
| 131 | branch. And so for this reason, commands like purge will interpret a branch |
| 132 | name to be the first check-in of the branch rather than the last. If there |
| 133 | are two or more branches with the same name, then these commands will select |
| 134 | the first check-in of the branch that has the most recent check-in. What |
| 135 | happens is that Fossil searches for the most recent check-in with the given |
| 136 | tag, just as it always does. But if that tag is a branch name, it then walks |
| 137 | back down the branch looking for the first check-in of that branch. |
| 138 | |
| 139 | Again, this behavior only occurs on a few commands where it make sense. |
| 140 | |
| 141 |
+1
-1
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -178,11 +178,11 @@ | ||
| 178 | 178 | </ul> |
| 179 | 179 | |
| 180 | 180 | <h2>3.0 Fossil - The Program</h2> |
| 181 | 181 | |
| 182 | 182 | Fossil is software. The implementation of fossil is in the form |
| 183 | -of a single executable named "fossil" (or "fossil.exe" on windows). | |
| 183 | +of a single executable named "fossil" (or "fossil.exe" on Windows). | |
| 184 | 184 | To install fossil on your system, |
| 185 | 185 | all you have to do is obtain a copy of this one executable file (either |
| 186 | 186 | by downloading a |
| 187 | 187 | <a href="http://www.fossil-scm.org/download.html">pre-compiled version</a> |
| 188 | 188 | or [./build.wiki | compiling it yourself]) and then |
| 189 | 189 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -178,11 +178,11 @@ | |
| 178 | </ul> |
| 179 | |
| 180 | <h2>3.0 Fossil - The Program</h2> |
| 181 | |
| 182 | Fossil is software. The implementation of fossil is in the form |
| 183 | of a single executable named "fossil" (or "fossil.exe" on windows). |
| 184 | To install fossil on your system, |
| 185 | all you have to do is obtain a copy of this one executable file (either |
| 186 | by downloading a |
| 187 | <a href="http://www.fossil-scm.org/download.html">pre-compiled version</a> |
| 188 | or [./build.wiki | compiling it yourself]) and then |
| 189 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -178,11 +178,11 @@ | |
| 178 | </ul> |
| 179 | |
| 180 | <h2>3.0 Fossil - The Program</h2> |
| 181 | |
| 182 | Fossil is software. The implementation of fossil is in the form |
| 183 | of a single executable named "fossil" (or "fossil.exe" on Windows). |
| 184 | To install fossil on your system, |
| 185 | all you have to do is obtain a copy of this one executable file (either |
| 186 | by downloading a |
| 187 | <a href="http://www.fossil-scm.org/download.html">pre-compiled version</a> |
| 188 | or [./build.wiki | compiling it yourself]) and then |
| 189 |
+2
-2
| --- www/contribute.wiki | ||
| +++ www/contribute.wiki | ||
| @@ -15,11 +15,11 @@ | ||
| 15 | 15 | and other lawyer-rich organizations require this as a precondition to using |
| 16 | 16 | Fossil. |
| 17 | 17 | |
| 18 | 18 | If you do not wish to submit a Contributor Agreement, we would still |
| 19 | 19 | welcome your suggestions and example code, but we will not use your code |
| 20 | -directly - we will be forced to reimplement your changes from scratch which | |
| 20 | +directly - we will be forced to re-implement your changes from scratch which | |
| 21 | 21 | might take longer. |
| 22 | 22 | |
| 23 | 23 | <h2>2.0 Submitting Patches</h2> |
| 24 | 24 | |
| 25 | 25 | Suggested changes or bug fixes can be submitted by creating a patch |
| @@ -51,11 +51,11 @@ | ||
| 51 | 51 | |
| 52 | 52 | Contributors are asked to make all non-trivial changes on a branch. The |
| 53 | 53 | Fossil Architect (Richard Hipp) will merge changes onto the trunk.</p> |
| 54 | 54 | |
| 55 | 55 | Contributors are required to following the |
| 56 | -[./checkin.wiki | pre-checkin checklist] prior to every checkin to | |
| 56 | +[./checkin.wiki | pre-checkin checklist] prior to every check-in to | |
| 57 | 57 | the Fossil self-hosting repository. This checklist is short and succinct |
| 58 | 58 | and should only require a few seconds to follow. Contributors |
| 59 | 59 | should print out a copy of the pre-checkin checklist and keep |
| 60 | 60 | it on a notecard beside their workstations, for quick reference. |
| 61 | 61 | |
| 62 | 62 |
| --- www/contribute.wiki | |
| +++ www/contribute.wiki | |
| @@ -15,11 +15,11 @@ | |
| 15 | and other lawyer-rich organizations require this as a precondition to using |
| 16 | Fossil. |
| 17 | |
| 18 | If you do not wish to submit a Contributor Agreement, we would still |
| 19 | welcome your suggestions and example code, but we will not use your code |
| 20 | directly - we will be forced to reimplement your changes from scratch which |
| 21 | might take longer. |
| 22 | |
| 23 | <h2>2.0 Submitting Patches</h2> |
| 24 | |
| 25 | Suggested changes or bug fixes can be submitted by creating a patch |
| @@ -51,11 +51,11 @@ | |
| 51 | |
| 52 | Contributors are asked to make all non-trivial changes on a branch. The |
| 53 | Fossil Architect (Richard Hipp) will merge changes onto the trunk.</p> |
| 54 | |
| 55 | Contributors are required to following the |
| 56 | [./checkin.wiki | pre-checkin checklist] prior to every checkin to |
| 57 | the Fossil self-hosting repository. This checklist is short and succinct |
| 58 | and should only require a few seconds to follow. Contributors |
| 59 | should print out a copy of the pre-checkin checklist and keep |
| 60 | it on a notecard beside their workstations, for quick reference. |
| 61 | |
| 62 |
| --- www/contribute.wiki | |
| +++ www/contribute.wiki | |
| @@ -15,11 +15,11 @@ | |
| 15 | and other lawyer-rich organizations require this as a precondition to using |
| 16 | Fossil. |
| 17 | |
| 18 | If you do not wish to submit a Contributor Agreement, we would still |
| 19 | welcome your suggestions and example code, but we will not use your code |
| 20 | directly - we will be forced to re-implement your changes from scratch which |
| 21 | might take longer. |
| 22 | |
| 23 | <h2>2.0 Submitting Patches</h2> |
| 24 | |
| 25 | Suggested changes or bug fixes can be submitted by creating a patch |
| @@ -51,11 +51,11 @@ | |
| 51 | |
| 52 | Contributors are asked to make all non-trivial changes on a branch. The |
| 53 | Fossil Architect (Richard Hipp) will merge changes onto the trunk.</p> |
| 54 | |
| 55 | Contributors are required to following the |
| 56 | [./checkin.wiki | pre-checkin checklist] prior to every check-in to |
| 57 | the Fossil self-hosting repository. This checklist is short and succinct |
| 58 | and should only require a few seconds to follow. Contributors |
| 59 | should print out a copy of the pre-checkin checklist and keep |
| 60 | it on a notecard beside their workstations, for quick reference. |
| 61 | |
| 62 |
+2
-2
| --- www/copyright-release.html | ||
| +++ www/copyright-release.html | ||
| @@ -3,11 +3,11 @@ | ||
| 3 | 3 | </h1> |
| 4 | 4 | |
| 5 | 5 | <p> |
| 6 | 6 | This agreement applies to your contribution of material to the |
| 7 | 7 | Fossil Software Configuration Management System ("Fossil") that is |
| 8 | -mananged by Hipp, Wyrick & Company, Inc. ("Hwaci") and | |
| 8 | +managed by Hipp, Wyrick & Company, Inc. ("Hwaci") and | |
| 9 | 9 | sets out the intellectual property rights you grant to Hwaci in the |
| 10 | 10 | contributed material. |
| 11 | 11 | The terms "contribution" and "contributed material" mean any source code, |
| 12 | 12 | object code, patch, tool, sample, graphic, specification, manual, |
| 13 | 13 | documentation, or any other material posted, submitted, or uploaded by |
| @@ -66,11 +66,11 @@ | ||
| 66 | 66 | grant the rights set out in this agreement. |
| 67 | 67 | <li> Your contribution does not, to the best of your knowledge and belief, |
| 68 | 68 | violate any third party's copyrights, trademarks, patents, |
| 69 | 69 | or other intellectual property rights. |
| 70 | 70 | <li> You are authorized to sign this agreement on behalf of your |
| 71 | - company (if appliable). | |
| 71 | + company (if applicable). | |
| 72 | 72 | </ul> |
| 73 | 73 | </ol> |
| 74 | 74 | |
| 75 | 75 | <p>By filling in the following information and signing your name, |
| 76 | 76 | you agree to be bound by all of the terms |
| 77 | 77 |
| --- www/copyright-release.html | |
| +++ www/copyright-release.html | |
| @@ -3,11 +3,11 @@ | |
| 3 | </h1> |
| 4 | |
| 5 | <p> |
| 6 | This agreement applies to your contribution of material to the |
| 7 | Fossil Software Configuration Management System ("Fossil") that is |
| 8 | mananged by Hipp, Wyrick & Company, Inc. ("Hwaci") and |
| 9 | sets out the intellectual property rights you grant to Hwaci in the |
| 10 | contributed material. |
| 11 | The terms "contribution" and "contributed material" mean any source code, |
| 12 | object code, patch, tool, sample, graphic, specification, manual, |
| 13 | documentation, or any other material posted, submitted, or uploaded by |
| @@ -66,11 +66,11 @@ | |
| 66 | grant the rights set out in this agreement. |
| 67 | <li> Your contribution does not, to the best of your knowledge and belief, |
| 68 | violate any third party's copyrights, trademarks, patents, |
| 69 | or other intellectual property rights. |
| 70 | <li> You are authorized to sign this agreement on behalf of your |
| 71 | company (if appliable). |
| 72 | </ul> |
| 73 | </ol> |
| 74 | |
| 75 | <p>By filling in the following information and signing your name, |
| 76 | you agree to be bound by all of the terms |
| 77 |
| --- www/copyright-release.html | |
| +++ www/copyright-release.html | |
| @@ -3,11 +3,11 @@ | |
| 3 | </h1> |
| 4 | |
| 5 | <p> |
| 6 | This agreement applies to your contribution of material to the |
| 7 | Fossil Software Configuration Management System ("Fossil") that is |
| 8 | managed by Hipp, Wyrick & Company, Inc. ("Hwaci") and |
| 9 | sets out the intellectual property rights you grant to Hwaci in the |
| 10 | contributed material. |
| 11 | The terms "contribution" and "contributed material" mean any source code, |
| 12 | object code, patch, tool, sample, graphic, specification, manual, |
| 13 | documentation, or any other material posted, submitted, or uploaded by |
| @@ -66,11 +66,11 @@ | |
| 66 | grant the rights set out in this agreement. |
| 67 | <li> Your contribution does not, to the best of your knowledge and belief, |
| 68 | violate any third party's copyrights, trademarks, patents, |
| 69 | or other intellectual property rights. |
| 70 | <li> You are authorized to sign this agreement on behalf of your |
| 71 | company (if applicable). |
| 72 | </ul> |
| 73 | </ol> |
| 74 | |
| 75 | <p>By filling in the following information and signing your name, |
| 76 | you agree to be bound by all of the terms |
| 77 |
+1
-1
| --- www/delta_format.wiki | ||
| +++ www/delta_format.wiki | ||
| @@ -155,11 +155,11 @@ | ||
| 155 | 155 | <tr><td> </td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr> |
| 156 | 156 | <tr><td> </td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr> |
| 157 | 157 | <tr><td> </td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr> |
| 158 | 158 | <tr><td> </td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr> |
| 159 | 159 | <tr><td> </td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr> |
| 160 | -<tr><td>Trailer</td><td>2zMM3E </td><td>Ckecksum</td><td> -1101438770 </td></tr> | |
| 160 | +<tr><td>Trailer</td><td>2zMM3E </td><td>Checksum</td><td> -1101438770 </td></tr> | |
| 161 | 161 | </table> |
| 162 | 162 | |
| 163 | 163 | <p>The unified diff behind the above delta is</p> |
| 164 | 164 | |
| 165 | 165 | <table border=1><tr><td><pre> |
| 166 | 166 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -155,11 +155,11 @@ | |
| 155 | <tr><td> </td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr> |
| 156 | <tr><td> </td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr> |
| 157 | <tr><td> </td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr> |
| 158 | <tr><td> </td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr> |
| 159 | <tr><td> </td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr> |
| 160 | <tr><td>Trailer</td><td>2zMM3E </td><td>Ckecksum</td><td> -1101438770 </td></tr> |
| 161 | </table> |
| 162 | |
| 163 | <p>The unified diff behind the above delta is</p> |
| 164 | |
| 165 | <table border=1><tr><td><pre> |
| 166 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -155,11 +155,11 @@ | |
| 155 | <tr><td> </td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr> |
| 156 | <tr><td> </td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr> |
| 157 | <tr><td> </td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr> |
| 158 | <tr><td> </td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr> |
| 159 | <tr><td> </td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr> |
| 160 | <tr><td>Trailer</td><td>2zMM3E </td><td>Checksum</td><td> -1101438770 </td></tr> |
| 161 | </table> |
| 162 | |
| 163 | <p>The unified diff behind the above delta is</p> |
| 164 | |
| 165 | <table border=1><tr><td><pre> |
| 166 |
+2
-2
| --- www/faq.tcl | ||
| +++ www/faq.tcl | ||
| @@ -84,11 +84,11 @@ | ||
| 84 | 84 | The CHECK-IN in the previous line can be any |
| 85 | 85 | [./checkin_names.wiki | valid check-in name format]. |
| 86 | 86 | |
| 87 | 87 | You can also add (and remove) tags from a check-in using the |
| 88 | 88 | [./webui.wiki | web interface]. First locate the check-in that you |
| 89 | - what to tag on the tmline, then click on the link to go the detailed | |
| 89 | + what to tag on the timeline, then click on the link to go the detailed | |
| 90 | 90 | information page for that check-in. Then find the "<b>edit</b>" |
| 91 | 91 | link (near the "Commands:" label) and click on that. There are |
| 92 | 92 | controls on the edit page that allow new tags to be added and existing |
| 93 | 93 | tags to be removed. |
| 94 | 94 | } |
| @@ -98,11 +98,11 @@ | ||
| 98 | 98 | main repository. |
| 99 | 99 | } { |
| 100 | 100 | Use the <b>--private</b> command-line option on the |
| 101 | 101 | <b>commit</b> command. The result will be a check-in which exists on |
| 102 | 102 | your local repository only and is never pushed to other repositories. |
| 103 | - All descendents of a private check-in are also private. | |
| 103 | + All descendants of a private check-in are also private. | |
| 104 | 104 | |
| 105 | 105 | Unless you specify something different using the <b>--branch</b> and/or |
| 106 | 106 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 107 | 107 | named "private" with an orange background color. |
| 108 | 108 | |
| 109 | 109 |
| --- www/faq.tcl | |
| +++ www/faq.tcl | |
| @@ -84,11 +84,11 @@ | |
| 84 | The CHECK-IN in the previous line can be any |
| 85 | [./checkin_names.wiki | valid check-in name format]. |
| 86 | |
| 87 | You can also add (and remove) tags from a check-in using the |
| 88 | [./webui.wiki | web interface]. First locate the check-in that you |
| 89 | what to tag on the tmline, then click on the link to go the detailed |
| 90 | information page for that check-in. Then find the "<b>edit</b>" |
| 91 | link (near the "Commands:" label) and click on that. There are |
| 92 | controls on the edit page that allow new tags to be added and existing |
| 93 | tags to be removed. |
| 94 | } |
| @@ -98,11 +98,11 @@ | |
| 98 | main repository. |
| 99 | } { |
| 100 | Use the <b>--private</b> command-line option on the |
| 101 | <b>commit</b> command. The result will be a check-in which exists on |
| 102 | your local repository only and is never pushed to other repositories. |
| 103 | All descendents of a private check-in are also private. |
| 104 | |
| 105 | Unless you specify something different using the <b>--branch</b> and/or |
| 106 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 107 | named "private" with an orange background color. |
| 108 | |
| 109 |
| --- www/faq.tcl | |
| +++ www/faq.tcl | |
| @@ -84,11 +84,11 @@ | |
| 84 | The CHECK-IN in the previous line can be any |
| 85 | [./checkin_names.wiki | valid check-in name format]. |
| 86 | |
| 87 | You can also add (and remove) tags from a check-in using the |
| 88 | [./webui.wiki | web interface]. First locate the check-in that you |
| 89 | what to tag on the timeline, then click on the link to go the detailed |
| 90 | information page for that check-in. Then find the "<b>edit</b>" |
| 91 | link (near the "Commands:" label) and click on that. There are |
| 92 | controls on the edit page that allow new tags to be added and existing |
| 93 | tags to be removed. |
| 94 | } |
| @@ -98,11 +98,11 @@ | |
| 98 | main repository. |
| 99 | } { |
| 100 | Use the <b>--private</b> command-line option on the |
| 101 | <b>commit</b> command. The result will be a check-in which exists on |
| 102 | your local repository only and is never pushed to other repositories. |
| 103 | All descendants of a private check-in are also private. |
| 104 | |
| 105 | Unless you specify something different using the <b>--branch</b> and/or |
| 106 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 107 | named "private" with an orange background color. |
| 108 | |
| 109 |
+2
-2
| --- www/faq.wiki | ||
| +++ www/faq.wiki | ||
| @@ -87,11 +87,11 @@ | ||
| 87 | 87 | The CHECK-IN in the previous line can be any |
| 88 | 88 | [./checkin_names.wiki | valid check-in name format]. |
| 89 | 89 | |
| 90 | 90 | You can also add (and remove) tags from a check-in using the |
| 91 | 91 | [./webui.wiki | web interface]. First locate the check-in that you |
| 92 | -what to tag on the tmline, then click on the link to go the detailed | |
| 92 | +what to tag on the timeline, then click on the link to go the detailed | |
| 93 | 93 | information page for that check-in. Then find the "<b>edit</b>" |
| 94 | 94 | link (near the "Commands:" label) and click on that. There are |
| 95 | 95 | controls on the edit page that allow new tags to be added and existing |
| 96 | 96 | tags to be removed.</blockquote></li> |
| 97 | 97 | |
| @@ -100,11 +100,11 @@ | ||
| 100 | 100 | main repository.</b></p> |
| 101 | 101 | |
| 102 | 102 | <blockquote>Use the <b>--private</b> command-line option on the |
| 103 | 103 | <b>commit</b> command. The result will be a check-in which exists on |
| 104 | 104 | your local repository only and is never pushed to other repositories. |
| 105 | -All descendents of a private check-in are also private. | |
| 105 | +All descendants of a private check-in are also private. | |
| 106 | 106 | |
| 107 | 107 | Unless you specify something different using the <b>--branch</b> and/or |
| 108 | 108 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 109 | 109 | named "private" with an orange background color. |
| 110 | 110 | |
| 111 | 111 |
| --- www/faq.wiki | |
| +++ www/faq.wiki | |
| @@ -87,11 +87,11 @@ | |
| 87 | The CHECK-IN in the previous line can be any |
| 88 | [./checkin_names.wiki | valid check-in name format]. |
| 89 | |
| 90 | You can also add (and remove) tags from a check-in using the |
| 91 | [./webui.wiki | web interface]. First locate the check-in that you |
| 92 | what to tag on the tmline, then click on the link to go the detailed |
| 93 | information page for that check-in. Then find the "<b>edit</b>" |
| 94 | link (near the "Commands:" label) and click on that. There are |
| 95 | controls on the edit page that allow new tags to be added and existing |
| 96 | tags to be removed.</blockquote></li> |
| 97 | |
| @@ -100,11 +100,11 @@ | |
| 100 | main repository.</b></p> |
| 101 | |
| 102 | <blockquote>Use the <b>--private</b> command-line option on the |
| 103 | <b>commit</b> command. The result will be a check-in which exists on |
| 104 | your local repository only and is never pushed to other repositories. |
| 105 | All descendents of a private check-in are also private. |
| 106 | |
| 107 | Unless you specify something different using the <b>--branch</b> and/or |
| 108 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 109 | named "private" with an orange background color. |
| 110 | |
| 111 |
| --- www/faq.wiki | |
| +++ www/faq.wiki | |
| @@ -87,11 +87,11 @@ | |
| 87 | The CHECK-IN in the previous line can be any |
| 88 | [./checkin_names.wiki | valid check-in name format]. |
| 89 | |
| 90 | You can also add (and remove) tags from a check-in using the |
| 91 | [./webui.wiki | web interface]. First locate the check-in that you |
| 92 | what to tag on the timeline, then click on the link to go the detailed |
| 93 | information page for that check-in. Then find the "<b>edit</b>" |
| 94 | link (near the "Commands:" label) and click on that. There are |
| 95 | controls on the edit page that allow new tags to be added and existing |
| 96 | tags to be removed.</blockquote></li> |
| 97 | |
| @@ -100,11 +100,11 @@ | |
| 100 | main repository.</b></p> |
| 101 | |
| 102 | <blockquote>Use the <b>--private</b> command-line option on the |
| 103 | <b>commit</b> command. The result will be a check-in which exists on |
| 104 | your local repository only and is never pushed to other repositories. |
| 105 | All descendants of a private check-in are also private. |
| 106 | |
| 107 | Unless you specify something different using the <b>--branch</b> and/or |
| 108 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 109 | named "private" with an orange background color. |
| 110 | |
| 111 |
+3
-3
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -113,11 +113,11 @@ | ||
| 113 | 113 | A manifest may optionally have a single B-card. The B-card specifies |
| 114 | 114 | another manifest that serves as the "baseline" for this manifest. A |
| 115 | 115 | manifest that has a B-card is called a delta-manifest and a manifest |
| 116 | 116 | that omits the B-card is a baseline-manifest. The other manifest |
| 117 | 117 | identified by the argument of the B-card must be a baseline-manifest. |
| 118 | -A baseline-manifest records the complete contents of a checkin. | |
| 118 | +A baseline-manifest records the complete contents of a check-in. | |
| 119 | 119 | A delta-manifest records only changes from its baseline. |
| 120 | 120 | |
| 121 | 121 | A manifest must have exactly one C-card. The sole argument to |
| 122 | 122 | the C-card is a check-in comment that describes the check-in that |
| 123 | 123 | the manifest defines. The check-in comment is text. The following |
| @@ -313,15 +313,15 @@ | ||
| 313 | 313 | to which the tag is to be applied. The |
| 314 | 314 | first value is the tag name. The first character of the tag |
| 315 | 315 | is either "+", "-", or "*". The "+" means the tag should be added |
| 316 | 316 | to the artifact. The "-" means the tag should be removed. |
| 317 | 317 | The "*" character means the tag should be added to the artifact |
| 318 | -and all direct descendants (but not descendents through a merge) down | |
| 318 | +and all direct descendants (but not descendants through a merge) down | |
| 319 | 319 | to but not including the first descendant that contains a |
| 320 | 320 | more recent "-", "*", or "+" tag with the same name. |
| 321 | 321 | The optional third argument is the value of the tag. A tag |
| 322 | -without a value is a boolean. | |
| 322 | +without a value is a Boolean. | |
| 323 | 323 | |
| 324 | 324 | When two or more tags with the same name are applied to the |
| 325 | 325 | same artifact, the tag with the latest (most recent) date is |
| 326 | 326 | used. |
| 327 | 327 | |
| 328 | 328 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -113,11 +113,11 @@ | |
| 113 | A manifest may optionally have a single B-card. The B-card specifies |
| 114 | another manifest that serves as the "baseline" for this manifest. A |
| 115 | manifest that has a B-card is called a delta-manifest and a manifest |
| 116 | that omits the B-card is a baseline-manifest. The other manifest |
| 117 | identified by the argument of the B-card must be a baseline-manifest. |
| 118 | A baseline-manifest records the complete contents of a checkin. |
| 119 | A delta-manifest records only changes from its baseline. |
| 120 | |
| 121 | A manifest must have exactly one C-card. The sole argument to |
| 122 | the C-card is a check-in comment that describes the check-in that |
| 123 | the manifest defines. The check-in comment is text. The following |
| @@ -313,15 +313,15 @@ | |
| 313 | to which the tag is to be applied. The |
| 314 | first value is the tag name. The first character of the tag |
| 315 | is either "+", "-", or "*". The "+" means the tag should be added |
| 316 | to the artifact. The "-" means the tag should be removed. |
| 317 | The "*" character means the tag should be added to the artifact |
| 318 | and all direct descendants (but not descendents through a merge) down |
| 319 | to but not including the first descendant that contains a |
| 320 | more recent "-", "*", or "+" tag with the same name. |
| 321 | The optional third argument is the value of the tag. A tag |
| 322 | without a value is a boolean. |
| 323 | |
| 324 | When two or more tags with the same name are applied to the |
| 325 | same artifact, the tag with the latest (most recent) date is |
| 326 | used. |
| 327 | |
| 328 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -113,11 +113,11 @@ | |
| 113 | A manifest may optionally have a single B-card. The B-card specifies |
| 114 | another manifest that serves as the "baseline" for this manifest. A |
| 115 | manifest that has a B-card is called a delta-manifest and a manifest |
| 116 | that omits the B-card is a baseline-manifest. The other manifest |
| 117 | identified by the argument of the B-card must be a baseline-manifest. |
| 118 | A baseline-manifest records the complete contents of a check-in. |
| 119 | A delta-manifest records only changes from its baseline. |
| 120 | |
| 121 | A manifest must have exactly one C-card. The sole argument to |
| 122 | the C-card is a check-in comment that describes the check-in that |
| 123 | the manifest defines. The check-in comment is text. The following |
| @@ -313,15 +313,15 @@ | |
| 313 | to which the tag is to be applied. The |
| 314 | first value is the tag name. The first character of the tag |
| 315 | is either "+", "-", or "*". The "+" means the tag should be added |
| 316 | to the artifact. The "-" means the tag should be removed. |
| 317 | The "*" character means the tag should be added to the artifact |
| 318 | and all direct descendants (but not descendants through a merge) down |
| 319 | to but not including the first descendant that contains a |
| 320 | more recent "-", "*", or "+" tag with the same name. |
| 321 | The optional third argument is the value of the tag. A tag |
| 322 | without a value is a Boolean. |
| 323 | |
| 324 | When two or more tags with the same name are applied to the |
| 325 | same artifact, the tag with the latest (most recent) date is |
| 326 | used. |
| 327 | |
| 328 |
+8
-8
| --- www/fiveminutes.wiki | ||
| +++ www/fiveminutes.wiki | ||
| @@ -5,18 +5,18 @@ | ||
| 5 | 5 | </i></b> |
| 6 | 6 | </p><hr> |
| 7 | 7 | |
| 8 | 8 | <h1>Up and running in 5 minutes as a single user</h1> |
| 9 | 9 | <p>This short document explains the main basic Fossil commands for a single |
| 10 | -user, ie. with no additional users, with no need to synchronize with some remote | |
| 10 | +user, i.e. with no additional users, with no need to synchronize with some remote | |
| 11 | 11 | repository, and no need for branching/forking.</p> |
| 12 | 12 | |
| 13 | 13 | <h2>Create a new repository</h2> |
| 14 | 14 | <p>fossil new c:\test.repo</p> |
| 15 | -<p>This will create the new SQLite binary file that holds the repository, ie. | |
| 15 | +<p>This will create the new SQLite binary file that holds the repository, i.e. | |
| 16 | 16 | files, tickets, wiki, etc. It can be located anywhere, although it's considered |
| 17 | -best practise to keep it outside the work directory where you will work on files | |
| 17 | +best practice to keep it outside the work directory where you will work on files | |
| 18 | 18 | after they've been checked out of the repository.</p> |
| 19 | 19 | |
| 20 | 20 | <h2>Open the repository</h2> |
| 21 | 21 | <p>cd c:\temp\test.fossil</p> |
| 22 | 22 | <p>fossil open c:\test.repo</p> |
| @@ -27,28 +27,28 @@ | ||
| 27 | 27 | |
| 28 | 28 | <h2>Add new files</h2> |
| 29 | 29 | <p>fossil add .</p> |
| 30 | 30 | <p>To tell Fossil to add new files to the repository. The files aren't actually |
| 31 | 31 | added until you run "commit". When using ".", it tells Fossil |
| 32 | -to add all the files in the current directory recursively, ie. including all | |
| 32 | +to add all the files in the current directory recursively, i.e. including all | |
| 33 | 33 | the files in all the subdirectories.</p> |
| 34 | 34 | <p>Note: To tell Fossil to ignore some extensions:</p> |
| 35 | 35 | <p>fossil settings ignore-glob "*.o,*.obj,*.exe" --global</p> |
| 36 | 36 | |
| 37 | -<h2>Remove files that haven't been commited yet</h2> | |
| 37 | +<h2>Remove files that haven't been committed yet</h2> | |
| 38 | 38 | <p>fossil delete myfile.c</p> |
| 39 | 39 | <p>This will simply remove the item from the list of files that were previously |
| 40 | 40 | added through "fossil add".</p> |
| 41 | 41 | |
| 42 | 42 | <h2>Check current status</h2> |
| 43 | 43 | <p>fossil changes</p> |
| 44 | -<p>This shows the list of changes that have been done and will be commited the | |
| 44 | +<p>This shows the list of changes that have been done and will be committed the | |
| 45 | 45 | next time you run "fossil commit". It's a useful command to run before |
| 46 | 46 | running "fossil commit" just to check that things are OK before proceeding.</p> |
| 47 | 47 | |
| 48 | 48 | <h2>Commit changes</h2> |
| 49 | -<p>To actually apply the pending changes to the repository, eg. new files marked | |
| 49 | +<p>To actually apply the pending changes to the repository, e.g. new files marked | |
| 50 | 50 | for addition, checked-out files that have been edited and must be checked-in, |
| 51 | 51 | etc.</p> |
| 52 | 52 | |
| 53 | 53 | <p>fossil commit -m "Added stuff"</p> |
| 54 | 54 | |
| @@ -59,11 +59,11 @@ | ||
| 59 | 59 | <p>If you wish to compare the last revision of a file and its checked out version |
| 60 | 60 | in your work directory:</p> |
| 61 | 61 | <p>fossil gdiff myfile.c</p> |
| 62 | 62 | <p>If you wish to compare two different revisions of a file in the repository:</p> |
| 63 | 63 | <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit |
| 64 | -when the file was commited</p> | |
| 64 | +when the file was committed</p> | |
| 65 | 65 | <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p> |
| 66 | 66 | <h2>Cancel changes and go back to previous revision</h2> |
| 67 | 67 | <p>fossil revert myfile.c</p> |
| 68 | 68 | <p>Fossil does not prompt when reverting a file. It simply reminds the user about the |
| 69 | 69 | "undo" command, just in case the revert was a mistake.</p> |
| 70 | 70 |
| --- www/fiveminutes.wiki | |
| +++ www/fiveminutes.wiki | |
| @@ -5,18 +5,18 @@ | |
| 5 | </i></b> |
| 6 | </p><hr> |
| 7 | |
| 8 | <h1>Up and running in 5 minutes as a single user</h1> |
| 9 | <p>This short document explains the main basic Fossil commands for a single |
| 10 | user, ie. with no additional users, with no need to synchronize with some remote |
| 11 | repository, and no need for branching/forking.</p> |
| 12 | |
| 13 | <h2>Create a new repository</h2> |
| 14 | <p>fossil new c:\test.repo</p> |
| 15 | <p>This will create the new SQLite binary file that holds the repository, ie. |
| 16 | files, tickets, wiki, etc. It can be located anywhere, although it's considered |
| 17 | best practise to keep it outside the work directory where you will work on files |
| 18 | after they've been checked out of the repository.</p> |
| 19 | |
| 20 | <h2>Open the repository</h2> |
| 21 | <p>cd c:\temp\test.fossil</p> |
| 22 | <p>fossil open c:\test.repo</p> |
| @@ -27,28 +27,28 @@ | |
| 27 | |
| 28 | <h2>Add new files</h2> |
| 29 | <p>fossil add .</p> |
| 30 | <p>To tell Fossil to add new files to the repository. The files aren't actually |
| 31 | added until you run "commit". When using ".", it tells Fossil |
| 32 | to add all the files in the current directory recursively, ie. including all |
| 33 | the files in all the subdirectories.</p> |
| 34 | <p>Note: To tell Fossil to ignore some extensions:</p> |
| 35 | <p>fossil settings ignore-glob "*.o,*.obj,*.exe" --global</p> |
| 36 | |
| 37 | <h2>Remove files that haven't been commited yet</h2> |
| 38 | <p>fossil delete myfile.c</p> |
| 39 | <p>This will simply remove the item from the list of files that were previously |
| 40 | added through "fossil add".</p> |
| 41 | |
| 42 | <h2>Check current status</h2> |
| 43 | <p>fossil changes</p> |
| 44 | <p>This shows the list of changes that have been done and will be commited the |
| 45 | next time you run "fossil commit". It's a useful command to run before |
| 46 | running "fossil commit" just to check that things are OK before proceeding.</p> |
| 47 | |
| 48 | <h2>Commit changes</h2> |
| 49 | <p>To actually apply the pending changes to the repository, eg. new files marked |
| 50 | for addition, checked-out files that have been edited and must be checked-in, |
| 51 | etc.</p> |
| 52 | |
| 53 | <p>fossil commit -m "Added stuff"</p> |
| 54 | |
| @@ -59,11 +59,11 @@ | |
| 59 | <p>If you wish to compare the last revision of a file and its checked out version |
| 60 | in your work directory:</p> |
| 61 | <p>fossil gdiff myfile.c</p> |
| 62 | <p>If you wish to compare two different revisions of a file in the repository:</p> |
| 63 | <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit |
| 64 | when the file was commited</p> |
| 65 | <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p> |
| 66 | <h2>Cancel changes and go back to previous revision</h2> |
| 67 | <p>fossil revert myfile.c</p> |
| 68 | <p>Fossil does not prompt when reverting a file. It simply reminds the user about the |
| 69 | "undo" command, just in case the revert was a mistake.</p> |
| 70 |
| --- www/fiveminutes.wiki | |
| +++ www/fiveminutes.wiki | |
| @@ -5,18 +5,18 @@ | |
| 5 | </i></b> |
| 6 | </p><hr> |
| 7 | |
| 8 | <h1>Up and running in 5 minutes as a single user</h1> |
| 9 | <p>This short document explains the main basic Fossil commands for a single |
| 10 | user, i.e. with no additional users, with no need to synchronize with some remote |
| 11 | repository, and no need for branching/forking.</p> |
| 12 | |
| 13 | <h2>Create a new repository</h2> |
| 14 | <p>fossil new c:\test.repo</p> |
| 15 | <p>This will create the new SQLite binary file that holds the repository, i.e. |
| 16 | files, tickets, wiki, etc. It can be located anywhere, although it's considered |
| 17 | best practice to keep it outside the work directory where you will work on files |
| 18 | after they've been checked out of the repository.</p> |
| 19 | |
| 20 | <h2>Open the repository</h2> |
| 21 | <p>cd c:\temp\test.fossil</p> |
| 22 | <p>fossil open c:\test.repo</p> |
| @@ -27,28 +27,28 @@ | |
| 27 | |
| 28 | <h2>Add new files</h2> |
| 29 | <p>fossil add .</p> |
| 30 | <p>To tell Fossil to add new files to the repository. The files aren't actually |
| 31 | added until you run "commit". When using ".", it tells Fossil |
| 32 | to add all the files in the current directory recursively, i.e. including all |
| 33 | the files in all the subdirectories.</p> |
| 34 | <p>Note: To tell Fossil to ignore some extensions:</p> |
| 35 | <p>fossil settings ignore-glob "*.o,*.obj,*.exe" --global</p> |
| 36 | |
| 37 | <h2>Remove files that haven't been committed yet</h2> |
| 38 | <p>fossil delete myfile.c</p> |
| 39 | <p>This will simply remove the item from the list of files that were previously |
| 40 | added through "fossil add".</p> |
| 41 | |
| 42 | <h2>Check current status</h2> |
| 43 | <p>fossil changes</p> |
| 44 | <p>This shows the list of changes that have been done and will be committed the |
| 45 | next time you run "fossil commit". It's a useful command to run before |
| 46 | running "fossil commit" just to check that things are OK before proceeding.</p> |
| 47 | |
| 48 | <h2>Commit changes</h2> |
| 49 | <p>To actually apply the pending changes to the repository, e.g. new files marked |
| 50 | for addition, checked-out files that have been edited and must be checked-in, |
| 51 | etc.</p> |
| 52 | |
| 53 | <p>fossil commit -m "Added stuff"</p> |
| 54 | |
| @@ -59,11 +59,11 @@ | |
| 59 | <p>If you wish to compare the last revision of a file and its checked out version |
| 60 | in your work directory:</p> |
| 61 | <p>fossil gdiff myfile.c</p> |
| 62 | <p>If you wish to compare two different revisions of a file in the repository:</p> |
| 63 | <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit |
| 64 | when the file was committed</p> |
| 65 | <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p> |
| 66 | <h2>Cancel changes and go back to previous revision</h2> |
| 67 | <p>fossil revert myfile.c</p> |
| 68 | <p>Fossil does not prompt when reverting a file. It simply reminds the user about the |
| 69 | "undo" command, just in case the revert was a mistake.</p> |
| 70 |
+5
-5
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -56,12 +56,12 @@ | ||
| 56 | 56 | Individual developers have one or more private branches. A hierarchy |
| 57 | 57 | of integrators merge changes from individual developers into collaborative |
| 58 | 58 | branches, until all the changes are merged together at the top-level master |
| 59 | 59 | branch. And all of this can be accomplished without having to have all the |
| 60 | 60 | code in any one repository. Developers or groups of developers can share |
| 61 | -only those branches that they want to share and keep other branchs of the | |
| 62 | -project private. This is analogous to sharding an a distributed database. | |
| 61 | +only those branches that they want to share and keep other branches of the | |
| 62 | +project private. This is analogous to sharding a distributed database. | |
| 63 | 63 | |
| 64 | 64 | Fossil allows private branches, but its default mode is to share everything. |
| 65 | 65 | And so in a Fossil project, all repositories tend to contain all of the |
| 66 | 66 | content at all times. This is analogous to replication in a |
| 67 | 67 | distributed database. |
| @@ -76,11 +76,11 @@ | ||
| 76 | 76 | works in his or her own branch and then merges changes up the hierarchy |
| 77 | 77 | until they reach the master branch. |
| 78 | 78 | |
| 79 | 79 | Fossil is designed for smaller and non-hierarchical teams where all |
| 80 | 80 | developers are operating directly on the master branch, or at most |
| 81 | -a small number of well defined branches. | |
| 81 | +a small number of well-defined branches. | |
| 82 | 82 | The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 83 | 83 | for multiple developers to work on a single branch and maintain |
| 84 | 84 | linear development on that branch and avoid needless forking |
| 85 | 85 | and merging. |
| 86 | 86 | |
| @@ -115,11 +115,11 @@ | ||
| 115 | 115 | So to a first approximation, branches in Git are developer-centric whereas |
| 116 | 116 | branches in Fossil are feature-centric. |
| 117 | 117 | |
| 118 | 118 | The Git approach scales much better for large projects like the Linux |
| 119 | 119 | kernel with thousands of contributors who in many cases don't even know |
| 120 | -each others names. The integrators serve a gatekeeper role to help keep | |
| 120 | +each other's names. The integrators serve a gatekeeper role to help keep | |
| 121 | 121 | undesirable code out of the official Linux source tree. On the other hand, |
| 122 | 122 | not many projects are as big or as loosely organized as the Linux kernel. |
| 123 | 123 | Most projects have a small team of developers who all know each other |
| 124 | 124 | well and trust each other, and who enjoy working together collaboratively |
| 125 | 125 | without the overhead and hierarchy of integrators. |
| @@ -220,11 +220,11 @@ | ||
| 220 | 220 | a complex sequence of check-ins to make their intent easier for others |
| 221 | 221 | to understand. This is important if you view the history of a project |
| 222 | 222 | as part of the documentation for the project. |
| 223 | 223 | |
| 224 | 224 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 225 | -stubornly refuses to change it. | |
| 225 | +stubbornly refuses to change it. | |
| 226 | 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 227 | 227 | can be revised, and check-ins can be moved onto new branches even after |
| 228 | 228 | the check-in has occurred) but the correction is an addition to the repository |
| 229 | 229 | and the original actions are preserved and displayed alongside |
| 230 | 230 | the corrections, thus preserving an historically accurate audit trail. |
| 231 | 231 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -56,12 +56,12 @@ | |
| 56 | Individual developers have one or more private branches. A hierarchy |
| 57 | of integrators merge changes from individual developers into collaborative |
| 58 | branches, until all the changes are merged together at the top-level master |
| 59 | branch. And all of this can be accomplished without having to have all the |
| 60 | code in any one repository. Developers or groups of developers can share |
| 61 | only those branches that they want to share and keep other branchs of the |
| 62 | project private. This is analogous to sharding an a distributed database. |
| 63 | |
| 64 | Fossil allows private branches, but its default mode is to share everything. |
| 65 | And so in a Fossil project, all repositories tend to contain all of the |
| 66 | content at all times. This is analogous to replication in a |
| 67 | distributed database. |
| @@ -76,11 +76,11 @@ | |
| 76 | works in his or her own branch and then merges changes up the hierarchy |
| 77 | until they reach the master branch. |
| 78 | |
| 79 | Fossil is designed for smaller and non-hierarchical teams where all |
| 80 | developers are operating directly on the master branch, or at most |
| 81 | a small number of well defined branches. |
| 82 | The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 83 | for multiple developers to work on a single branch and maintain |
| 84 | linear development on that branch and avoid needless forking |
| 85 | and merging. |
| 86 | |
| @@ -115,11 +115,11 @@ | |
| 115 | So to a first approximation, branches in Git are developer-centric whereas |
| 116 | branches in Fossil are feature-centric. |
| 117 | |
| 118 | The Git approach scales much better for large projects like the Linux |
| 119 | kernel with thousands of contributors who in many cases don't even know |
| 120 | each others names. The integrators serve a gatekeeper role to help keep |
| 121 | undesirable code out of the official Linux source tree. On the other hand, |
| 122 | not many projects are as big or as loosely organized as the Linux kernel. |
| 123 | Most projects have a small team of developers who all know each other |
| 124 | well and trust each other, and who enjoy working together collaboratively |
| 125 | without the overhead and hierarchy of integrators. |
| @@ -220,11 +220,11 @@ | |
| 220 | a complex sequence of check-ins to make their intent easier for others |
| 221 | to understand. This is important if you view the history of a project |
| 222 | as part of the documentation for the project. |
| 223 | |
| 224 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 225 | stubornly refuses to change it. |
| 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 227 | can be revised, and check-ins can be moved onto new branches even after |
| 228 | the check-in has occurred) but the correction is an addition to the repository |
| 229 | and the original actions are preserved and displayed alongside |
| 230 | the corrections, thus preserving an historically accurate audit trail. |
| 231 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -56,12 +56,12 @@ | |
| 56 | Individual developers have one or more private branches. A hierarchy |
| 57 | of integrators merge changes from individual developers into collaborative |
| 58 | branches, until all the changes are merged together at the top-level master |
| 59 | branch. And all of this can be accomplished without having to have all the |
| 60 | code in any one repository. Developers or groups of developers can share |
| 61 | only those branches that they want to share and keep other branches of the |
| 62 | project private. This is analogous to sharding a distributed database. |
| 63 | |
| 64 | Fossil allows private branches, but its default mode is to share everything. |
| 65 | And so in a Fossil project, all repositories tend to contain all of the |
| 66 | content at all times. This is analogous to replication in a |
| 67 | distributed database. |
| @@ -76,11 +76,11 @@ | |
| 76 | works in his or her own branch and then merges changes up the hierarchy |
| 77 | until they reach the master branch. |
| 78 | |
| 79 | Fossil is designed for smaller and non-hierarchical teams where all |
| 80 | developers are operating directly on the master branch, or at most |
| 81 | a small number of well-defined branches. |
| 82 | The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 83 | for multiple developers to work on a single branch and maintain |
| 84 | linear development on that branch and avoid needless forking |
| 85 | and merging. |
| 86 | |
| @@ -115,11 +115,11 @@ | |
| 115 | So to a first approximation, branches in Git are developer-centric whereas |
| 116 | branches in Fossil are feature-centric. |
| 117 | |
| 118 | The Git approach scales much better for large projects like the Linux |
| 119 | kernel with thousands of contributors who in many cases don't even know |
| 120 | each other's names. The integrators serve a gatekeeper role to help keep |
| 121 | undesirable code out of the official Linux source tree. On the other hand, |
| 122 | not many projects are as big or as loosely organized as the Linux kernel. |
| 123 | Most projects have a small team of developers who all know each other |
| 124 | well and trust each other, and who enjoy working together collaboratively |
| 125 | without the overhead and hierarchy of integrators. |
| @@ -220,11 +220,11 @@ | |
| 220 | a complex sequence of check-ins to make their intent easier for others |
| 221 | to understand. This is important if you view the history of a project |
| 222 | as part of the documentation for the project. |
| 223 | |
| 224 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 225 | stubbornly refuses to change it. |
| 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 227 | can be revised, and check-ins can be moved onto new branches even after |
| 228 | the check-in has occurred) but the correction is an addition to the repository |
| 229 | and the original actions are preserved and displayed alongside |
| 230 | the corrections, thus preserving an historically accurate audit trail. |
| 231 |
+1
-1
| --- www/hints.wiki | ||
| +++ www/hints.wiki | ||
| @@ -28,11 +28,11 @@ | ||
| 28 | 28 | URL to get any number of records you desire. To see a complete |
| 29 | 29 | timeline graph, set n to some ridiculously large value like 10000000. |
| 30 | 30 | |
| 31 | 31 | 6. You can manually add a "c=CHECKIN" query parameter to the timeline |
| 32 | 32 | URL to get a snapshot of what was going on about the time of some |
| 33 | - checkin. The "CHECKIN" can be | |
| 33 | + check-in. The "CHECKIN" can be | |
| 34 | 34 | [./checkin_names.wiki | any valid check-in or version name], including |
| 35 | 35 | tags, branch names, and dates. For example, to see what was going |
| 36 | 36 | on in the Fossil repository on 2008-01-01, visit |
| 37 | 37 | [http://www.fossil-scm.org/fossil/timeline?c=2008-01-01]. |
| 38 | 38 | |
| 39 | 39 |
| --- www/hints.wiki | |
| +++ www/hints.wiki | |
| @@ -28,11 +28,11 @@ | |
| 28 | URL to get any number of records you desire. To see a complete |
| 29 | timeline graph, set n to some ridiculously large value like 10000000. |
| 30 | |
| 31 | 6. You can manually add a "c=CHECKIN" query parameter to the timeline |
| 32 | URL to get a snapshot of what was going on about the time of some |
| 33 | checkin. The "CHECKIN" can be |
| 34 | [./checkin_names.wiki | any valid check-in or version name], including |
| 35 | tags, branch names, and dates. For example, to see what was going |
| 36 | on in the Fossil repository on 2008-01-01, visit |
| 37 | [http://www.fossil-scm.org/fossil/timeline?c=2008-01-01]. |
| 38 | |
| 39 |
| --- www/hints.wiki | |
| +++ www/hints.wiki | |
| @@ -28,11 +28,11 @@ | |
| 28 | URL to get any number of records you desire. To see a complete |
| 29 | timeline graph, set n to some ridiculously large value like 10000000. |
| 30 | |
| 31 | 6. You can manually add a "c=CHECKIN" query parameter to the timeline |
| 32 | URL to get a snapshot of what was going on about the time of some |
| 33 | check-in. The "CHECKIN" can be |
| 34 | [./checkin_names.wiki | any valid check-in or version name], including |
| 35 | tags, branch names, and dates. For example, to see what was going |
| 36 | on in the Fossil repository on 2008-01-01, visit |
| 37 | [http://www.fossil-scm.org/fossil/timeline?c=2008-01-01]. |
| 38 | |
| 39 |
+1
-1
| --- www/inout.wiki | ||
| +++ www/inout.wiki | ||
| @@ -47,11 +47,11 @@ | ||
| 47 | 47 | As with the "import" command, the --git option is not required |
| 48 | 48 | since the git-fast-export file format is currently the only VCS interchange |
| 49 | 49 | format that Fossil will generate. However, |
| 50 | 50 | future versions of Fossil might add the ability to generate other |
| 51 | 51 | VCS interchange formats, and so for compatibility, the use of the --git |
| 52 | -option recommented. | |
| 52 | +option recommended. | |
| 53 | 53 | |
| 54 | 54 | An anonymous user sends this comment: |
| 55 | 55 | |
| 56 | 56 | <blockquote> |
| 57 | 57 | The main Fossil branch is called "trunk", while the main git branch is |
| 58 | 58 |
| --- www/inout.wiki | |
| +++ www/inout.wiki | |
| @@ -47,11 +47,11 @@ | |
| 47 | As with the "import" command, the --git option is not required |
| 48 | since the git-fast-export file format is currently the only VCS interchange |
| 49 | format that Fossil will generate. However, |
| 50 | future versions of Fossil might add the ability to generate other |
| 51 | VCS interchange formats, and so for compatibility, the use of the --git |
| 52 | option recommented. |
| 53 | |
| 54 | An anonymous user sends this comment: |
| 55 | |
| 56 | <blockquote> |
| 57 | The main Fossil branch is called "trunk", while the main git branch is |
| 58 |
| --- www/inout.wiki | |
| +++ www/inout.wiki | |
| @@ -47,11 +47,11 @@ | |
| 47 | As with the "import" command, the --git option is not required |
| 48 | since the git-fast-export file format is currently the only VCS interchange |
| 49 | format that Fossil will generate. However, |
| 50 | future versions of Fossil might add the ability to generate other |
| 51 | VCS interchange formats, and so for compatibility, the use of the --git |
| 52 | option recommended. |
| 53 | |
| 54 | An anonymous user sends this comment: |
| 55 | |
| 56 | <blockquote> |
| 57 | The main Fossil branch is called "trunk", while the main git branch is |
| 58 |
+1
-1
| --- www/mkindex.tcl | ||
| +++ www/mkindex.tcl | ||
| @@ -11,11 +11,11 @@ | ||
| 11 | 11 | adding_code.wiki {Hacking Fossil} |
| 12 | 12 | antibot.wiki {Defense against Spiders and Bots} |
| 13 | 13 | bugtheory.wiki {Bug Tracking In Fossil} |
| 14 | 14 | branching.wiki {Branching, Forking, Merging, and Tagging} |
| 15 | 15 | build.wiki {Compiling and Installing Fossil} |
| 16 | - checkin_names.wiki {Checkin And Version Names} | |
| 16 | + checkin_names.wiki {Check-in And Version Names} | |
| 17 | 17 | checkin.wiki {Check-in Checklist} |
| 18 | 18 | changes.wiki {Fossil Changelog} |
| 19 | 19 | copyright-release.html {Contributor License Agreement} |
| 20 | 20 | concepts.wiki {Fossil Core Concepts} |
| 21 | 21 | contribute.wiki {Contributing Code or Documentation To The Fossil Project} |
| 22 | 22 |
| --- www/mkindex.tcl | |
| +++ www/mkindex.tcl | |
| @@ -11,11 +11,11 @@ | |
| 11 | adding_code.wiki {Hacking Fossil} |
| 12 | antibot.wiki {Defense against Spiders and Bots} |
| 13 | bugtheory.wiki {Bug Tracking In Fossil} |
| 14 | branching.wiki {Branching, Forking, Merging, and Tagging} |
| 15 | build.wiki {Compiling and Installing Fossil} |
| 16 | checkin_names.wiki {Checkin And Version Names} |
| 17 | checkin.wiki {Check-in Checklist} |
| 18 | changes.wiki {Fossil Changelog} |
| 19 | copyright-release.html {Contributor License Agreement} |
| 20 | concepts.wiki {Fossil Core Concepts} |
| 21 | contribute.wiki {Contributing Code or Documentation To The Fossil Project} |
| 22 |
| --- www/mkindex.tcl | |
| +++ www/mkindex.tcl | |
| @@ -11,11 +11,11 @@ | |
| 11 | adding_code.wiki {Hacking Fossil} |
| 12 | antibot.wiki {Defense against Spiders and Bots} |
| 13 | bugtheory.wiki {Bug Tracking In Fossil} |
| 14 | branching.wiki {Branching, Forking, Merging, and Tagging} |
| 15 | build.wiki {Compiling and Installing Fossil} |
| 16 | checkin_names.wiki {Check-in And Version Names} |
| 17 | checkin.wiki {Check-in Checklist} |
| 18 | changes.wiki {Fossil Changelog} |
| 19 | copyright-release.html {Contributor License Agreement} |
| 20 | concepts.wiki {Fossil Core Concepts} |
| 21 | contribute.wiki {Contributing Code or Documentation To The Fossil Project} |
| 22 |
+3
-3
| --- www/permutedindex.html | ||
| +++ www/permutedindex.html | ||
| @@ -35,11 +35,11 @@ | ||
| 35 | 35 | <li><a href="branching.wiki">Branching, Forking, Merging, and Tagging</a></li> |
| 36 | 36 | <li><a href="bugtheory.wiki">Bug Tracking In Fossil</a></li> |
| 37 | 37 | <li><a href="makefile.wiki">Build Process — The Fossil</a></li> |
| 38 | 38 | <li><a href="changes.wiki">Changelog — Fossil</a></li> |
| 39 | 39 | <li><a href="checkin.wiki">Check-in Checklist</a></li> |
| 40 | -<li><a href="checkin_names.wiki">Checkin And Version Names</a></li> | |
| 40 | +<li><a href="checkin_names.wiki">Check-in And Version Names</a></li> | |
| 41 | 41 | <li><a href="checkin.wiki">Checklist — Check-in</a></li> |
| 42 | 42 | <li><a href="../test/release-checklist.wiki">Checklist — Pre-Release Testing</a></li> |
| 43 | 43 | <li><a href="foss-cklist.wiki">Checklist For Successful Open-Source Projects</a></li> |
| 44 | 44 | <li><a href="selfcheck.wiki">Checks — Fossil Repository Integrity Self</a></li> |
| 45 | 45 | <li><a href="contribute.wiki">Code or Documentation To The Fossil Project — Contributing</a></li> |
| @@ -118,11 +118,11 @@ | ||
| 118 | 118 | <li><a href="copyright-release.html">License Agreement — Contributor</a></li> |
| 119 | 119 | <li><a href="password.wiki">Management And Authentication — Password</a></li> |
| 120 | 120 | <li><a href="branching.wiki">Merging, and Tagging — Branching, Forking,</a></li> |
| 121 | 121 | <li><a href="fossil-from-msvc.wiki">Microsoft Express 2010 IDE — Integrating Fossil in the</a></li> |
| 122 | 122 | <li><a href="fiveminutes.wiki">Minutes as a Single User — Update and Running in 5</a></li> |
| 123 | -<li><a href="checkin_names.wiki">Names — Checkin And Version</a></li> | |
| 123 | +<li><a href="checkin_names.wiki">Names — Check-in And Version</a></li> | |
| 124 | 124 | <li><a href="adding_code.wiki">New Features To Fossil — Adding</a></li> |
| 125 | 125 | <li><a href="newrepo.wiki">New Fossil Repository — How To Create A</a></li> |
| 126 | 126 | <li><a href="foss-cklist.wiki">Open-Source Projects — Checklist For Successful</a></li> |
| 127 | 127 | <li><a href="pop.wiki">Operations — Principles Of</a></li> |
| 128 | 128 | <li><a href="tech_overview.wiki">Overview Of The Design And Implementation Of Fossil — A Technical</a></li> |
| @@ -185,13 +185,13 @@ | ||
| 185 | 185 | <li><a href="bugtheory.wiki">Tracking In Fossil — Bug</a></li> |
| 186 | 186 | <li><a href="fiveminutes.wiki">Update and Running in 5 Minutes as a Single User</a></li> |
| 187 | 187 | <li><a href="hints.wiki">Usage Hints — Fossil Tips And</a></li> |
| 188 | 188 | <li><a href="fiveminutes.wiki">User — Update and Running in 5 Minutes as a Single</a></li> |
| 189 | 189 | <li><a href="ssl.wiki">Using SSL with Fossil</a></li> |
| 190 | -<li><a href="checkin_names.wiki">Version Names — Checkin And</a></li> | |
| 190 | +<li><a href="checkin_names.wiki">Version Names — Check-in And</a></li> | |
| 191 | 191 | <li><a href="fossil-v-git.wiki">Versus Git — Fossil</a></li> |
| 192 | 192 | <li><a href="webui.wiki">Web Interface — The Fossil</a></li> |
| 193 | 193 | <li><a href="customskin.md">Web Pages — Theming: Customizing The Appearance of</a></li> |
| 194 | 194 | <li><a href="quotes.wiki">What People Are Saying About Fossil, Git, and DVCSes in General — Quotes:</a></li> |
| 195 | 195 | <li><a href="wikitheory.wiki">Wiki In Fossil</a></li> |
| 196 | 196 | <li><a href="ssl.wiki">with Fossil — Using SSL</a></li> |
| 197 | 197 | </ul></div> |
| 198 | 198 |
| --- www/permutedindex.html | |
| +++ www/permutedindex.html | |
| @@ -35,11 +35,11 @@ | |
| 35 | <li><a href="branching.wiki">Branching, Forking, Merging, and Tagging</a></li> |
| 36 | <li><a href="bugtheory.wiki">Bug Tracking In Fossil</a></li> |
| 37 | <li><a href="makefile.wiki">Build Process — The Fossil</a></li> |
| 38 | <li><a href="changes.wiki">Changelog — Fossil</a></li> |
| 39 | <li><a href="checkin.wiki">Check-in Checklist</a></li> |
| 40 | <li><a href="checkin_names.wiki">Checkin And Version Names</a></li> |
| 41 | <li><a href="checkin.wiki">Checklist — Check-in</a></li> |
| 42 | <li><a href="../test/release-checklist.wiki">Checklist — Pre-Release Testing</a></li> |
| 43 | <li><a href="foss-cklist.wiki">Checklist For Successful Open-Source Projects</a></li> |
| 44 | <li><a href="selfcheck.wiki">Checks — Fossil Repository Integrity Self</a></li> |
| 45 | <li><a href="contribute.wiki">Code or Documentation To The Fossil Project — Contributing</a></li> |
| @@ -118,11 +118,11 @@ | |
| 118 | <li><a href="copyright-release.html">License Agreement — Contributor</a></li> |
| 119 | <li><a href="password.wiki">Management And Authentication — Password</a></li> |
| 120 | <li><a href="branching.wiki">Merging, and Tagging — Branching, Forking,</a></li> |
| 121 | <li><a href="fossil-from-msvc.wiki">Microsoft Express 2010 IDE — Integrating Fossil in the</a></li> |
| 122 | <li><a href="fiveminutes.wiki">Minutes as a Single User — Update and Running in 5</a></li> |
| 123 | <li><a href="checkin_names.wiki">Names — Checkin And Version</a></li> |
| 124 | <li><a href="adding_code.wiki">New Features To Fossil — Adding</a></li> |
| 125 | <li><a href="newrepo.wiki">New Fossil Repository — How To Create A</a></li> |
| 126 | <li><a href="foss-cklist.wiki">Open-Source Projects — Checklist For Successful</a></li> |
| 127 | <li><a href="pop.wiki">Operations — Principles Of</a></li> |
| 128 | <li><a href="tech_overview.wiki">Overview Of The Design And Implementation Of Fossil — A Technical</a></li> |
| @@ -185,13 +185,13 @@ | |
| 185 | <li><a href="bugtheory.wiki">Tracking In Fossil — Bug</a></li> |
| 186 | <li><a href="fiveminutes.wiki">Update and Running in 5 Minutes as a Single User</a></li> |
| 187 | <li><a href="hints.wiki">Usage Hints — Fossil Tips And</a></li> |
| 188 | <li><a href="fiveminutes.wiki">User — Update and Running in 5 Minutes as a Single</a></li> |
| 189 | <li><a href="ssl.wiki">Using SSL with Fossil</a></li> |
| 190 | <li><a href="checkin_names.wiki">Version Names — Checkin And</a></li> |
| 191 | <li><a href="fossil-v-git.wiki">Versus Git — Fossil</a></li> |
| 192 | <li><a href="webui.wiki">Web Interface — The Fossil</a></li> |
| 193 | <li><a href="customskin.md">Web Pages — Theming: Customizing The Appearance of</a></li> |
| 194 | <li><a href="quotes.wiki">What People Are Saying About Fossil, Git, and DVCSes in General — Quotes:</a></li> |
| 195 | <li><a href="wikitheory.wiki">Wiki In Fossil</a></li> |
| 196 | <li><a href="ssl.wiki">with Fossil — Using SSL</a></li> |
| 197 | </ul></div> |
| 198 |
| --- www/permutedindex.html | |
| +++ www/permutedindex.html | |
| @@ -35,11 +35,11 @@ | |
| 35 | <li><a href="branching.wiki">Branching, Forking, Merging, and Tagging</a></li> |
| 36 | <li><a href="bugtheory.wiki">Bug Tracking In Fossil</a></li> |
| 37 | <li><a href="makefile.wiki">Build Process — The Fossil</a></li> |
| 38 | <li><a href="changes.wiki">Changelog — Fossil</a></li> |
| 39 | <li><a href="checkin.wiki">Check-in Checklist</a></li> |
| 40 | <li><a href="checkin_names.wiki">Check-in And Version Names</a></li> |
| 41 | <li><a href="checkin.wiki">Checklist — Check-in</a></li> |
| 42 | <li><a href="../test/release-checklist.wiki">Checklist — Pre-Release Testing</a></li> |
| 43 | <li><a href="foss-cklist.wiki">Checklist For Successful Open-Source Projects</a></li> |
| 44 | <li><a href="selfcheck.wiki">Checks — Fossil Repository Integrity Self</a></li> |
| 45 | <li><a href="contribute.wiki">Code or Documentation To The Fossil Project — Contributing</a></li> |
| @@ -118,11 +118,11 @@ | |
| 118 | <li><a href="copyright-release.html">License Agreement — Contributor</a></li> |
| 119 | <li><a href="password.wiki">Management And Authentication — Password</a></li> |
| 120 | <li><a href="branching.wiki">Merging, and Tagging — Branching, Forking,</a></li> |
| 121 | <li><a href="fossil-from-msvc.wiki">Microsoft Express 2010 IDE — Integrating Fossil in the</a></li> |
| 122 | <li><a href="fiveminutes.wiki">Minutes as a Single User — Update and Running in 5</a></li> |
| 123 | <li><a href="checkin_names.wiki">Names — Check-in And Version</a></li> |
| 124 | <li><a href="adding_code.wiki">New Features To Fossil — Adding</a></li> |
| 125 | <li><a href="newrepo.wiki">New Fossil Repository — How To Create A</a></li> |
| 126 | <li><a href="foss-cklist.wiki">Open-Source Projects — Checklist For Successful</a></li> |
| 127 | <li><a href="pop.wiki">Operations — Principles Of</a></li> |
| 128 | <li><a href="tech_overview.wiki">Overview Of The Design And Implementation Of Fossil — A Technical</a></li> |
| @@ -185,13 +185,13 @@ | |
| 185 | <li><a href="bugtheory.wiki">Tracking In Fossil — Bug</a></li> |
| 186 | <li><a href="fiveminutes.wiki">Update and Running in 5 Minutes as a Single User</a></li> |
| 187 | <li><a href="hints.wiki">Usage Hints — Fossil Tips And</a></li> |
| 188 | <li><a href="fiveminutes.wiki">User — Update and Running in 5 Minutes as a Single</a></li> |
| 189 | <li><a href="ssl.wiki">Using SSL with Fossil</a></li> |
| 190 | <li><a href="checkin_names.wiki">Version Names — Check-in And</a></li> |
| 191 | <li><a href="fossil-v-git.wiki">Versus Git — Fossil</a></li> |
| 192 | <li><a href="webui.wiki">Web Interface — The Fossil</a></li> |
| 193 | <li><a href="customskin.md">Web Pages — Theming: Customizing The Appearance of</a></li> |
| 194 | <li><a href="quotes.wiki">What People Are Saying About Fossil, Git, and DVCSes in General — Quotes:</a></li> |
| 195 | <li><a href="wikitheory.wiki">Wiki In Fossil</a></li> |
| 196 | <li><a href="ssl.wiki">with Fossil — Using SSL</a></li> |
| 197 | </ul></div> |
| 198 |
+4
-4
| --- www/private.wiki | ||
| +++ www/private.wiki | ||
| @@ -16,11 +16,11 @@ | ||
| 16 | 16 | |
| 17 | 17 | The --private option causes Fossil to put the check-in in a new branch |
| 18 | 18 | named "private". That branch will not participate in subsequent clone, |
| 19 | 19 | sync, push, or pull operations. The branch will remain on the one local |
| 20 | 20 | repository where it was created. Note that you only use the --private |
| 21 | -option for the first checkin that creates the private branch. | |
| 21 | +option for the first check-in that creates the private branch. | |
| 22 | 22 | Additional checkins into the private branch remain private automatically. |
| 23 | 23 | |
| 24 | 24 | <h2>Publishing Private Changes</h2> |
| 25 | 25 | |
| 26 | 26 | After additional work, one might desire to publish the changes associated |
| @@ -41,15 +41,15 @@ | ||
| 41 | 41 | <h2>Syncing Private Branches</h2> |
| 42 | 42 | |
| 43 | 43 | A private branch normally stays on the one repository where it was |
| 44 | 44 | originally created. But sometimes you want to share private branches |
| 45 | 45 | with another repository. For example, you might be building a cross-platform |
| 46 | -application and have separate repositories on your windows laptop, | |
| 47 | -your linux desktop, and your iMac. You can transfer private branches | |
| 46 | +application and have separate repositories on your Windows laptop, | |
| 47 | +your Linux desktop, and your iMac. You can transfer private branches | |
| 48 | 48 | between these machines by using the --private option on the "sync", |
| 49 | 49 | "push", "pull", and "clone" commands. For example, if you are running |
| 50 | -"fossil server" on your linux box and you want to clone that repository | |
| 50 | +"fossil server" on your Linux box and you want to clone that repository | |
| 51 | 51 | to your Mac, including all private branches, use: |
| 52 | 52 | |
| 53 | 53 | <blockquote><pre> |
| 54 | 54 | fossil clone --private http://[email protected]:8080/ mac-clone.fossil |
| 55 | 55 | </pre></blockquote> |
| 56 | 56 |
| --- www/private.wiki | |
| +++ www/private.wiki | |
| @@ -16,11 +16,11 @@ | |
| 16 | |
| 17 | The --private option causes Fossil to put the check-in in a new branch |
| 18 | named "private". That branch will not participate in subsequent clone, |
| 19 | sync, push, or pull operations. The branch will remain on the one local |
| 20 | repository where it was created. Note that you only use the --private |
| 21 | option for the first checkin that creates the private branch. |
| 22 | Additional checkins into the private branch remain private automatically. |
| 23 | |
| 24 | <h2>Publishing Private Changes</h2> |
| 25 | |
| 26 | After additional work, one might desire to publish the changes associated |
| @@ -41,15 +41,15 @@ | |
| 41 | <h2>Syncing Private Branches</h2> |
| 42 | |
| 43 | A private branch normally stays on the one repository where it was |
| 44 | originally created. But sometimes you want to share private branches |
| 45 | with another repository. For example, you might be building a cross-platform |
| 46 | application and have separate repositories on your windows laptop, |
| 47 | your linux desktop, and your iMac. You can transfer private branches |
| 48 | between these machines by using the --private option on the "sync", |
| 49 | "push", "pull", and "clone" commands. For example, if you are running |
| 50 | "fossil server" on your linux box and you want to clone that repository |
| 51 | to your Mac, including all private branches, use: |
| 52 | |
| 53 | <blockquote><pre> |
| 54 | fossil clone --private http://[email protected]:8080/ mac-clone.fossil |
| 55 | </pre></blockquote> |
| 56 |
| --- www/private.wiki | |
| +++ www/private.wiki | |
| @@ -16,11 +16,11 @@ | |
| 16 | |
| 17 | The --private option causes Fossil to put the check-in in a new branch |
| 18 | named "private". That branch will not participate in subsequent clone, |
| 19 | sync, push, or pull operations. The branch will remain on the one local |
| 20 | repository where it was created. Note that you only use the --private |
| 21 | option for the first check-in that creates the private branch. |
| 22 | Additional checkins into the private branch remain private automatically. |
| 23 | |
| 24 | <h2>Publishing Private Changes</h2> |
| 25 | |
| 26 | After additional work, one might desire to publish the changes associated |
| @@ -41,15 +41,15 @@ | |
| 41 | <h2>Syncing Private Branches</h2> |
| 42 | |
| 43 | A private branch normally stays on the one repository where it was |
| 44 | originally created. But sometimes you want to share private branches |
| 45 | with another repository. For example, you might be building a cross-platform |
| 46 | application and have separate repositories on your Windows laptop, |
| 47 | your Linux desktop, and your iMac. You can transfer private branches |
| 48 | between these machines by using the --private option on the "sync", |
| 49 | "push", "pull", and "clone" commands. For example, if you are running |
| 50 | "fossil server" on your Linux box and you want to clone that repository |
| 51 | to your Mac, including all private branches, use: |
| 52 | |
| 53 | <blockquote><pre> |
| 54 | fossil clone --private http://[email protected]:8080/ mac-clone.fossil |
| 55 | </pre></blockquote> |
| 56 |
+2
-2
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -76,11 +76,11 @@ | ||
| 76 | 76 | |
| 77 | 77 | <p>A Fossil repository is a single disk file. Instead of cloning, |
| 78 | 78 | you can just make a copy of the repository file (for example, using |
| 79 | 79 | "scp"). Note, however, that the repository file contains auxiliary |
| 80 | 80 | information above and beyond the versioned files, including some |
| 81 | - sensitive information such as password hashs and email addresses. If you | |
| 81 | + sensitive information such as password hashes and email addresses. If you | |
| 82 | 82 | want to share Fossil repositories directly, consider running the |
| 83 | 83 | [/help/scrub|fossil scrub] command to remove sensitive information |
| 84 | 84 | before transmitting the file. |
| 85 | 85 | |
| 86 | 86 | <h2>Importing From Another Version Control System</h2> |
| @@ -336,11 +336,11 @@ | ||
| 336 | 336 | <li>[./server.wiki#inetd|inetd/xinetd] |
| 337 | 337 | <li>[./server.wiki#cgi|CGI] |
| 338 | 338 | <li>[./server.wiki#scgi|SCGI] |
| 339 | 339 | </ul> |
| 340 | 340 | |
| 341 | - <p>The the [./selfhost.wiki | self-hosting fossil repositories] use | |
| 341 | + <p>The [./selfhost.wiki | self-hosting fossil repositories] use | |
| 342 | 342 | CGI. |
| 343 | 343 | |
| 344 | 344 | <a name="proxy"></a> |
| 345 | 345 | <h2>HTTP Proxies</h2> |
| 346 | 346 | |
| 347 | 347 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -76,11 +76,11 @@ | |
| 76 | |
| 77 | <p>A Fossil repository is a single disk file. Instead of cloning, |
| 78 | you can just make a copy of the repository file (for example, using |
| 79 | "scp"). Note, however, that the repository file contains auxiliary |
| 80 | information above and beyond the versioned files, including some |
| 81 | sensitive information such as password hashs and email addresses. If you |
| 82 | want to share Fossil repositories directly, consider running the |
| 83 | [/help/scrub|fossil scrub] command to remove sensitive information |
| 84 | before transmitting the file. |
| 85 | |
| 86 | <h2>Importing From Another Version Control System</h2> |
| @@ -336,11 +336,11 @@ | |
| 336 | <li>[./server.wiki#inetd|inetd/xinetd] |
| 337 | <li>[./server.wiki#cgi|CGI] |
| 338 | <li>[./server.wiki#scgi|SCGI] |
| 339 | </ul> |
| 340 | |
| 341 | <p>The the [./selfhost.wiki | self-hosting fossil repositories] use |
| 342 | CGI. |
| 343 | |
| 344 | <a name="proxy"></a> |
| 345 | <h2>HTTP Proxies</h2> |
| 346 | |
| 347 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -76,11 +76,11 @@ | |
| 76 | |
| 77 | <p>A Fossil repository is a single disk file. Instead of cloning, |
| 78 | you can just make a copy of the repository file (for example, using |
| 79 | "scp"). Note, however, that the repository file contains auxiliary |
| 80 | information above and beyond the versioned files, including some |
| 81 | sensitive information such as password hashes and email addresses. If you |
| 82 | want to share Fossil repositories directly, consider running the |
| 83 | [/help/scrub|fossil scrub] command to remove sensitive information |
| 84 | before transmitting the file. |
| 85 | |
| 86 | <h2>Importing From Another Version Control System</h2> |
| @@ -336,11 +336,11 @@ | |
| 336 | <li>[./server.wiki#inetd|inetd/xinetd] |
| 337 | <li>[./server.wiki#cgi|CGI] |
| 338 | <li>[./server.wiki#scgi|SCGI] |
| 339 | </ul> |
| 340 | |
| 341 | <p>The [./selfhost.wiki | self-hosting fossil repositories] use |
| 342 | CGI. |
| 343 | |
| 344 | <a name="proxy"></a> |
| 345 | <h2>HTTP Proxies</h2> |
| 346 | |
| 347 |
+1
-1
| --- www/quotes.wiki | ||
| +++ www/quotes.wiki | ||
| @@ -5,11 +5,11 @@ | ||
| 5 | 5 | by the creator of Fossil, so of course there is selection bias... |
| 6 | 6 | |
| 7 | 7 | <h2>On The Usability Of Git:</h2> |
| 8 | 8 | |
| 9 | 9 | <ol> |
| 10 | -<li>Git approaches the useability of iptables, which is to say, utterly | |
| 10 | +<li>Git approaches the usability of iptables, which is to say, utterly | |
| 11 | 11 | unusable unless you have the manpage tattooed on you arm. |
| 12 | 12 | |
| 13 | 13 | <blockquote> |
| 14 | 14 | <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i> |
| 15 | 15 | </blockquote> |
| 16 | 16 |
| --- www/quotes.wiki | |
| +++ www/quotes.wiki | |
| @@ -5,11 +5,11 @@ | |
| 5 | by the creator of Fossil, so of course there is selection bias... |
| 6 | |
| 7 | <h2>On The Usability Of Git:</h2> |
| 8 | |
| 9 | <ol> |
| 10 | <li>Git approaches the useability of iptables, which is to say, utterly |
| 11 | unusable unless you have the manpage tattooed on you arm. |
| 12 | |
| 13 | <blockquote> |
| 14 | <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i> |
| 15 | </blockquote> |
| 16 |
| --- www/quotes.wiki | |
| +++ www/quotes.wiki | |
| @@ -5,11 +5,11 @@ | |
| 5 | by the creator of Fossil, so of course there is selection bias... |
| 6 | |
| 7 | <h2>On The Usability Of Git:</h2> |
| 8 | |
| 9 | <ol> |
| 10 | <li>Git approaches the usability of iptables, which is to say, utterly |
| 11 | unusable unless you have the manpage tattooed on you arm. |
| 12 | |
| 13 | <blockquote> |
| 14 | <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i> |
| 15 | </blockquote> |
| 16 |
+1
-1
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -69,11 +69,11 @@ | ||
| 69 | 69 | <h2>Checksum Over All Files In A Check-in</h2> |
| 70 | 70 | |
| 71 | 71 | Manifest artifacts that define a check-in have two fields (the |
| 72 | 72 | R-card and Z-card) that record MD5 hashes of the manifest itself |
| 73 | 73 | and of all other files in the manifest. Prior to any check-in |
| 74 | -commit, these checksums are verified to ensure that the checkin | |
| 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 | 78 | Note that these added checks use a different hash (MD5 instead |
| 79 | 79 | of SHA1) in order to avoid common-mode failures in the hash |
| 80 | 80 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -69,11 +69,11 @@ | |
| 69 | <h2>Checksum Over All Files In A Check-in</h2> |
| 70 | |
| 71 | Manifest artifacts that define a check-in have two fields (the |
| 72 | R-card and Z-card) that record MD5 hashes of the manifest itself |
| 73 | and of all other files in the manifest. Prior to any check-in |
| 74 | commit, these checksums are verified to ensure that the checkin |
| 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 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -69,11 +69,11 @@ | |
| 69 | <h2>Checksum Over All Files In A Check-in</h2> |
| 70 | |
| 71 | Manifest artifacts that define a check-in have two fields (the |
| 72 | R-card and Z-card) that record MD5 hashes of the manifest itself |
| 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 |
+4
-4
| --- www/server.wiki | ||
| +++ www/server.wiki | ||
| @@ -99,11 +99,11 @@ | ||
| 99 | 99 | off of the wire. |
| 100 | 100 | </p> |
| 101 | 101 | <p> |
| 102 | 102 | [http://www.stunnel.org/ | Stunnel version 4] is an inetd-like process that |
| 103 | 103 | accepts and decodes SSL-encrypted connections. Fossil can be run directly from |
| 104 | -stunnel in a mannar similar to inetd and xinetd. This can be used to provide | |
| 104 | +stunnel in a manner similar to inetd and xinetd. This can be used to provide | |
| 105 | 105 | a secure link to a Fossil project. The configuration needed to get stunnel4 |
| 106 | 106 | to invoke Fossil is very similar to the inetd and xinetd examples shown above. |
| 107 | 107 | The relevant parts of an stunnel configuration might look something |
| 108 | 108 | like the following: |
| 109 | 109 | <blockquote><pre><nowiki> |
| @@ -111,11 +111,11 @@ | ||
| 111 | 111 | accept = www.ubercool-project.org:443 |
| 112 | 112 | TIMEOUTclose = 0 |
| 113 | 113 | exec = /usr/bin/fossil |
| 114 | 114 | execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https |
| 115 | 115 | </nowiki></pre></blockquote> |
| 116 | -See the stunnel4 documentation for further details bout the /etc/stunnel/stunnel.conf | |
| 116 | +See the stunnel4 documentation for further details about the /etc/stunnel/stunnel.conf | |
| 117 | 117 | configuration file. Note that the [/help/http|fossil http] command should include |
| 118 | 118 | the --https option to let Fossil know to use "https" instead of "http" as the scheme |
| 119 | 119 | on generated hyperlinks. |
| 120 | 120 | <p> |
| 121 | 121 | Using inetd or xinetd or stunnel is a more complex setup |
| @@ -266,11 +266,11 @@ | ||
| 266 | 266 | normally takes less than 10 milliseconds of CPU time to complete. So |
| 267 | 267 | requests can be arriving at a continuous rate of 20 or more per second |
| 268 | 268 | and the CPU can still be mostly idle. |
| 269 | 269 | <p> |
| 270 | 270 | However, there are some Fossil web pages that can consume large |
| 271 | -amounts of CPU time, expecially on repositories with a large number | |
| 271 | +amounts of CPU time, especially on repositories with a large number | |
| 272 | 272 | of files or with long revision histories. High CPU usage pages include |
| 273 | 273 | [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], |
| 274 | 274 | [/help?cmd=/annotate | /annotate] and others. On very large repositories, |
| 275 | 275 | these commands can take 15 seconds or more of CPU time. |
| 276 | 276 | If these kinds of requests arrive too quickly, the load average on the |
| @@ -313,11 +313,11 @@ | ||
| 313 | 313 | </pre></blockquote> |
| 314 | 314 | The second form is especially useful for changing the maximum load average |
| 315 | 315 | simultaneously on a large number of repositories. |
| 316 | 316 | <p> |
| 317 | 317 | Note that this load-average limiting feature is only available on operating |
| 318 | -systems that support the "getloadavg()" API. Most modern unix systems have | |
| 318 | +systems that support the "getloadavg()" API. Most modern Unix systems have | |
| 319 | 319 | this interface, but Windows does not, so the feature will not work on Windows. |
| 320 | 320 | Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg" |
| 321 | 321 | file in the "proc" virtual filesystem. If you are running a Fossil instance |
| 322 | 322 | inside a chroot() jail on Linux, you will need to make the "/proc" file |
| 323 | 323 | system available inside that jail in order for this feature to work. On |
| 324 | 324 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -99,11 +99,11 @@ | |
| 99 | off of the wire. |
| 100 | </p> |
| 101 | <p> |
| 102 | [http://www.stunnel.org/ | Stunnel version 4] is an inetd-like process that |
| 103 | accepts and decodes SSL-encrypted connections. Fossil can be run directly from |
| 104 | stunnel in a mannar similar to inetd and xinetd. This can be used to provide |
| 105 | a secure link to a Fossil project. The configuration needed to get stunnel4 |
| 106 | to invoke Fossil is very similar to the inetd and xinetd examples shown above. |
| 107 | The relevant parts of an stunnel configuration might look something |
| 108 | like the following: |
| 109 | <blockquote><pre><nowiki> |
| @@ -111,11 +111,11 @@ | |
| 111 | accept = www.ubercool-project.org:443 |
| 112 | TIMEOUTclose = 0 |
| 113 | exec = /usr/bin/fossil |
| 114 | execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https |
| 115 | </nowiki></pre></blockquote> |
| 116 | See the stunnel4 documentation for further details bout the /etc/stunnel/stunnel.conf |
| 117 | configuration file. Note that the [/help/http|fossil http] command should include |
| 118 | the --https option to let Fossil know to use "https" instead of "http" as the scheme |
| 119 | on generated hyperlinks. |
| 120 | <p> |
| 121 | Using inetd or xinetd or stunnel is a more complex setup |
| @@ -266,11 +266,11 @@ | |
| 266 | normally takes less than 10 milliseconds of CPU time to complete. So |
| 267 | requests can be arriving at a continuous rate of 20 or more per second |
| 268 | and the CPU can still be mostly idle. |
| 269 | <p> |
| 270 | However, there are some Fossil web pages that can consume large |
| 271 | amounts of CPU time, expecially on repositories with a large number |
| 272 | of files or with long revision histories. High CPU usage pages include |
| 273 | [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], |
| 274 | [/help?cmd=/annotate | /annotate] and others. On very large repositories, |
| 275 | these commands can take 15 seconds or more of CPU time. |
| 276 | If these kinds of requests arrive too quickly, the load average on the |
| @@ -313,11 +313,11 @@ | |
| 313 | </pre></blockquote> |
| 314 | The second form is especially useful for changing the maximum load average |
| 315 | simultaneously on a large number of repositories. |
| 316 | <p> |
| 317 | Note that this load-average limiting feature is only available on operating |
| 318 | systems that support the "getloadavg()" API. Most modern unix systems have |
| 319 | this interface, but Windows does not, so the feature will not work on Windows. |
| 320 | Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg" |
| 321 | file in the "proc" virtual filesystem. If you are running a Fossil instance |
| 322 | inside a chroot() jail on Linux, you will need to make the "/proc" file |
| 323 | system available inside that jail in order for this feature to work. On |
| 324 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -99,11 +99,11 @@ | |
| 99 | off of the wire. |
| 100 | </p> |
| 101 | <p> |
| 102 | [http://www.stunnel.org/ | Stunnel version 4] is an inetd-like process that |
| 103 | accepts and decodes SSL-encrypted connections. Fossil can be run directly from |
| 104 | stunnel in a manner similar to inetd and xinetd. This can be used to provide |
| 105 | a secure link to a Fossil project. The configuration needed to get stunnel4 |
| 106 | to invoke Fossil is very similar to the inetd and xinetd examples shown above. |
| 107 | The relevant parts of an stunnel configuration might look something |
| 108 | like the following: |
| 109 | <blockquote><pre><nowiki> |
| @@ -111,11 +111,11 @@ | |
| 111 | accept = www.ubercool-project.org:443 |
| 112 | TIMEOUTclose = 0 |
| 113 | exec = /usr/bin/fossil |
| 114 | execargs = /usr/bin/fossil http /home/fossil/ubercool.fossil --https |
| 115 | </nowiki></pre></blockquote> |
| 116 | See the stunnel4 documentation for further details about the /etc/stunnel/stunnel.conf |
| 117 | configuration file. Note that the [/help/http|fossil http] command should include |
| 118 | the --https option to let Fossil know to use "https" instead of "http" as the scheme |
| 119 | on generated hyperlinks. |
| 120 | <p> |
| 121 | Using inetd or xinetd or stunnel is a more complex setup |
| @@ -266,11 +266,11 @@ | |
| 266 | normally takes less than 10 milliseconds of CPU time to complete. So |
| 267 | requests can be arriving at a continuous rate of 20 or more per second |
| 268 | and the CPU can still be mostly idle. |
| 269 | <p> |
| 270 | However, there are some Fossil web pages that can consume large |
| 271 | amounts of CPU time, especially on repositories with a large number |
| 272 | of files or with long revision histories. High CPU usage pages include |
| 273 | [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], |
| 274 | [/help?cmd=/annotate | /annotate] and others. On very large repositories, |
| 275 | these commands can take 15 seconds or more of CPU time. |
| 276 | If these kinds of requests arrive too quickly, the load average on the |
| @@ -313,11 +313,11 @@ | |
| 313 | </pre></blockquote> |
| 314 | The second form is especially useful for changing the maximum load average |
| 315 | simultaneously on a large number of repositories. |
| 316 | <p> |
| 317 | Note that this load-average limiting feature is only available on operating |
| 318 | systems that support the "getloadavg()" API. Most modern Unix systems have |
| 319 | this interface, but Windows does not, so the feature will not work on Windows. |
| 320 | Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg" |
| 321 | file in the "proc" virtual filesystem. If you are running a Fossil instance |
| 322 | inside a chroot() jail on Linux, you will need to make the "/proc" file |
| 323 | system available inside that jail in order for this feature to work. On |
| 324 |
+3
-3
| --- www/stats.wiki | ||
| +++ www/stats.wiki | ||
| @@ -123,20 +123,20 @@ | ||
| 123 | 123 | prior to measuring its compressed size. Repository sizes would typically |
| 124 | 124 | be 20% larger without that rebuild. |
| 125 | 125 | |
| 126 | 126 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | 127 | total number of bytes sent from server back to the client. The number of |
| 128 | -bytes sent from client to server is neglible in comparison. | |
| 128 | +bytes sent from client to server is negligible in comparison. | |
| 129 | 129 | These byte counts include HTTP protocol overhead. |
| 130 | 130 | |
| 131 | 131 | In the table and throughout this article, |
| 132 | 132 | "GB" means gigabytes (10<sup><small>9</small></sup> bytes) |
| 133 | 133 | not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> |
| 134 | 134 | (2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" |
| 135 | 135 | means megabytes and kilobytes, not mebibytes and kibibytes. |
| 136 | 136 | |
| 137 | -<h2>Analysis And Supplimental Data</h2> | |
| 137 | +<h2>Analysis And Supplemental Data</h2> | |
| 138 | 138 | |
| 139 | 139 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | 140 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | 141 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | 142 | Each of these edits is stored as a delta, and hence the SQLite project |
| @@ -152,8 +152,8 @@ | ||
| 152 | 152 | fossil using only about 23.2MB of network traffic. (This 23.2MB includes |
| 153 | 153 | all the changes to SQLite that have been made since the conversion from |
| 154 | 154 | CVS. Of those changes are omitted, the clone bandwidth drops to 13MB.) |
| 155 | 155 | The "sync" protocol |
| 156 | 156 | used by fossil has turned out to be surprisingly efficient. A typical |
| 157 | -check-in on SQLite might use 3 or 4KB of network bandwidth total. Hardly | |
| 157 | +check-in on SQLite might use 3 or 4KB of network bandwidth total, hardly | |
| 158 | 158 | worth measuring. The sync protocol is efficient enough that, once cloned, |
| 159 | 159 | Fossil could easily be used over a dial-up connection. |
| 160 | 160 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -123,20 +123,20 @@ | |
| 123 | prior to measuring its compressed size. Repository sizes would typically |
| 124 | be 20% larger without that rebuild. |
| 125 | |
| 126 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | total number of bytes sent from server back to the client. The number of |
| 128 | bytes sent from client to server is neglible in comparison. |
| 129 | These byte counts include HTTP protocol overhead. |
| 130 | |
| 131 | In the table and throughout this article, |
| 132 | "GB" means gigabytes (10<sup><small>9</small></sup> bytes) |
| 133 | not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> |
| 134 | (2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" |
| 135 | means megabytes and kilobytes, not mebibytes and kibibytes. |
| 136 | |
| 137 | <h2>Analysis And Supplimental Data</h2> |
| 138 | |
| 139 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | Each of these edits is stored as a delta, and hence the SQLite project |
| @@ -152,8 +152,8 @@ | |
| 152 | fossil using only about 23.2MB of network traffic. (This 23.2MB includes |
| 153 | all the changes to SQLite that have been made since the conversion from |
| 154 | CVS. Of those changes are omitted, the clone bandwidth drops to 13MB.) |
| 155 | The "sync" protocol |
| 156 | used by fossil has turned out to be surprisingly efficient. A typical |
| 157 | check-in on SQLite might use 3 or 4KB of network bandwidth total. Hardly |
| 158 | worth measuring. The sync protocol is efficient enough that, once cloned, |
| 159 | Fossil could easily be used over a dial-up connection. |
| 160 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -123,20 +123,20 @@ | |
| 123 | prior to measuring its compressed size. Repository sizes would typically |
| 124 | be 20% larger without that rebuild. |
| 125 | |
| 126 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | total number of bytes sent from server back to the client. The number of |
| 128 | bytes sent from client to server is negligible in comparison. |
| 129 | These byte counts include HTTP protocol overhead. |
| 130 | |
| 131 | In the table and throughout this article, |
| 132 | "GB" means gigabytes (10<sup><small>9</small></sup> bytes) |
| 133 | not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> |
| 134 | (2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" |
| 135 | means megabytes and kilobytes, not mebibytes and kibibytes. |
| 136 | |
| 137 | <h2>Analysis And Supplemental Data</h2> |
| 138 | |
| 139 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | Each of these edits is stored as a delta, and hence the SQLite project |
| @@ -152,8 +152,8 @@ | |
| 152 | fossil using only about 23.2MB of network traffic. (This 23.2MB includes |
| 153 | all the changes to SQLite that have been made since the conversion from |
| 154 | CVS. Of those changes are omitted, the clone bandwidth drops to 13MB.) |
| 155 | The "sync" protocol |
| 156 | used by fossil has turned out to be surprisingly efficient. A typical |
| 157 | check-in on SQLite might use 3 or 4KB of network bandwidth total, hardly |
| 158 | worth measuring. The sync protocol is efficient enough that, once cloned, |
| 159 | Fossil could easily be used over a dial-up connection. |
| 160 |
+2
-2
| --- www/style.wiki | ||
| +++ www/style.wiki | ||
| @@ -23,11 +23,11 @@ | ||
| 23 | 23 | 16. All C-code conforms to ANSI C-89. |
| 24 | 24 | |
| 25 | 25 | 17. All comments and identifiers are in English. |
| 26 | 26 | |
| 27 | 27 | 18. The program is single-threaded. Do not use threads. |
| 28 | - (One exception to this is the HTTP server implementation for windows, | |
| 28 | + (One exception to this is the HTTP server implementation for Windows, | |
| 29 | 29 | which we do not know how to implement without the use of threads.) |
| 30 | 30 | |
| 31 | 31 | |
| 32 | 32 | <b>C preprocessor macros</b>: |
| 33 | 33 | |
| @@ -46,11 +46,11 @@ | ||
| 46 | 46 | |
| 47 | 47 | 30. Every function has a header comment describing the purpose and use |
| 48 | 48 | of the function. |
| 49 | 49 | |
| 50 | 50 | 31. Function header comment defines the behavior of the function in |
| 51 | - sufficient detail to allow the function to be reimplemented from | |
| 51 | + sufficient detail to allow the function to be re-implemented from | |
| 52 | 52 | scratch without reference to the original code. |
| 53 | 53 | |
| 54 | 54 | 32. Functions that perform dynamic memory allocation (either directly |
| 55 | 55 | or indirectly via subfunctions) say so in their header comments. |
| 56 | 56 | |
| 57 | 57 |
| --- www/style.wiki | |
| +++ www/style.wiki | |
| @@ -23,11 +23,11 @@ | |
| 23 | 16. All C-code conforms to ANSI C-89. |
| 24 | |
| 25 | 17. All comments and identifiers are in English. |
| 26 | |
| 27 | 18. The program is single-threaded. Do not use threads. |
| 28 | (One exception to this is the HTTP server implementation for windows, |
| 29 | which we do not know how to implement without the use of threads.) |
| 30 | |
| 31 | |
| 32 | <b>C preprocessor macros</b>: |
| 33 | |
| @@ -46,11 +46,11 @@ | |
| 46 | |
| 47 | 30. Every function has a header comment describing the purpose and use |
| 48 | of the function. |
| 49 | |
| 50 | 31. Function header comment defines the behavior of the function in |
| 51 | sufficient detail to allow the function to be reimplemented from |
| 52 | scratch without reference to the original code. |
| 53 | |
| 54 | 32. Functions that perform dynamic memory allocation (either directly |
| 55 | or indirectly via subfunctions) say so in their header comments. |
| 56 | |
| 57 |
| --- www/style.wiki | |
| +++ www/style.wiki | |
| @@ -23,11 +23,11 @@ | |
| 23 | 16. All C-code conforms to ANSI C-89. |
| 24 | |
| 25 | 17. All comments and identifiers are in English. |
| 26 | |
| 27 | 18. The program is single-threaded. Do not use threads. |
| 28 | (One exception to this is the HTTP server implementation for Windows, |
| 29 | which we do not know how to implement without the use of threads.) |
| 30 | |
| 31 | |
| 32 | <b>C preprocessor macros</b>: |
| 33 | |
| @@ -46,11 +46,11 @@ | |
| 46 | |
| 47 | 30. Every function has a header comment describing the purpose and use |
| 48 | of the function. |
| 49 | |
| 50 | 31. Function header comment defines the behavior of the function in |
| 51 | sufficient detail to allow the function to be re-implemented from |
| 52 | scratch without reference to the original code. |
| 53 | |
| 54 | 32. Functions that perform dynamic memory allocation (either directly |
| 55 | or indirectly via subfunctions) say so in their header comments. |
| 56 | |
| 57 |
+7
-7
| --- www/tech_overview.wiki | ||
| +++ www/tech_overview.wiki | ||
| @@ -124,12 +124,12 @@ | ||
| 124 | 124 | |
| 125 | 125 | The configuration database also maintains a list of repositories. This |
| 126 | 126 | list is used by the [/help/all | fossil all] command in order to run various |
| 127 | 127 | operations such as "sync" or "rebuild" on all repositories managed by a user. |
| 128 | 128 | |
| 129 | -On unix systems, the configuration database is named ".fossil" and is | |
| 130 | -located in the user's home directory. On windows, the configuration | |
| 129 | +On Unix systems, the configuration database is named ".fossil" and is | |
| 130 | +located in the user's home directory. On Windows, the configuration | |
| 131 | 131 | database is named "_fossil" (using an underscore as the first character |
| 132 | 132 | instead of a dot) and is located in the directory specified by the |
| 133 | 133 | LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. |
| 134 | 134 | |
| 135 | 135 | <h3>2.2 Repository Databases</h3> |
| @@ -186,20 +186,20 @@ | ||
| 186 | 186 | |
| 187 | 187 | The global project state information in the repository database is |
| 188 | 188 | supplemented by computed metadata that makes querying the project state |
| 189 | 189 | more efficient. Metadata includes information such as the following: |
| 190 | 190 | |
| 191 | - * The names for all files found in any checkin. | |
| 191 | + * The names for all files found in any check-in. | |
| 192 | 192 | * All check-ins that modify a given file |
| 193 | - * Parents and children of each checkin. | |
| 193 | + * Parents and children of each check-in. | |
| 194 | 194 | * Potential timeline rows. |
| 195 | - * The names of all symbolic tags and the checkins they apply to. | |
| 195 | + * The names of all symbolic tags and the check-ins they apply to. | |
| 196 | 196 | * The names of all wiki pages and the artifacts that comprise each |
| 197 | 197 | wiki page. |
| 198 | 198 | * Attachments and the wiki pages or tickets they apply to. |
| 199 | 199 | * Current content of each ticket. |
| 200 | - * Cross-references between tickets, checkins, and wiki pages. | |
| 200 | + * Cross-references between tickets, check-ins, and wiki pages. | |
| 201 | 201 | |
| 202 | 202 | The metadata is held in various SQL tables in the repository database. |
| 203 | 203 | The metadata is designed to facilitate queries for the various timelines and |
| 204 | 204 | reports that Fossil generates. |
| 205 | 205 | As the functionality of Fossil evolves, |
| @@ -299,11 +299,11 @@ | ||
| 299 | 299 | * Files that have been [/help/add | added], |
| 300 | 300 | [/help/rm | removed], or [/help/mv | renamed] but not |
| 301 | 301 | yet committed. |
| 302 | 302 | * The mtime and size of files as they were originally checked out, |
| 303 | 303 | in order to expedite checking which files have been edited. |
| 304 | - * Other checkins that have been [/help/merge | merged] into the | |
| 304 | + * Other check-ins that have been [/help/merge | merged] into the | |
| 305 | 305 | working checkout but not yet committed. |
| 306 | 306 | * Copies of files prior to the most recent undoable operation - needed to |
| 307 | 307 | implement the [/help/undo | undo] and [/help/redo | redo] commands. |
| 308 | 308 | * The [/help/stash | stash]. |
| 309 | 309 | * State information for the [/help/bisect | bisect] command. |
| 310 | 310 |
| --- www/tech_overview.wiki | |
| +++ www/tech_overview.wiki | |
| @@ -124,12 +124,12 @@ | |
| 124 | |
| 125 | The configuration database also maintains a list of repositories. This |
| 126 | list is used by the [/help/all | fossil all] command in order to run various |
| 127 | operations such as "sync" or "rebuild" on all repositories managed by a user. |
| 128 | |
| 129 | On unix systems, the configuration database is named ".fossil" and is |
| 130 | located in the user's home directory. On windows, the configuration |
| 131 | database is named "_fossil" (using an underscore as the first character |
| 132 | instead of a dot) and is located in the directory specified by the |
| 133 | LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. |
| 134 | |
| 135 | <h3>2.2 Repository Databases</h3> |
| @@ -186,20 +186,20 @@ | |
| 186 | |
| 187 | The global project state information in the repository database is |
| 188 | supplemented by computed metadata that makes querying the project state |
| 189 | more efficient. Metadata includes information such as the following: |
| 190 | |
| 191 | * The names for all files found in any checkin. |
| 192 | * All check-ins that modify a given file |
| 193 | * Parents and children of each checkin. |
| 194 | * Potential timeline rows. |
| 195 | * The names of all symbolic tags and the checkins they apply to. |
| 196 | * The names of all wiki pages and the artifacts that comprise each |
| 197 | wiki page. |
| 198 | * Attachments and the wiki pages or tickets they apply to. |
| 199 | * Current content of each ticket. |
| 200 | * Cross-references between tickets, checkins, and wiki pages. |
| 201 | |
| 202 | The metadata is held in various SQL tables in the repository database. |
| 203 | The metadata is designed to facilitate queries for the various timelines and |
| 204 | reports that Fossil generates. |
| 205 | As the functionality of Fossil evolves, |
| @@ -299,11 +299,11 @@ | |
| 299 | * Files that have been [/help/add | added], |
| 300 | [/help/rm | removed], or [/help/mv | renamed] but not |
| 301 | yet committed. |
| 302 | * The mtime and size of files as they were originally checked out, |
| 303 | in order to expedite checking which files have been edited. |
| 304 | * Other checkins that have been [/help/merge | merged] into the |
| 305 | working checkout but not yet committed. |
| 306 | * Copies of files prior to the most recent undoable operation - needed to |
| 307 | implement the [/help/undo | undo] and [/help/redo | redo] commands. |
| 308 | * The [/help/stash | stash]. |
| 309 | * State information for the [/help/bisect | bisect] command. |
| 310 |
| --- www/tech_overview.wiki | |
| +++ www/tech_overview.wiki | |
| @@ -124,12 +124,12 @@ | |
| 124 | |
| 125 | The configuration database also maintains a list of repositories. This |
| 126 | list is used by the [/help/all | fossil all] command in order to run various |
| 127 | operations such as "sync" or "rebuild" on all repositories managed by a user. |
| 128 | |
| 129 | On Unix systems, the configuration database is named ".fossil" and is |
| 130 | located in the user's home directory. On Windows, the configuration |
| 131 | database is named "_fossil" (using an underscore as the first character |
| 132 | instead of a dot) and is located in the directory specified by the |
| 133 | LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. |
| 134 | |
| 135 | <h3>2.2 Repository Databases</h3> |
| @@ -186,20 +186,20 @@ | |
| 186 | |
| 187 | The global project state information in the repository database is |
| 188 | supplemented by computed metadata that makes querying the project state |
| 189 | more efficient. Metadata includes information such as the following: |
| 190 | |
| 191 | * The names for all files found in any check-in. |
| 192 | * All check-ins that modify a given file |
| 193 | * Parents and children of each check-in. |
| 194 | * Potential timeline rows. |
| 195 | * The names of all symbolic tags and the check-ins they apply to. |
| 196 | * The names of all wiki pages and the artifacts that comprise each |
| 197 | wiki page. |
| 198 | * Attachments and the wiki pages or tickets they apply to. |
| 199 | * Current content of each ticket. |
| 200 | * Cross-references between tickets, check-ins, and wiki pages. |
| 201 | |
| 202 | The metadata is held in various SQL tables in the repository database. |
| 203 | The metadata is designed to facilitate queries for the various timelines and |
| 204 | reports that Fossil generates. |
| 205 | As the functionality of Fossil evolves, |
| @@ -299,11 +299,11 @@ | |
| 299 | * Files that have been [/help/add | added], |
| 300 | [/help/rm | removed], or [/help/mv | renamed] but not |
| 301 | yet committed. |
| 302 | * The mtime and size of files as they were originally checked out, |
| 303 | in order to expedite checking which files have been edited. |
| 304 | * Other check-ins that have been [/help/merge | merged] into the |
| 305 | working checkout but not yet committed. |
| 306 | * Copies of files prior to the most recent undoable operation - needed to |
| 307 | implement the [/help/undo | undo] and [/help/redo | redo] commands. |
| 308 | * The [/help/stash | stash]. |
| 309 | * State information for the [/help/bisect | bisect] command. |
| 310 |
+4
-4
| --- www/th1.md | ||
| +++ www/th1.md | ||
| @@ -5,11 +5,11 @@ | ||
| 5 | 5 | content in Fossil. |
| 6 | 6 | |
| 7 | 7 | Origins |
| 8 | 8 | ------- |
| 9 | 9 | |
| 10 | -TH1 began as a minimalist reimplementation of the TCL scripting language. | |
| 10 | +TH1 began as a minimalist re-implementation of the TCL scripting language. | |
| 11 | 11 | There was a need to test the SQLite library on Symbian phones, but at that |
| 12 | 12 | time all of the test cases for SQLite were written in Tcl and Tcl could not |
| 13 | 13 | be easily compiled on the SymbianOS. So TH1 was developed as a cut-down |
| 14 | 14 | version of TCL that would facilitate running the SQLite test scripts on |
| 15 | 15 | SymbianOS. |
| @@ -79,11 +79,11 @@ | ||
| 79 | 79 | |
| 80 | 80 | Summary of Core TH1 Commands |
| 81 | 81 | ---------------------------- |
| 82 | 82 | |
| 83 | 83 | The original TCL language after when TH1 is modeled has a very rich |
| 84 | -repetoire of commands. TH1, as it is designed to be minimalist and | |
| 84 | +repertoire of commands. TH1, as it is designed to be minimalist and | |
| 85 | 85 | embedded has a greatly reduced command set. The following bullets |
| 86 | 86 | summarize the commands available in TH1: |
| 87 | 87 | |
| 88 | 88 | * break |
| 89 | 89 | * catch SCRIPT ?VARIABLE? |
| @@ -157,10 +157,10 @@ | ||
| 157 | 157 | |
| 158 | 158 | Each of the commands above is documented by a block comment above their |
| 159 | 159 | implementation in the th_main.c source file. |
| 160 | 160 | |
| 161 | 161 | **To Do:** We would like to have a community volunteer go through and |
| 162 | -copy the documentation for each of these command (with appropriate | |
| 162 | +copy the documentation for each of these commands (with appropriate | |
| 163 | 163 | format changes and spelling and grammar corrections) into subsequent |
| 164 | 164 | sections of this document. It is suggested that the list of extension |
| 165 | 165 | commands be left intact - as a quick reference. But it would be really |
| 166 | -nice to also have the details of each each command does. | |
| 166 | +nice to also have the details of what each command does. | |
| 167 | 167 |
| --- www/th1.md | |
| +++ www/th1.md | |
| @@ -5,11 +5,11 @@ | |
| 5 | content in Fossil. |
| 6 | |
| 7 | Origins |
| 8 | ------- |
| 9 | |
| 10 | TH1 began as a minimalist reimplementation of the TCL scripting language. |
| 11 | There was a need to test the SQLite library on Symbian phones, but at that |
| 12 | time all of the test cases for SQLite were written in Tcl and Tcl could not |
| 13 | be easily compiled on the SymbianOS. So TH1 was developed as a cut-down |
| 14 | version of TCL that would facilitate running the SQLite test scripts on |
| 15 | SymbianOS. |
| @@ -79,11 +79,11 @@ | |
| 79 | |
| 80 | Summary of Core TH1 Commands |
| 81 | ---------------------------- |
| 82 | |
| 83 | The original TCL language after when TH1 is modeled has a very rich |
| 84 | repetoire of commands. TH1, as it is designed to be minimalist and |
| 85 | embedded has a greatly reduced command set. The following bullets |
| 86 | summarize the commands available in TH1: |
| 87 | |
| 88 | * break |
| 89 | * catch SCRIPT ?VARIABLE? |
| @@ -157,10 +157,10 @@ | |
| 157 | |
| 158 | Each of the commands above is documented by a block comment above their |
| 159 | implementation in the th_main.c source file. |
| 160 | |
| 161 | **To Do:** We would like to have a community volunteer go through and |
| 162 | copy the documentation for each of these command (with appropriate |
| 163 | format changes and spelling and grammar corrections) into subsequent |
| 164 | sections of this document. It is suggested that the list of extension |
| 165 | commands be left intact - as a quick reference. But it would be really |
| 166 | nice to also have the details of each each command does. |
| 167 |
| --- www/th1.md | |
| +++ www/th1.md | |
| @@ -5,11 +5,11 @@ | |
| 5 | content in Fossil. |
| 6 | |
| 7 | Origins |
| 8 | ------- |
| 9 | |
| 10 | TH1 began as a minimalist re-implementation of the TCL scripting language. |
| 11 | There was a need to test the SQLite library on Symbian phones, but at that |
| 12 | time all of the test cases for SQLite were written in Tcl and Tcl could not |
| 13 | be easily compiled on the SymbianOS. So TH1 was developed as a cut-down |
| 14 | version of TCL that would facilitate running the SQLite test scripts on |
| 15 | SymbianOS. |
| @@ -79,11 +79,11 @@ | |
| 79 | |
| 80 | Summary of Core TH1 Commands |
| 81 | ---------------------------- |
| 82 | |
| 83 | The original TCL language after when TH1 is modeled has a very rich |
| 84 | repertoire of commands. TH1, as it is designed to be minimalist and |
| 85 | embedded has a greatly reduced command set. The following bullets |
| 86 | summarize the commands available in TH1: |
| 87 | |
| 88 | * break |
| 89 | * catch SCRIPT ?VARIABLE? |
| @@ -157,10 +157,10 @@ | |
| 157 | |
| 158 | Each of the commands above is documented by a block comment above their |
| 159 | implementation in the th_main.c source file. |
| 160 | |
| 161 | **To Do:** We would like to have a community volunteer go through and |
| 162 | copy the documentation for each of these commands (with appropriate |
| 163 | format changes and spelling and grammar corrections) into subsequent |
| 164 | sections of this document. It is suggested that the list of extension |
| 165 | commands be left intact - as a quick reference. But it would be really |
| 166 | nice to also have the details of what each command does. |
| 167 |
+5
-5
| --- www/webui.wiki | ||
| +++ www/webui.wiki | ||
| @@ -12,13 +12,13 @@ | ||
| 12 | 12 | * Graphs of revision and branching history |
| 13 | 13 | * [./event.wiki | Technical notes] |
| 14 | 14 | * File and version lists and differences |
| 15 | 15 | * Download historical versions as ZIP archives |
| 16 | 16 | * Historical change data |
| 17 | - * Add and remove tags on checkins | |
| 18 | - * Move checkins between branches | |
| 19 | - * Revise checkin comments | |
| 17 | + * Add and remove tags on check-ins | |
| 18 | + * Move check-ins between branches | |
| 19 | + * Revise check-in comments | |
| 20 | 20 | * Manage user credentials and access permissions |
| 21 | 21 | * And so forth... (some [./webpage-ex.md|examples]) |
| 22 | 22 | |
| 23 | 23 | You get all of this, and more, for free when you use Fossil. |
| 24 | 24 | There are no extra programs to install or setup. |
| @@ -104,16 +104,16 @@ | ||
| 104 | 104 | of time learning a new markup language. And, as with tickets, all of |
| 105 | 105 | your edits will automatically merge with those of your co-workers when |
| 106 | 106 | your repository synchronizes. |
| 107 | 107 | |
| 108 | 108 | You can view summary reports of <b>branches</b> in the |
| 109 | -check-in graph by visiting the "Branche" links on the | |
| 109 | +check-in graph by visiting the "Branches" link on the | |
| 110 | 110 | menu bar. From those pages you can follow hyperlinks to get additional |
| 111 | 111 | details. These screens allow you to easily keep track of what is going |
| 112 | 112 | on with separate subteams within your project team. |
| 113 | 113 | |
| 114 | -The "Files" link on the menu allows you to browse though the <b>file | |
| 114 | +The "Files" link on the menu allows you to browse through the <b>file | |
| 115 | 115 | hierarchy</b> of the project and to view complete changes histories on |
| 116 | 116 | individual files, with hyperlinks to the check-ins that made those |
| 117 | 117 | changes, and with diffs and annotated diffs between versions. |
| 118 | 118 | |
| 119 | 119 | The web interface supports [./embeddeddoc.wiki | embedded documentation]. |
| 120 | 120 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -12,13 +12,13 @@ | |
| 12 | * Graphs of revision and branching history |
| 13 | * [./event.wiki | Technical notes] |
| 14 | * File and version lists and differences |
| 15 | * Download historical versions as ZIP archives |
| 16 | * Historical change data |
| 17 | * Add and remove tags on checkins |
| 18 | * Move checkins between branches |
| 19 | * Revise checkin comments |
| 20 | * Manage user credentials and access permissions |
| 21 | * And so forth... (some [./webpage-ex.md|examples]) |
| 22 | |
| 23 | You get all of this, and more, for free when you use Fossil. |
| 24 | There are no extra programs to install or setup. |
| @@ -104,16 +104,16 @@ | |
| 104 | of time learning a new markup language. And, as with tickets, all of |
| 105 | your edits will automatically merge with those of your co-workers when |
| 106 | your repository synchronizes. |
| 107 | |
| 108 | You can view summary reports of <b>branches</b> in the |
| 109 | check-in graph by visiting the "Branche" links on the |
| 110 | menu bar. From those pages you can follow hyperlinks to get additional |
| 111 | details. These screens allow you to easily keep track of what is going |
| 112 | on with separate subteams within your project team. |
| 113 | |
| 114 | The "Files" link on the menu allows you to browse though the <b>file |
| 115 | hierarchy</b> of the project and to view complete changes histories on |
| 116 | individual files, with hyperlinks to the check-ins that made those |
| 117 | changes, and with diffs and annotated diffs between versions. |
| 118 | |
| 119 | The web interface supports [./embeddeddoc.wiki | embedded documentation]. |
| 120 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -12,13 +12,13 @@ | |
| 12 | * Graphs of revision and branching history |
| 13 | * [./event.wiki | Technical notes] |
| 14 | * File and version lists and differences |
| 15 | * Download historical versions as ZIP archives |
| 16 | * Historical change data |
| 17 | * Add and remove tags on check-ins |
| 18 | * Move check-ins between branches |
| 19 | * Revise check-in comments |
| 20 | * Manage user credentials and access permissions |
| 21 | * And so forth... (some [./webpage-ex.md|examples]) |
| 22 | |
| 23 | You get all of this, and more, for free when you use Fossil. |
| 24 | There are no extra programs to install or setup. |
| @@ -104,16 +104,16 @@ | |
| 104 | of time learning a new markup language. And, as with tickets, all of |
| 105 | your edits will automatically merge with those of your co-workers when |
| 106 | your repository synchronizes. |
| 107 | |
| 108 | You can view summary reports of <b>branches</b> in the |
| 109 | check-in graph by visiting the "Branches" link on the |
| 110 | menu bar. From those pages you can follow hyperlinks to get additional |
| 111 | details. These screens allow you to easily keep track of what is going |
| 112 | on with separate subteams within your project team. |
| 113 | |
| 114 | The "Files" link on the menu allows you to browse through the <b>file |
| 115 | hierarchy</b> of the project and to view complete changes histories on |
| 116 | individual files, with hyperlinks to the check-ins that made those |
| 117 | changes, and with diffs and annotated diffs between versions. |
| 118 | |
| 119 | The web interface supports [./embeddeddoc.wiki | embedded documentation]. |
| 120 |