[etc] RCS (Revision Control System) for smaller personal projects.

Use CVS for large systems.
RCS
Any development work is an incremental process, particularly so at the
debugging stage. It always pays to keep a record of the process using some
form of revision control system, so that a bad change can backed out with
minimal effort. A very basic revision control system can be implemented by
just keeping a backup of a file before making major changes, however this
approach tends to become cumbersome and inefficient very quickly.

Enter RCS, the little brother of CVS. CVS is great for large projects with
many contributors, but is overkill for small personal projects. One of the
attractions of RCS is it's simplicity.

First create the RCS directory in the same directory as your source files:

mkdir RCS

Then "check in" a source file:

ci -u some-file.c

You will then be prompted to give a description. By default, RCS deletes the
working file upon check in, so you will want the -u option which
automatically checks the file out again. Check in all the files you are
working on in this way.

Make some changes to one of your source files and check it in again. You'll
be prompted for a summary of the changes and the version number will be
incremented.

Suppose you have made a mess of the working file and want to revert to a
known good version (1.7), check it out using this command:

co -l -r1.7 some-file.c

The -l flag locks the file and gives you write access to it (otherwise you
get read access only).

RCS stores the initial file and only differences between versions, saving
disk space. For more information on RCS, see the following man pages: rcs,
ci, co, rcsintro, rcsdiff, rcsclean, rcsmerge, rlog, rcsfile and ident.