////////////////////////////////////////////////////////////////////// rvs 0.6.3 retroactive versioning system a versioning system that allows you to check in commit 2 before commit 1 ////////////////////////////////////////////////////////////////////// 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 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 (be sure to read the `configuration' section of `README' first) 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.3' 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.3 all executables are shell scripts. Most of these can easily be changed _after_ compilation also: VER line 4 of the wrapper SHELL line 1 of 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.3. 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. stderr should be used for all messages. 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 $$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 using the code: source "`rvs -d`/lib/stdio" or source "`rvs -d`/lib/rvsdb" (`rvs -d' returns $$libdir$$) stdio provides several functions for printing messages: verbose MESSAGE print MESSAGE to stdout only if $verbose is set to '-v' out MESSAGE print MESSAGE to stdout if $verbose isn't set to '-q' warn MESSAGE print "rvs: MESSAGE" to stderr error MESSAGE print "rvs: MESSAGE" and a quick message about `rvs --help' (hinting at user error) to stderr, then exit with error fatal MESSAGE For internal error. Print "rvs: MESSAGE" to stderr and exit with error version print the version information and exit with success rvsdb provides several functions and variables for dealing with the rvs database: $repo the directory of the database (./.rvs) getid FILE returns what the id of a given file would be if it were in the database. This is used to know where to put files when commiting them. In 0.5.8-0.6.3 this is just the sha1sum of the file NOTE: the "log*" functions aren't very stable or developed loginit FILE initialize an rvs log at FILE. These logs are used for metafiles, directory listings, and (probably) eventually checkout logs lograw LOG prepare LOG for reading, and write the output to stdout (to pipe into another function). This is mostly for internal use by rvsdb logread LOG VAR read variable VAR from the logfile LOG logwrite LOG VAR VAL set variable VAR to VAL in the logfile LOG logfind LOG VAL return all the names of variables in logfile LOG who have the value VAL the database (.rvs/*) So, what are all these files doing in in the database? The scheme is fairly simple. In the `.rvs' directory there is 1 directory, the `files' directory. There used to be a folder for tempfiles (0.5.8- 0.6.2), but no more (0.6.3+). If you need a tempfile, just run: FILENAME=`tempfile` The `files' directory is where all the data is kept. When any file is commited, whether it be a regular file, a directory, a link, or any other type of file, 2 file are created in `.rvs/files', the "raw-file" and the "meta-file". When we speek of file IDs, we mean the filename of the corresponding file in `.rvs/files' in rvs 0.5.8-0.6.3 this is just the sha1sum of the file. The meta-file stores everything not part of the file itself; the filename, file-type, author, copyright owner, file permissions, timestamps, etc, and the ID of the corresponding raw-file. In the 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. final thoughts 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 Happy Hacking!