run all source files through sed to update all changes in design.

fix the few things the sed script didn't count on (init.sh mostly)
remove code for back-compat with unupdated parts
update HACKING file with some (but not all design changes)

1 files changed, 23 insertions, 25 deletions

diff --git a/HACKING b/HACKING
index 6571868..ed08289 100644
--- a/HACKING
+++ b/HACKING
@@ -5,7 +5,7 @@
 	            in commit 2 before commit 1
 //////////////////////////////////////////////////////////////////////
 
-   I know this file is long* and boring.  I try to keep it preened and
+   I know this file is long* and boring. I try to keep it preened and
    informative, but would rather spend my time actually hacking. If
    you think you can help this file, have at it! ~ Luke Shumaker
    
@@ -13,9 +13,9 @@
 
                               hacking
 
-   There are two main parts to rvs, the wrapper, and the core.  The
+   There are two main parts to rvs, the wrapper, and the core. The
    wrapper is a small executable, located in the PATH, and is the one
-   called when you type `rvs'.  The core is a set of many small
+   called when you type `rvs'. The core is a set of many small
    executables that do all the real work.
 
   build system
@@ -31,7 +31,7 @@
 
    preprocessor
 
-    The preprocessor contains all configuration variables.  When it
+    The preprocessor contains all configuration variables. When it
     processes a file every instance of `$$VAR_NAME$$' is replaced by
     that variable's value. Note that this replacement only happens for
     defined variables.
@@ -51,11 +51,11 @@
    The source for the  core   is in `source/rvs-core/'
 
     $$SHELL$$ is the shell all shell scripts that are part of rvs are
-    run in.  As of rvs 0.6.3 all executables are shell scripts. 
+    run in. As of rvs 0.6.3 all executables are shell scripts. 
 
    Most of these can easily be changed _after_ compilation also:
    	VER  	line 4 of the wrapper
-   	SHELL	line 1 each shell script
+   	SHELL	line 1 of each shell script
    	prefix	simply move the wrapper
    	bindir	simply move the wrapper
    	libdir	move the core, then update the line `RVSDIR=...' in
@@ -71,8 +71,8 @@
    
    The `rvs commit' command is also quite simple in design. It takes a
    single argument; the file to commit. If no target is specified, it
-   defaults to `./'.  It checks which type of file the target is, and
-   runs `rvs commit.FILE_CODE TARGET'.  The file codes are as follows:
+   defaults to `./'. It checks which type of file the target is, and
+   runs `rvs commit.FILE_CODE TARGET'. The file codes are as follows:
    
    	block       (buffered) special b
    	character (unbuffered) special c
@@ -88,9 +88,9 @@
    implemented as of rvs 0.6.3.
    
    After `rvs commit' has done this, it creates a meta-file for that
-   commit.  The meta file contains author, copyright owner, licence
-   data, file permissions, timestamps, etc.  The id of the meta-file
-   is written to stdout, and used to later check out that commit
+   commit. The meta file contains author, copyright owner, licence
+   data, file permissions, timestamps, etc. The id of the meta-file is
+   written to stdout, and used to later check out that commit.
 
    get works in much the same way as commit, only it reads the file
    type from the meta-file, then runs `rvs get.FILE_CODE COMMIT_ID'.
@@ -99,7 +99,7 @@
    functions in the propper locations.
 
      Any commit function should take a  filename   as an argument and
-     output the according commit id to stdout.  stderr should be used
+     output the according commit id to stdout. stderr should be used
      for all messages.
 
      Any  get   function should take the commit id as an argument and
@@ -118,7 +118,7 @@
    THIS WAS WRITTEN FOR rvs 0.6.2
    THIS PORTION OF THE CODE IS BEING REVISED IN rvs 0.6.3
 
-   I have created two 'libraries' for use by rvs components.  They
+   I have created two 'libraries' for use by rvs components. They
    provide several functions that can be accessed by shell script by 
    using the code:
    	source "`rvs -d`/lib/stdio"
@@ -147,17 +147,17 @@
    	   the directory of the database (./.rvs)
    	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
+   	   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
    	   the file
    	NOTE: the "log*" functions aren't very stable or developed
    	loginit FILE
-   	   initialize an rvs log at FILE.  These logs are used for
+   	   initialize an rvs log at FILE. These logs are used for
    	   metafiles, directory listings, and (probably) eventually
    	   checkout logs
    	lograw LOG
    	   prepare LOG for reading, and write the output to stdout (to
-   	   pipe into another function).  This is mostly for internal
+   	   pipe into another function). This is mostly for internal
    	   use by rvsdb
    	logread LOG VAR
    	   read variable VAR from the logfile LOG
@@ -170,11 +170,9 @@
   the database (.rvs/*)
 
    So, what are all these files doing in in the database? The scheme
-   is fairly simple. In the `.rvs' directory there are 2 directories,
-   the `files' directory, and the `tmp' directory. `tmp' is what it
-   sounds like, a place for rvs compnents to keep temporary files.
-   The wrapper sets TMPDIR, so you can create a unique file in there
-   with:
+   is fairly simple. In the `.rvs' directory there is 1 directory, the
+   `files' directory. There used to be a folder for tempfiles (0.5.8-
+   0.6.2), but no more (0.6.3+). If you need a tempfile, just run:
    	FILENAME=`tempfile`
    The `files' directory is where all the data is kept.
    
@@ -192,9 +190,9 @@
    
    $$libdir$$/commit calls $$libdir$$/commit.FILETYPE to generate the
    raw-file, but generates the meta-file itself (in `.rvs/tmp', then
-   calls commit.f to commit the meta-file).  It then returns the ID
-   of the meta-file.  Therefore, the user never deals with the IDs of
-   raw-files, and doesn't need to.  The metafiles contain pointers to
+   calls commit.f to commit the meta-file). It then returns the ID of
+   the meta-file. Therefore, the user never deals with the IDs of
+   raw-files, and doesn't need to. The metafiles contain pointers to
    the corresponding raw-files.
    
    To keep things modular, commit.f is the ONLY thing that should