spell-check on HACKING and README

1 files changed, 20 insertions, 19 deletions

diff --git a/HACKING b/HACKING
index bceb3dd..8fe3733 100644
--- a/HACKING
+++ b/HACKING
@@ -1,7 +1,7 @@
 #!/bin/less
 
-   Version 0.8c reimplements the wrapper in C, to allow better
-   cooperation betweem plugins via dependancies.  This probably makes
+   Version 0.8c re-implements the wrapper in C, to allow better
+   cooperation between plugins via dependencies.  This probably makes
    a lot of this document out-dated, but a lot of it is still good, it
    describes the workings of the plugins, and the repo structure.
 
@@ -23,23 +23,24 @@
 
   build basics
 
-   One of the coolest things about rvs (imo) is how modular and
-   customizable it is.  If you wish to create a fork of rvs, it wls ould
+   One of the coolest things about rvs (IMO) is how modular and
+   customizable it is.  If you wish to create a fork of rvs, it would
    be a good idea to give it a different name.  This can be done
    without even changing a single source file!  Simply run configure
    with `--name=NAME' option (variables that have `rvs' in the name
    will not be renamed, but the user will never know this unless they
-   peek ath the code).
+   peek at the code).
    
    Other options to configure and their default values are:
+
    	name='rvs'
    		The name of the program. Note that unlike most
    		variables, you should NOT call this in Makefiles
    		(`$(name)'), but use `$(rvs)' instead.
    	RVS='$(bindir)/$(rvs)'
-   		Where the exectuable will be. `$(rvs)' is the same as
+   		Where the executable will be. `$(rvs)' is the same as
    		`$(name)' (see above). In this document it is
-   		sometimes reffered to as the `wrapper'.
+   		sometimes referred to as the `wrapper'.
    	SHELL='/bin/sh'
    		The shell that will be used by make, and the shell
    		that scripts will run in. (Perhaps we should make
@@ -70,7 +71,7 @@
    The configure script will run on any instance of `Makefile.in' in
    $(srcdir).
    
-   Currently, rvs is distributed with 2 pluggins. `repo'(sitory) is
+   Currently, rvs is distributed with 2 plugins. `repo'[sitory] is
    the core of the rvs file database. `users' handles all usernames,
    settings, and other info.
 
@@ -92,7 +93,7 @@
       uninstall PLUGIN
       	Uninstalls PLUGIN. Did that really need to be said?
    
-   A plugin is simply a collection of independant executable files.
+   A plugin is simply a collection of independent executable files.
    When rvs is invoked, it looks for the COMMAND in a few places:
      1) checks if COMMAND is an built-in command
      2) looks at the file `$(libexecdir)/$(rvs)/plugins'. This is a
@@ -118,13 +119,13 @@
    The build system rvs uses is rather simple.
    `./configure' does two things:
    	* create a sed script (`var.sed')
-   	* run every incance of `$(srcdir)/Makefile.in' through
-   	  `var.sed' to generate a propper `Makefile'
+   	* run every instance of `$(srcdir)/Makefile.in' through
+   	  `var.sed' to generate a proper `Makefile'
 
     `var.sed' contains all configuration variables. When it processes
     a file every instance of `@VAR_NAME@' is replaced by that
     variable's value. This makes `configure' act much like a GNU
-    package `congfigure'. Note that this replacement only happens for
+    package `configure'. Note that this replacement only happens for
     defined variables.
 
    Most of these can easily be changed _after_ `compilation' also:
@@ -162,7 +163,7 @@
    implemented as of rvs 0.7.0.
    
    After `rvs commit' has done this, it creates a meta-file for that
-   commit. The meta file contains author, copyright owner, licence
+   commit. The meta file contains author, copyright owner, license
    data, file permissions, timestamps, etc. The id of the meta-file is
    written to stdout, and used to later check out that commit.
 
@@ -170,7 +171,7 @@
    type from the meta-file, then runs `rvs get.FILE_CODE COMMIT_ID'.
    
    If you implement any other file types, save the commit and get
-   functions in the propper locations.
+   functions in the proper locations.
 
      Any commit function should take a  filename   as an argument and
      output the according commit id to stdout. stderr should be used
@@ -181,9 +182,9 @@
 
    To summarize, the modules are separate programs and communicate via
    pipes, which is generally considered bad-design, and libraries
-   should be used instead. I deliberatly broke this because:
+   should be used instead. I deliberately broke this because:
 
-    1. incompatible licences can be used for different modules
+    1. incompatible licenses can be used for different modules
     2. modules can be added/removed on the fly
     3. one can use any language to write new modules, without
        having to worry about bindings`$(libexecdir)/$(rvs)
@@ -220,7 +221,7 @@
    	getid FILE
    	   returns what the id of a given file would be if it were in
    	   the database. This is used to know where to put files when
-   	   commiting them. In 0.5.8-0.6.3 this is just the sha1sum of
+   	   committing them. In 0.5.8-0.6.3 this is just the sha1sum of
    	   the file
    	NOTE: the "log*" functions aren't very stable or developed
    	loginit FILE
@@ -248,9 +249,9 @@
    	FILENAME=`tempfile`
    The `files' directory is where all the data is kept.
    
-   When any file is commited, whether it be a regular file, a
+   When any file is committed, whether it be a regular file, a
    directory, a link, or any other type of file, 2 file are created in
-   `.rvs/files', the "raw-file" and the "meta-file". When we speek of
+   `.rvs/files', the "raw-file" and the "meta-file". When we speak of
    file IDs, we mean the filename of the corresponding file in
    `.rvs/files' in rvs 0.5.8-0.6.3 this is just the sha1sum of the
    file. The meta-file stores everything not part of the file itself;