summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorLuke Shumaker <lukeshu@sbcglobal.net>2015-07-09 18:53:23 -0600
committerLuke Shumaker <lukeshu@sbcglobal.net>2015-07-09 18:53:23 -0600
commit4fae29531c16df28685ca0530fbc0162b7882cff (patch)
treeb838d208af69475f68e1bba212433f5f85b2d005 /HACKING
parent1c2efabda503cc1b668b492ff553f18179cdb429 (diff)
whitespace
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING53
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: