summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorLuke Shumaker <lukeshu@sbcglobal.net>2015-07-05 13:43:48 -0600
committerLuke Shumaker <lukeshu@sbcglobal.net>2015-07-05 13:43:48 -0600
commit5e9f055b19b4553462a809c0d1096b6ce0966910 (patch)
treeb1626db8fe0122d025b19e38ee382aa6d14ce774 /HACKING
parent504d11ded8c1e9a0757332f2a10ed7d86dd5fc70 (diff)
spell-check on HACKING and README
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING39
1 files changed, 20 insertions, 19 deletions
diff --git a/HACKING b/HACKING
index bceb3dd..8fe3733 100644
--- a/HACKING
+++ b/HACKING
@@ -1,7 +1,7 @@
#!/bin/less
- Version 0.8c reimplements the wrapper in C, to allow better
- cooperation betweem plugins via dependancies. This probably makes
+ Version 0.8c re-implements the wrapper in C, to allow better
+ cooperation between plugins via dependencies. This probably makes
a lot of this document out-dated, but a lot of it is still good, it
describes the workings of the plugins, and the repo structure.
@@ -23,23 +23,24 @@
build basics
- One of the coolest things about rvs (imo) is how modular and
- customizable it is. If you wish to create a fork of rvs, it wls ould
+ One of the coolest things about rvs (IMO) is how modular and
+ customizable it is. If you wish to create a fork of rvs, it would
be a good idea to give it a different name. This can be done
without even changing a single source file! Simply run configure
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 ath the code).
+ peek at the code).
Other options to configure and their default values are:
+
name='rvs'
The name of the program. Note that unlike most
variables, you should NOT call this in Makefiles
(`$(name)'), but use `$(rvs)' instead.
RVS='$(bindir)/$(rvs)'
- Where the exectuable will be. `$(rvs)' is the same as
+ Where the executable will be. `$(rvs)' is the same as
`$(name)' (see above). In this document it is
- sometimes reffered to as the `wrapper'.
+ sometimes referred to as the `wrapper'.
SHELL='/bin/sh'
The shell that will be used by make, and the shell
that scripts will run in. (Perhaps we should make
@@ -70,7 +71,7 @@
The configure script will run on any instance of `Makefile.in' in
$(srcdir).
- Currently, rvs is distributed with 2 pluggins. `repo'(sitory) is
+ 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 +93,7 @@
uninstall PLUGIN
Uninstalls PLUGIN. Did that really need to be said?
- A plugin is simply a collection of independant executable files.
+ 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
2) looks at the file `$(libexecdir)/$(rvs)/plugins'. This is a
@@ -118,13 +119,13 @@
The build system rvs uses is rather simple.
`./configure' does two things:
* create a sed script (`var.sed')
- * run every incance of `$(srcdir)/Makefile.in' through
- `var.sed' to generate a propper `Makefile'
+ * run every instance of `$(srcdir)/Makefile.in' through
+ `var.sed' to generate a proper `Makefile'
`var.sed' contains all configuration variables. When it processes
a file every instance of `@VAR_NAME@' is replaced by that
variable's value. This makes `configure' act much like a GNU
- package `congfigure'. Note that this replacement only happens for
+ package `configure'. Note that this replacement only happens for
defined variables.
Most of these can easily be changed _after_ `compilation' also:
@@ -162,7 +163,7 @@
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, licence
+ commit. The meta file contains author, copyright owner, license
data, file permissions, timestamps, etc. The id of the meta-file is
written to stdout, and used to later check out that commit.
@@ -170,7 +171,7 @@
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.
+ functions in the proper locations.
Any commit function should take a filename as an argument and
output the according commit id to stdout. stderr should be used
@@ -181,9 +182,9 @@
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:
+ should be used instead. I deliberately broke this because:
- 1. incompatible licences can be used for different modules
+ 1. incompatible licenses 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`$(libexecdir)/$(rvs)
@@ -220,7 +221,7 @@
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
+ committing 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
@@ -248,9 +249,9 @@
FILENAME=`tempfile`
The `files' directory is where all the data is kept.
- When any file is commited, whether it be a regular file, a
+ When any file is committed, 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
+ `.rvs/files', the "raw-file" and the "meta-file". When we speak 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;