If you don't already have the requirement of a ticket for each change, then getting developers to create a ticket for each change important enough to end up in the change log seems reasonable.
If the change is significant enough to tell users about, then you probably want to be making that change under a ticket anyway, and writing descriptive tickets is good practise. Plus you can tie this in with whatever release versioning and roadmap support your bug tracker has.
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
As noted,
svn logwill get you this answer. But this really isn't suitable for time tracking -- just about all accounting systems need a hole for restatement, editing a svn commit description can be tricky if not impossible due to post-commit hooks.You might want to look at something like redmine which integrates with SVN and has a time tracking feature built-in.