//////////////////////////////////////////////////////////////////////
                               rvs 0.6.1
	retroactive versioning system
	          a versioning system that allows you to check
	            in commit 2 before commit 1
//////////////////////////////////////////////////////////////////////

                              hacking

   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
   executables that do all the real work.

  build system

   The build system rvs uses is rather simple.
   `./configure' does two things:
   	* create a preprocessor (`tmp/var.sed')
   	* run `Makefile.orig' through the preprocessor to generate a
   	  propper `Makefile'
   Then, the Makefile runs each file in `source/' through the
   preprocessor, and writes the resulting files to `out/'.

   preprocessor

    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.

  configuration Variables

   Again the configuration variables and their default values are:
   	VER   	'0.6.1'
   	SHELL 	'/usr/bin/env bash'
   	prefix	"$HOME"
   	bindir	'bin'
   	libdir	'/etc/rvs/'

   The wrapper is installed at `$$prefix$$/$$bindir$$/rvs'
   The  core   is installed at `$$libdir$$/'
   The source for the wrapper is in `source/rvs'
   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.1 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
   	prefix	simply move the wrapper
   	bindir	simply move the wrapper
   	libdir	move the core, then update the line `RVSDIR=...' in
   	      	the wrapper
   
   I have designed this system to be extremely modular. As you may
   have figured out, each bit on functionality is in it's own
   executable, and the file you call when you type `rvs' is just a
   wrapper for them.

   The wrapper is quite simple in mechanism. It simply checks if
   `$$libdir$$/COMMAND_NAME' exists, and if so, runs that file.
   
   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:
   
   	block       (buffered) special b
   	character (unbuffered) special c
   	directory                      d
   	named pipe (FIFO)              p
   	regular file                   f
   	symbolic link                  l
   	socket                         s
   	door (Solaris only)            D

   As you probably noticed (if you've looked at the blueprints or
   source files), only directories and regular files have been
   implemented as of rvs 0.6.1.
   
   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

   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'.
   
   If you implement any other file types, save the commit and get
   functions in the propper locations.

     Any commit function should take a  filename   as an argument and
     output the according commit id to stdout.

     Any  get   function should take the commit id as an argument and
     uses stdout only if verbose, or to report errors.

   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:

    1. incompatible licences 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

   I have set up bazaar repository at Launchpad:
   	https://launchpad.net/rvs
   Only until rvs becomes self-hosting.

   If anyone needs any help, let me know, either via email, or via
   Launchpad, I'll be happy to help!

~ Luke Shumaker <LukeShu@sbcglobal.net>
Happy Hacking!