To use commit history for more than "made changes" or "fixed bug" type comments, it should be linked with your issue tracking system. Every change, every commit, should have some issue associated with it so you know what changed, by whom, and why.
As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?
Sufficiently complex software rarely has all requirements implemented and all bugs fixed for a multitude of reasons, so I think your assertion here is, let's say, optimistic.
Suppose you are on version 7.8 of your program. But you are supporting, in the field, 12 different active versions, like 1.6, 2.2, 2.8, and so on. Each of these aren't going to be upgraded to the latest version for a variety of reasons, so you are supporting all with bug fixes. A customer finds a bug in your latest 7.8 release. You fix it in 7.8. How do you know how many of the other releases need to be fixed? Without source history and issue tracking you don't.
Don't ask him. Don't tell him. Show him.
Install svn, or git, or whatever you like on some extra machine. Practice using it yourself until you feel comfortable not just using it, but explaining it. If you're going to make him comfortable with your new system, you'll need to be more than comfortable with it yourself. You'll need to be able to help him recover easily when he screws up a merge or checks something into the wrong place.
When you're ready, show him exactly what you're talking about. Show him that it doesn't "make a mess" of anything. Point out that it doesn't just let you retrieve any previous version of your code with ease, it also makes it possible to know exactly what changed between any two versions.
Point out that if anything ever happens to the server (serious bug, virus, hacker, disk crash...) you'll both look like heros if you can instantly reconstruct the necessary version. Point out, too, that you'll look twice as good if you're able to produce any version on demand. Search your old e-mail and compile a list of problems you've had over the past year that you could have avoided with version control.
Give him a cheat sheet that will make it easy for him to use your version control system.
Finally, suggest some options but leave the decision to him. Should you set up your own server, or use one of the many hosted services? Should you use svn, git, or something else? Should you migrate all seven projects to the system, or try it with one or two at first?
Best Answer
Why choose ? It should be both.
Your development environment should be configured so it's as easy as doing a checkout, open, build, run, debug (eg: no absolute path!). You can do that easily with compilation directives, configuration class + dependancy injection, or even tricks like the perso.config in ASP.NET
Your automated build script should be customized enought to take care of specific production configuration, clean up, packaging etc.