Ticket UUID: | 9dd30a98f562c4b4d2e1f098d6c56a909b777133 | ||
Title: | Patch for fixing spelling mistakes in documentation | ||
Status: | Fixed | Type: | Documentation |
Severity: | Important | Priority: | |
Subsystem: | Resolution: | Fixed | |
Last Modified: | 2010-06-11 13:51:43 | ||
Version Found In: | |||
Description & Comments: | |||
Patch below.
Index: www/branching.wiki =================================================================== --- www/branching.wiki +++ www/branching.wiki @@ -51,20 +51,20 @@ editing check-in 2 are named Alice and Bob. Suppose Alice finished her edits first and did a commit, resulting in check-in 3. Later, when Bob tried to commit his changes, fossil would try to verify that check-in 2 was still a leaf. Fossil would see that check-in 3 had occurred and would abort Bob's commit attempt with a message "would fork". This allows Bob -to do a "fossil update" which would pull in Alices changes and merge them +to do a "fossil update" which would pull in Alice's changes and merge them together with his own changes. After merging, Bob could then commit check-in 4 as a child of check-in 3 and the result would be a linear graph as shown in figure 1. This is how CVS works. This is also how fossil works in "autosync" mode. But it might be that Bob is off-network when he does his commit, so he has no way of knowing that Alice has already committed her changes. Or, it could be that Bob has turned off "autosync" mode in SQLite. Or, -maybe Bob just doesn't want to merge in Alices changes before he has +maybe Bob just doesn't want to merge in Alice's changes before he has saved his own, so he forces the commit to occur using the "--force" option to the fossil <b>commit</b> command. For whatever reason, two commits against check-in 2 have occurred and now the tree has two leaves. So which version of the project is the "latest" in the sense of having @@ -194,11 +194,11 @@ are symbolic name tags. When a symbolic name tag is attached to a check-in, that allows you to refer to that check-in by its symbolic name rather than by its 40-character SHA1 hash name. When a symbolic name tag propagates (as does the <b>sym-trunk</b> tag) then referring to that name is the same as referring to the most recent check-in with that name. -Thus the two tags on check-in one cause all decendents to be in the +Thus the two tags on check-in one cause all descendants to be in the "trunk" branch and to have the symbolic name "trunk". Check-in 4 has a <b>branch</b> tag which changes the name of the branch to "test". The branch tag on check-in 4 propagates to check-ins 6 and 9. But because tag propagation does not follow merge links, the <b>branch=test</b> @@ -238,11 +238,11 @@ branch property.</p></dd> <dt><b>Leaf</b></dt> <dd><p>A leaf is a check-in that has no children in the same branch.</p></dd> <dt><b>Closed Leaf</b></dt> <dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves -are intented to never be extended with descendents and hence are omitted +are intented to never be extended with descendants and hence are omitted from lists of leaves in the command-line and web interface.</p></dd> <dt><b>Open Leaf</b></dt> <dd><p>A open leaf is a leaf that is not closed.</p></dd> <dt><b>Fork</b></dt> <dd><p>A fork occurs when a check-in has two or more direct (non-merge) Index: www/cmd_all.wiki =================================================================== --- www/cmd_all.wiki +++ www/cmd_all.wiki @@ -37,11 +37,11 @@ Or, you could just jog your memory. The <code>all</code> command uses the <i>.fossil</i> file in the home directory to find all of your repositories, so you can mess it up by moving your repositories around. This is easy to do inadvertently if -you have a cavalier attitude about repos, but you'll know pretty +you have a cavalier attitude about repositories, but you'll know pretty quickly that you've done it—many commands you try to use from inside of a checkout won't work correctly. The <i>.fossil</i> file is an <b>sqlite</b> db file which fossil uses to keeping track of repository locations. Advice: if you move your repositories around, let fossil know you did; Index: www/faq.wiki =================================================================== --- www/faq.wiki +++ www/faq.wiki @@ -70,11 +70,11 @@ main repository.</b></p> <blockquote>Use the <b>--private</b> command-line option on the <b>commit</b> command. The result will be a check-in which exists on your local repository only and is never pushed to other repositories. -All descendents of a private check-in are also private. +All descendants of a private check-in are also private. Unless you specify something different using the <b>--branch</b> and/or <b>--bgcolor</b> options, the new private check-in will be put on a branch named "private" with an orange background color. Index: www/fileformat.wiki =================================================================== --- www/fileformat.wiki +++ www/fileformat.wiki @@ -243,11 +243,11 @@ within the repository. The basic format of a control artifact is the same as a manifest or cluster. A control artifact is a text files divided into cards by newline characters. Each card has a single-character card type followed by arguments. Spaces separate the card type and the arguments. No surplus whitespace is allowed. -All cards must occur in strict lexigraphical order. +All cards must occur in strict lexicographical order. Allowed cards in a control artifact are as follows: <blockquote> <b>D</b> <i>time-and-date-stamp</i><br /> Index: www/index.wiki =================================================================== --- www/index.wiki +++ www/index.wiki @@ -112,11 +112,11 @@ to do it using fossil. * The [./selfcheck.wiki | automatic self-check] mechanism helps insure project integrity. * Fossil contains a [./wikitheory.wiki | built-in wiki]. * There is a - [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] (with publically readable + [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list] (with publicly readable [http://www.mail-archive.com/fossil-users@lists.fossil-scm.org | archives] available for discussing fossil issues. * [./stats.wiki | Performance statistics] taken from real-world projects hosted on fossil. * How to [./shunning.wiki | delete content] from a fossil repository. Index: www/newrepo.wiki =================================================================== --- www/newrepo.wiki +++ www/newrepo.wiki @@ -32,11 +32,11 @@ The <tt>ui</tt> command starts up a server (with an optional <tt>-port NUMBER</tt> argument) and launches a web browser pointing at the fossil server. From there it takes just a few moments to configure the repo. Most importantly, go to the Admin menu, then the Users link, and set your account name and password, and grant your account all access -priviledges. (I also like to grant Clone access to the anonymous user, +privileges. (I also like to grant Clone access to the anonymous user, but that's personal preference.) Once you are done, kill the fossil server (with Ctrl-C or equivalent) and close the browser window. @@ -63,11 +63,11 @@ information about your local repository. You can ignore it for all purposes, but be sure not to accidentally remove it or otherwise damage it - it belongs to fossil, not you. The next thing we need to do is add files to our repository. As it -happens, we have a few C source files laying around, which we'll +happens, we have a few C source files lying around, which we'll simply copy into our working directory. <verbatim> stephan@ludo:~/fossil/demo$ cp ../csnip/*.{c,h} . stephan@ludo:~/fossil/demo$ ls @@ -75,11 +75,11 @@ tokenize_path.c tokenize_path.h vappendf.c vappendf.h Fossil doesn't know about those files yet. Telling fossil about a new file is a two-step process. First we add the file -to the repo, then we commit the file. This is a familiar +to the repository, then we commit the file. This is a familiar process for anyone who's worked with SCM systems before: stephan@ludo:~/fossil/demo$ fossil add *.{c,h} stephan@ludo:~/fossil/demo$ fossil commit -m "egg" Index: www/qandc.wiki =================================================================== --- www/qandc.wiki +++ www/qandc.wiki @@ -38,11 +38,11 @@ code while off network, then sync your changes later. With Trac, you can only view and edit tickets and wiki while you are connected to the server. </li> <li> Fossil is lightweight and fully self-contained. It is very easy to setup on a low-resource machine. Fossil does not require an - administator.</li> + administrator.</li> <li> Fossil integrates code versioning into the same repository with wiki and tickets. There is nothing extra to add or install. Fossil is an all-in-one turnkey solution. </li> </ol> </blockquote> @@ -70,12 +70,12 @@ <blockquote> <p>I take a pragmatic approach to software: form follows function. To me, it is more important to have a reliable, fast, efficient, enduring, and simple DVCS than one that looks pretty.</p> -<p>On the other hand, if you have patches that improve the apparance -of Fossil without seriously compromising its reliablity, performance, +<p>On the other hand, if you have patches that improve the appearance +of Fossil without seriously compromising its reliability, performance, and/or maintainability, I will be happy to accept them. Fossil is self-hosting. Send email to request a password that will let you push to the main fossil repository.</p> </blockquote> Index: www/quickstart.wiki =================================================================== --- www/quickstart.wiki +++ www/quickstart.wiki @@ -39,11 +39,11 @@ <blockquote> <b>fossil clone http://www.fossil-scm.org/ myclone.fossil</b> </blockquote> - <p>The new local copy of the respository is stored in a single file, + <p>The new local copy of the repository is stored in a single file, which in the example above is named "myclone.fossil". You can name your repositories anything you want. The ".fossil" suffix is not required.</p> <p>Note: If you are behind a restrictive firewall, you might need Index: www/reference.wiki =================================================================== --- www/reference.wiki +++ www/reference.wiki @@ -1,18 +1,18 @@ <h2>Command Line Interface Reference</h2> This is an easy introduction to the fossil command line interface (cli). It assumes some familiarity with using the command line, and - with Source Code Maintenence (SCM) systems—but not <i>too</i> + with Source Code Maintenance (SCM) systems—but not <i>too</i> much. If you are trying to find information about fossil's web capabilities, see the <a href="index.wiki">Fossil Home</a> and <a href="wikitheory.wiki">Fossil Wiki</a> pages for pointers. <h3>Things to note</h3> - * Fossil cli commands do not use special delimeters, they use + * Fossil cli commands do not use special delimiters, they use spaces. This is traditional with VCS/SCM. Some <i>options</i> to fossil commands <i>do</i> use special delimiters, particularly the '-' (hyphen, or dash) character. This is very similar to Tcl. Think of fossil as a shell you invoke and feed a command to, including any options, and it will make more sense. @@ -40,11 +40,11 @@ effectively is to [./quickstart.wiki#fslclone | clone the repository for fossil] itself. You can then poke around using the <code>fossil ui</code> command, and look things up with no connection worries. You can set up test repositories and try things out on-the-fly to see how - they work, using their own ui's. The CLI will far easier to + they work, using their own UIs. The CLI will far easier to understand if you can run a repository, watch it in a browser, and hack around with it in a simplified environment (your tests) with guaranteed and fast access to the sources & docs (your cloned fossil repository). <br /><br /> <br /> @@ -179,11 +179,11 @@ <hr><a href="#tof">ˆ</a> <a name="cgi">Usage: </a><a href="cmd_cgi.wiki">fossil cgi</a> SCRIPT The SCRIPT argument is the name of a file that is the CGI script that is being run. The command name, "cgi", may be omitted if the GATEWAY_INTERFACE environment variable is set to "CGI" (which - should always be the case for CGI scripts run by a webserver.) The + should always be the case for CGI scripts run by a web server.) The SCRIPT file should look something like this: #!/usr/bin/fossil repository: /home/somebody/project.db @@ -241,11 +241,11 @@ Where METHOD is one of: export import merge pull push reset. All methods accept the -R or --repository option to specific a repository. fossil configuration export AREA FILENAME - Write to FILENAME exported configuraton information for AREA. + Write to FILENAME exported configuration information for AREA. AREA can be one of: all ticket skin project fossil configuration import FILENAME Read a configuration from FILENAME, overwriting the current @@ -297,11 +297,11 @@ <a name="diff">Usage: </a><a href="cmd_diff.wiki">fossil diff</a>|gdiff ?-i? ?-r REVISION? FILE... Show the difference between the current version of a file (as it exists on disk) and that same file as it was checked out. diff will show a textual diff while gdiff will attempt to run a - graphical diff command that you have setup. If the choosen command + graphical diff command that you have setup. If the chosen command is not yet configured, the internal textual diff command will be used. If -i is supplied for either diff or gdiff, the internal textual diff command will be executed. @@ -334,11 +334,11 @@ <hr><a href="#tof">ˆ</a> <a name="info">Usage: </a><a href="cmd_info.wiki">fossil info</a> ?ARTIFACT-ID|FILENAME? With no arguments, provide information about the current tree. If an argument is specified, provide information about the object - in the respository of the current tree that the argument refers + in the repository of the current tree that the argument refers to. Or if the argument is the name of a repository, show information about that repository. <hr><a href="#tof">ˆ</a> <a name="leaves">Usage: </a><a href="cmd_leaves.wiki">fossil leaves</a> @@ -383,11 +383,11 @@ Deliver a report of the repository statistics for the current checkout. <hr><a href="#tof">ˆ</a> - <a name="pull">Usage: </a><a href="cmd_pull.wiki">fossil pull</a> ?URL? ?-R|--respository REPOSITORY? + <a name="pull">Usage: </a><a href="cmd_pull.wiki">fossil pull</a> ?URL? ?-R|--repository REPOSITORY? Pull changes in a remote repository into the local repository. The repository is identified by the -R or --repository option. If there is no such option then the open repository is used. The URL of the remote server is specified on the command line If no URL is specified then the URL used by the most recent @@ -655,11 +655,11 @@ FILE or from standard input. fossil wiki list Lists all wiki entries, one per line, ordered - case-insentively by name. + case-insensitively by name. TODOs: fossil wiki export ?-u ARTIFACT? WikiName ?FILE? @@ -691,8 +691,8 @@ fossil help... Duplicate commands are only listed once (I <i>think</i>). There are several bits of <b>fossil</b> that are not addressed in the help for commands (special wiki directories, special users, etc.) so they are (currently) not addressed here. Clarity and brevity may be sacrificed for expediency at the authors indiscretion. All spelling and - grammatical mistakes are somebody elses fault.<code> void * </code> + grammatical mistakes are somebody else's fault.<code> void * </code> prohibited where<code> __C_PLUS_PLUS__ </code>. Title and taxes extra. Not valid in Hooptigonia. Index: www/selfcheck.wiki =================================================================== --- www/selfcheck.wiki +++ www/selfcheck.wiki @@ -30,14 +30,14 @@ If something goes wrong in the middle of the commit, then the transaction is rolled back and the database is unchanged. <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> -The content files that comprise the global state of a fossil respository +The content files that comprise the global state of a fossil repository are stored in the repository as a tree. The leaves of the tree are stored as zlib-compressed BLOBs. Interior nodes are deltas from their -decendants. A lot of encoding is going on. There is +descendants. A lot of encoding is going on. There is zlib-compression which is relatively well-tested but still might cause corruption if used improperly. And there is the relatively new delta-encoding mechanism designed expressly for fossil. We want to make sure that bugs in these encoding mechanisms do not lead to loss of data. @@ -64,11 +64,11 @@ files. <h2>Checksum Over All Files In A Check-in</h2> Manifest artifacts that define a check-in have two fields (the -R-card and Z-card) that record MD5 hashs of the manifest itself +R-card and Z-card) that record MD5 hashes of the manifest itself and of all other files in the manifest. Prior to any check-in commit, these checksums are verified to ensure that the check-in checked in agrees exactly with what is on disk. Similarly, the repository checksum is verified after a checkout to make sure that the entire repository was checked out correctly. Index: www/shunning.wiki =================================================================== --- www/shunning.wiki +++ www/shunning.wiki @@ -38,13 +38,13 @@ The shunning list is part of the local state of a Fossil repository. In other words, shunning does not propagate using the normal "sync" mechanism. An artifact can be shunned from one repository but be allowed to exist in another. The fact that the shunning list does not propagate is a security feature. If the -shunning list propagated then a malecious user (or +shunning list propagated then a malicious user (or a bug in the fossil code) might introduce a shun record that would -propagate through all respositories in a network and permanently +propagate through all repositories in a network and permanently destroy vital information. By refusing to propagate the shunning list, Fossil insures that no remote user will ever be able to remove information from your personal repositories without your permission. The shunning list does not propagate by the normal "sync" mechanism, @@ -57,11 +57,11 @@ The two command above will pull or push shunning lists from or to the <i>remote-url</i> indicated and merge the lists on the receiving end. "Admin" privilege on the remote server is required in order to push a shun list. -Note that the shunning list remains in the respository even after the +Note that the shunning list remains in the repository even after the shunned artifact has been removed. This is to prevent the artifact from being reintroduced into the repository the next time it syncs with another repository that has not shunned the artifact. <h3>Managing the shunning list</h3> @@ -70,11 +70,11 @@ with "admin" privilege on the "/shunned" URL of the web interface to Fossil. That URL is accessible under the "Admin" button on the default menu bar. Items can be added to or removed from the shunning list. "Sync" operations are inhibited as soon as the artifact is added to the shunning list, but the content of the artifact is not actually removed -from the responstory until the next time the repository is rebuilt. +from the repository until the next time the repository is rebuilt. When viewing individual artifacts with the web interface, "admin" users will usually see a "Shun" option in the submenu that will take them directly to the shunning page and enable that artifact to be shunned with a single additional mouse click. Index: www/sync.wiki =================================================================== --- www/sync.wiki +++ www/sync.wiki @@ -26,12 +26,12 @@ shared to a few hundred.</p> <p>Each repository also has local state. The local state determines the web-page formatting preferences, authorized users, ticket formats, and similar information that varies from one repository to another. -The local state is not transfered by the <b>push</b>, <b>pull</b>, -and <b>sync</b> command, though some local state is transfered during +The local state is not transferred by the <b>push</b>, <b>pull</b>, +and <b>sync</b> command, though some local state is transferred during a <b>clone</b> in order to initialize the local state of the new repository. The <b>configuration push</b> and <b>configuration pull</b> commands can be used to send or receive local state.</p> Index: www/wikitheory.wiki =================================================================== --- www/wikitheory.wiki +++ www/wikitheory.wiki @@ -8,11 +8,11 @@ * [./embeddeddoc.wiki | Embedded documentation] files whose name ends in "wiki". The [/wiki_rules | formatting rules] for fossil wiki are designed to be simple and intuitive. The idea is that wiki provides -paragraph breaks, numbered and bulletted lists, and hyperlinking for +paragraph breaks, numbered and bulleted lists, and hyperlinking for simple documents together with a safe subset of HTML for more complex formatting tasks. Some commentators feel that the use of HTML is a mistake and that fossil should use the markup language of the @@ -55,23 +55,23 @@ <h2>Embedded Documentation</h2> Files in the source tree that use the ".wiki" suffix can be accessed and displayed using special URLs to the fossil server. This allows project documentation to be stored in the source tree and accessed -online. (Details are descripted [./embeddeddoc.wiki | separately].) +online. (Details are described [./embeddeddoc.wiki | separately].) Some project prefer to store their documentation in wiki. There is nothing wrong with that. But other projects prefer to keep documentation as part of the source tree, so that it is versioned along with the source tree and so that only developers with check-in privileges can change it. Embedded documentation serves this latter purpose. Both forms of documentation use the exact same wiki markup language. Some projects may choose to use both forms of documentation at the same time. Because the same -format is used, it is trival to move file from wiki to embedded documentation +format is used, it is trivial to move file from wiki to embedded documentation or back again as the project evolves. <h2>Bug-reports and check-in comments</h2> The comments on check-ins and the text in the descriptions of bug reports both use wiki formatting. Exactly the same set of formatting rules apply. There is never a need to learn one formatting language for documentation and a different markup for bugs or for check-in comments. |