summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
Diffstat (limited to 'README')
-rw-r--r--README150
1 files changed, 88 insertions, 62 deletions
diff --git a/README b/README
index 790d9f6..4349f61 100644
--- a/README
+++ b/README
@@ -1,70 +1,96 @@
//////////////////////////////////////////////////////////////////////
- rvs - retroactive versioning system
- versioning system that allows you to check
- in commit 2 before commit 1
+ rvs 0.6.1
+ retroactive versioning system
+ a versioning system that allows you to check
+ in commit 2 before commit 1
//////////////////////////////////////////////////////////////////////
-CONTENTS:
- 1 ) Introduction
- 2 ) Building
- 2.1 ) configuration
+introduction
-//////////////////////////////////////////////////////////////////////
-== 1: Introduction
-The name is a little bit of a nod to RCS (revision control system),
-and even less to CVS. I'm not particularly fond of CVS, but recognize
-it's impact on the scm scene.
-
-rvs is about being able to go back and edit *anything* that has
-already been committed. Yes, some other SCMs do this, but fuck things
-proper if someone else has a copy of the old version.
-
-Why would you want to do this? Take for example the Bazaar repository
-rvs is hosted on: It starts at 0.6.0, what if I later want to import
-0.0.0 - 0.5.10? Or if I'm trying to construct a history of BSD,
-and import all the BSDs I can find, such as 1,3,4, then latter find 2?
-
-== 2: Building
-rvs doesn't exactly use the GNU build system, but acts much like it
-does. To build rvs with default configuration, simply run:
- $ ./configure
- $ make
- # make install
-It's generally considered good practice to build in another directory
-than the source directory. This is not nescessary in rvs , all the
-created file are put in another directory anyway. If you would still
-like to do this, it can be done in rvs-0.6.1 and up.
-
-=== 2.1: Configuration
-There are several configuration variables that can be set. The default
-values are kept in the file `Variables'.
-
-Variables is in the format `VAR_NAME<tab>VALUE'. You can modify these
-configuration variables by editing the `Variables' file directly, or
-by running ./configure such as:
- $ ./configure --VAR_NAME=VALUE
-
-The different configuration variables are as follows:
-VER value='0.6.0'
- rvs's internal varsion number
-SHELL value='/usr/bin/env bash'
- the shell that scripts will be run in.
-prefix value="$HOME"
- where the files will be installed. For me the defualt is
- `/home/luke'. Many of you will want to change this to '/usr'
-bindir value='bin'
- the binaries folder inside the prefix. If I leave the prefix
- and bindir the same, for me rvs is installed in
- `/home/luke/bin'. If I change prefix to '/usr', then rvs will
- be installed in `/usr/bin'
-libdir value='/etc/rvs/'
- where the rvs libraries will be installed.
- in rvs almost nothing is actually done int the core binary
- ([$prefix]/[$bindir]/rvs) but option handling. All the real
- work is done in modular sub-programs. I call them libraries,
- even though they are independend programs that communicate via
- pipes.
+ The name is a little bit of a nod to RCS (revision control
+ system), and even less to CVS. I'm not particularly fond of CVS,
+ but recognize it's impact on the scm scene.
+
+ rvs is about being able to go back and edit *anything* that has
+ already been committed. Yes, some other SCMs do this, but fuck
+ things proper if someone else has a copy of the old version.
+
+ Why would you want to do this? Take for example the Bazaar
+ repository rvs is hosted on: It starts at 0.6.0, what if I later
+ want to import 0.0.0 - 0.5.10? Or if I'm trying to construct a
+ history of BSD, and import all the BSDs I can find, such as
+ 1,3,4, then latter find 2?
+
+system requirements
+
+ Pretty much any *nix system should be able to run rvs. If you
+ need to use a shell other than GNU bash, run ./configure with
+ the --SHELL=YOUR_SHELL option. rvs is not designed for Windows,
+ but should be able to run in bash if you have some *nix pack
+ installed.
+
+ To my knowledge, this is the absolute requirements (all need to
+ be in your PATH):
+ * GNU bash
+ * cat (included in GNU Core Utils)
+ * cp (included in GNU Core Utils)
+ * cut (included in GNU Core Utils)
+ * echo (included in GNU Core Utils)
+ * mkdir (included in GNU Core Utils)
+ * rm (included in GNU Core Utils)
+ * sed (included in GNU Core Utils)
+ * sha1sum (included in GNU Core Utils)
+ * tempfile (included in GNU Core Utils)
+ * tr (included in GNU Core Utils)
+
+building
+
+ rvs doesn't exactly use the GNU build system, but acts much like
+ it does. To build rvs with default configuration, simply run:
+ $ ./configure
+ $ make
+ # make install
+
+ It's generally considered good practice to build in another
+ directory than the source directory. This is not nescessary in
+ rvs , all the created file are put in another directory anyway.
+ If you would still like to do this, it can be done in rvs-0.6.1
+ and up.
+
+ Configuration
+
+ There are several configuration variables that can be set. The
+ default values are kept in the file `Variables'.
+
+ Variables is in the format `VAR_NAME<tab>VALUE'. You can modify
+ these configuration variables by editing the `Variables' file
+ directly, or by running ./configure such as:
+ $ ./configure --VAR_NAME=VALUE
+
+ The different configuration variables are as follows:
+ VER value='0.6.0'
+ rvs's internal varsion number
+ SHELL value='/usr/bin/env bash'
+ the shell that scripts will be run in.
+ prefix value="$HOME"
+ where the files will be installed. For me the defualt is
+ `/home/luke'. Many of you will want to change this to '/usr'
+ bindir value='bin'
+ the binaries folder inside the prefix. If I leave the prefix
+ and bindir the same, for me rvs is installed in
+ `/home/luke/bin'. If I change prefix to '/usr', then rvs will
+ be installed in `/usr/bin'
+ libdir value='/etc/rvs/'
+ where the rvs libraries will be installed. In rvs almost
+ nothing is actually done in the execurable you call when you
+ type `rvs' ([$prefix]/[$bindir]/rvs) but option handling. All
+ the real work is done in modular sub-programs. I call them
+ libraries, even though they are independend programs that
+ communicate via pipes. Note that they probably should NOT be
+ located in your PATH.
~ Luke Shumaker <LukeShu@sbcglobal.net>
Happy Hacking!
+([$prefix]/[$bindir]/rvs) but option handling.
+