Point is, whatever approach you use, do not use version control as a backup, and an 'automated' backup as version control. Two different things. Just my 2 cents.
Agreed. Although ...
Devil's advocate mode what's the worst that could happen? No seriously, what is the worst thing that could happen if you use version control as backup, and automated archives as version control?
With that said, considering version control, whatever you use for this, is a good step. Many "lone" developers build a bad habit of NOT tracking changes for what they develop. They just add features, fix bugs, and move on, considering that the last version will always be the best one anyway. So starting to keep track of changes is certainly a good thing. You can start with something as simple as Changelog text file listing the changes from one version/revision to the next.
Guilty as charged, especially in the past.
Typically it would go something like
"Mmmh, I wonder if this would work..." followed by a bunch of small scripts/experiments, finding/reading/misplacing papers, making some notes, and before you know it you have a collection of
stuff that really could do with some version control. Especially since this kind of experiment more often than not either fizzles, gets interrupted, or runs into a roadblock. So it can be on the backburner for days, months, sometimes even years... Lets just say that I have never had a regret of this form:
"Gee, this repo sure is useless. Eating up all this precious diskspace. I sure wish I never created a repository for this." On the other hand the
"#^%@!! why didn't I just create a repo for this EARLIER?" variety has been known to happen every now and then.
As for the original question, yet another git user here. Fairly typical path taken: CVS -> SVN -> GIT for the most part, with some mercurial here and there. For new projects preference is git, but mercurial is fine too. Subversion is a most definite
maaaaaybe, and CVS is a hard pass.