Re: Why use a revision control system?
If there's something broken, one would restore from tape (or at least, restore the offending file from a tape).
Hahaha. No.
The reason why this is wrong is nicely illustrated by the following hypothetical situation:
You get in at 8am and find there is some urgent configuration work to do and your cient needs it all working by the end of the day. The changes aren't simple, and after making and testing several revisions, you're finally ready to go at 4:30 pm. You're just about to run your scripts, and you discover that you've accidentally deleted the folder they are in because windows explorer had the focus when you thought you were hitting the Delete key in a Word document (because you are documenting everything, and you are working over a laggy connection to a VM in another office). Do you:
a) Restore from a tape backup and repeat 8.5 hours work. This will take 24 hours to retrieve the backup tape from the secure off-site storage, followed by 3 hours to verify, find and restore the file in question. Or it will do, once you have got management authorisation to make a request to have the tape retrieved. Lets hope the backup compelted succesfully, eh?
b) Retrieve the last good version of your script from version control and reapply the last 0.5 hours of work.
Tape backups and version control systems are different tools, for different jobs, and both have their places. I wouldn't use a git repository for database backups, and I wouldn't use tape for version control.