ソースコードなどのプロジェクトの成果物を管理する手段として、バージョン管理とかソフトウェア構成管理と言うものがありますが、この２つの違いというのは意外と知られていないものです。
というか、厳密な定義がないに等しく（各書（各所）によって同じ言葉を異なった意味合いで用いていることがあるため）非常に紛らわしかったりします。
ここでは、一般的だと（私の主観で...）思う定義（をさらに簡略化して）にて、整理したいと思います：
バージョン管理（Version Control）：
ソースコードなどのファイルを「いつ、誰が、なんのために、なにを、どのように」改訂したのかを版（リビジョンやバージョン）として記録し、構成の把握などに役立てること。ソフトウェア構成管理（Software Configuration Management）：
プロジェクトの成果物の構成を正確に記録し、必要に応じて過去の構成であっても正確に再現することができるように管理すること。基本要素としては、バージョン管理（Version Control）、作業領域管理（Workspace Control）、ビルド/リリース管理（Build/Release Control）、プロセス制御（Process Control）が求められる。
いささか強引な定義ではありますが、わかりやすくするためですので、ご了承ください。
本題のバージョン管理とソフトウェア構成管理の関係ですが、ソフトウェア構成管理においてはバージョン管理は必須な要素なのです。ただ、ソフトウェア構成管理は、バージョン管理だけではなく、ほかの基本要素も満たすことが求められているわけですね。
満たしていないといけないというと、堅苦しい学術的な話や、何かの認証や認定の話に聞こえてしまいそうですが、実際にソフトウェア構成管理の導入などのお手伝いをさせていただいていても、上記の基本要素をすべて考慮しないと、「いつ、いかなる構成も再現する」ことは難しいことが実感できます（個人的に一番キーとなる要素は作業領域管理だと思っています）。
話を戻しまして、要するにバージョン管理は、ソフトウェア構成管理を実践する上で包含されるものであり、バージョン管理＝ソフトウェア構成管理とは、言いがたいということになります。
ちなみに、上記のソフトウェア構成管理の定義（簡略化版）は、狭義のソフトウェア構成管理の定義として扱われることが多く、ここ数年で重要視されている変更管理を含めて、広義のソフトウェア構成管理ということがあります。
広義のソフトウェア構成管理
＝ 変更管理（Change Management）
＝ 狭義のソフトウェア構成管理 ＋ 変更依頼管理（Change Request Management）
といった式のイメージになるでしょうか。
最後に、誤解があってはいけないので、書いておきたいと思いますが、バージョン管理ツールでは、ソフトウェア構成管理が実践できないと言っているわけではありません。
バージョン管理ツールを用いてソフトウェア構成管理を実践なさっているプロジェクトをいくつも知っています。ただ、それと同じかそれ以上に、バージョン管理ツールの機能の範囲だけでチャレンジしているために、ある種の壁を越えられなかったり、ツールの機能の範囲を超える部分は手動であったり、他のツールも利用したりで恩恵を受けるどころか、余計な手作業やミスによる手戻り工数が発生してしまったり、なかなかプロジェクトや組織に定着しなかったりで悩んでいらっしゃるプロジェクトを見ているのも事実です。
では、ソフトウェア構成管理ツールっていうものは、何をしてくれるのかというと...、「チームメンバー（開発者だけではなく、アーキテクトやプロジェクト管理者、リリース担当者など含めて）に適切な構成を提供し続ける」といったことをしてくれます。そのために、上述の基本要素を考慮した機能を提供してくれています。
次回は（「何時だよ」って突っ込みはご勘弁を（＾＾；）、変更依頼管理についてちょっと書いてみたいと思います。