whitespace

1 files changed, 26 insertions, 27 deletions

diff --git a/HACKING b/HACKING
index 968e685..773d247 100644
--- a/HACKING
+++ b/HACKING
@@ -8,10 +8,10 @@
    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
-   
+
    * at 200+ lines, it's longer than any rvs source file
 
-- - -cut-here- - 8< - - - - - - - - - - - - - - - - - - - - - - - - - 
+- - -cut-here- - 8< - - - - - - - - - - - - - - - - - - - - - - - - -
 //////////////////////////////////////////////////////////////////////
                                rvs 0.7.0
 	retroactive versioning system
@@ -30,7 +30,7 @@
    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 at the code).
-   
+
    Other options to configure and their default values are:
 
    	name='rvs'
@@ -60,17 +60,17 @@
    	srcdir=$(readlink -f `dirname "$0"`)
    		Where the source code is.  The default value evaluates
    		to the directory of the `configure' script.
-   
+
    These can either be changed by manually changing `configure' or by
    running it like:
    	./configure --VAR_NAME=VALUE
-   
+
    In this document, the `$(VAR_NAME)' refers to whatever you set the
    value to.
-   
+
    The configure script will run on any instance of `Makefile.in' in
    $(srcdir).
-   
+
    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 +92,7 @@
       	have lowest priority (see `$(libexecdir)/$(rvs)/plugins').
       uninstall PLUGIN
       	Uninstalls PLUGIN. Did that really need to be said?
-   
+
    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
@@ -103,15 +103,14 @@
         `$(libexecdir)/$(rvs)/plugins', in the order they appear in
         the file.
      4) if rvs does not find the command, it reports an error
-   
-   
+
    If you would like to contribute a plugin, or distribute one with a
    fork, all you have to do is put it in `$(srcdir)/plugins/NAME'. The
    main Makefile will recognize any directory in `$(srcdir)/plugins/'
    as a plugin, and will run `make -C `plugins/NAME/Makefile'. It
    should create a directory (mine use `plugins/NAME/out') to put ALL,
-   and ONLY the final files to be used by that plugin. 
-   
+   and ONLY the final files to be used by that plugin.
+
 ========this is outdated but I don't really want to keep editing it ==
 
   build system
@@ -134,8 +133,8 @@
    	prefix    	simply move the wrapper
    	bindir    	simply move the wrapper
    	libexecdir	move the directory, then update the line
-   	           	`RVSDIR=...' in the wrapper
-   
+   	          	`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
@@ -143,12 +142,12 @@
 
    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
@@ -161,7 +160,7 @@
    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.7.0.
-   
+
    After `rvs commit' has done this, it creates a meta-file for that
    commit. The meta file contains author, copyright owner, license
    data, file permissions, timestamps, etc. The id of the meta-file is
@@ -169,7 +168,7 @@
 
    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 proper locations.
 
@@ -190,11 +189,12 @@
        having to worry about bindings`$(libexecdir)/$(rvs)
 
   $$libdir$$/lib/
+
    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
-   provide several functions that can be accessed by shell script by 
+   provide several functions that can be accessed by shell script by
    using the code:
    	source "`rvs -d`/lib/stdio"
    or
@@ -215,7 +215,7 @@
    	   with error
    	version
    	   print the version information and exit with success
-   
+
    rvsdb provides several functions and variables for dealing with the
    rvs database:
    	getid FILE
@@ -241,14 +241,14 @@
    	   the value VAL
 
   the database (.rvs/*)
-  
+
    So, what are all these files doing in this database? The scheme is
    fairly simple. In the `.rvs' directory there is 1 directory, the
    `files' directory. There used to be a folder for tmpfiles (0.5.8-
    0.6.2), but no more (0.6.3+). If you need a tmpfile, just run:
    	FILENAME=$(mktemp -t)
    The `files' directory is where all the data is kept.
-   
+
    When any file is committed, whether it be a regular file, a
    directory, a link, or any other type of file, 2 files are created
    in `.rvs/files', the "raw-file" and the "meta-file". When we speak
@@ -260,29 +260,28 @@
    case of an regular file, the raw-file contains the file itself. For
    directories, it contains pointers to each file inside the
    directory.
-   
+
    $$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
    the corresponding raw-files.
-   
+
    To keep things modular, commit.f is the ONLY thing that should
    actually put files in `.rvs/files', and get.f the only thing that
    should get them. Everything else should call them.
-   
+
    The repo and init are the ONLY things that should have `.rvs'
    hardcoded into them. If the repository directory is needed, then
    use `rvs repo'. Again, in the core, these should only be the .f
    functions, however, it will be useful to plugins.
-   
+
    Why do we have the `files' directory, why don't we just put
    everything in `.rvs'? This way:
     * There is a spot to put user data, when we get around to writing
       it
 
-
   final thoughts
 
    I have set up bazaar repository at Launchpad: