1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
//////////////////////////////////////////////////////////////////////
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!
|
