this is a great question and I actually reviewed this terminology in my book on CM Best Practices. Years ago there was really very little difference between configuration control and version control. This goes back to when we selected the versions of Cobol programs, copybooks etc for a release. Back then we referred to a baseline of the code as a configuration and, in some sense, it actually was. The technology has changed and the terminology has also evolved.
Configuration control now really refers to setting runtime dependencies and we often discuss "configuring" an application to run. An example would be a JMX control or even more basic - specifying whether you are accessing a QA/UAT or production database. There are lots of jobs out there where you focus on configuration management in the sense of configuring a package to run (actually customizing the runtime experience). This is often done through XML or properties files such as an application server (e.g. WebSphere).
Version control refers to checking in and storing specific versions of the source code and now there is a real difference between configuration control and version control. Years ago the terms were used almost interchangeably although back then (around the 80s and early 90s) we didn't have too many real version control tools. On mainframes we had Panvalet and I think that CA Librarian came soon after.
How about the rest of your CM Historians! What say you?
Bob Aiello
Technical Editor, CM Crossroads
http://www.linkedin.com/in/BobAiello
Another difference I'd like to mention is third party libraries, and other similar packages, utilized by Development to ccreate their products. Yes, these are virsioned, yet by their versioning, they can cause changes in configurations in order to use them.
Someone needs to keep track of the tools and packages in use, as well as track upgrades to these as they may (and usually do) have an impact on how a given application is built, thus also causing possible changes in the underlying service assets.