I keep copies of each older release, and also a changelog of what was done for each new release. Plus, anything which is non-obvious as to its purpose (eg. a change to my emulator which is needed for compatibility with some obscure guest program) has a comment to that effect in the source. Those three measures have proven adequate for me. Plus, last time I checked, these revision control systems seem to require use of a makefile. YMMV; I'm not saying that revision control is useless for everyone, but if your coding is done in a disciplined way it's not necessary.
That certainly can work, but it may not always work. Some 25 years go I could literally remember everything that went on in a program, its configuration files, it data files, what all the constants meant and how they were used.
Nowadays there's not so much of the old zing around (maybe the programs became bigger, maybe the tools got better), and I have become too lazy to do manually what a script, a program, a tool could do automatically for me.
Maintaining a change log is necessary, and it is very convenient to maintain it through subversion (SVN) commit messages, which lateron get folded into a release log file. The subversion repository keeps track of my file changes, the change log data that describes the changes, and it contains the release log file, too.
If need be, I can use the subversion repository to roll back changes I made (undo), and I can go back to old releases for review. All of that can be done by reviewing archived changes, stored in individual files (which clutter up the directory), but with a revision control system you just tell it to retrieve the file change history and you're able to review each small change you made and committed.
If you change one character in a file you can commit the change and it won't eat up a lot of disk space (revision control systems store differences between subsequent revisions), but you probably wouldn't store a full backup copy of that file for later reference.
The subversion command does work which I need to do anyway, and it allows me to spend far less time on it than doing it manually would. There are positive side-effects as well.
Revision control systems such as the old RCS, CVS and SVN do not need a makefile. It's possible that the makefile contains rules for invoking these programs, but these are just icing on the cake. You could invoke these commands manually and it would not change a thing.
What is needed is a place to store the revision information, etc. Both the old RCS, CVS and even subversion allow you to keep the data in a local directory on your computer. Storing that data on a separate system, where it can be safe from data corruption or loss may be a more appropriate solution though.
Once you commit to using a revision control system and clear the first hurdle in setting up a repository, it can become second nature to use it for every project you work on, no matter how small. If you consider each small project in isolation, then setting up the repository may look like unnecessary, unwarranted effort. But if you do start using it, then every project, no matter how small, can benefit from having it around.