(Regarding this thread.)
Get the book, and don't go past Chapters 1 and 2 at first (technically, you may want to hit the first part of Chapter 5 long enough to convince yourself that you should use fsfs as the repository backend format). Gloss over anything involving resolving conflicts, merges, branches or anything else involving multiple people.
Once you're done for the day, rsync or copy your repository off to another disk or system.
Consider setting up ViewVC if you want pretty graphs and charts of what changed when. It's not the only option in that field, though.
I understand your pain. I do version control in fits and starts on two major areas of work: the configuration management directory tree for my servers, and for LaTeX templates for my university's thesis/dissertation formats. Nobody else has write access to these areas, but knowing I can go back and track changes on a basis as fine-grained as my commit schedule is nice. I haven't really used it all on any other areas of work. And getting others to use it on multi-developer code projects has been like pulling teeth. I'm about ready to swear off supporting any code that can't be tracked, but I doubt I'll be able to.