When Matlab is installed in its 64 bit version, it can use only 64 bit source control systems. Is there a source control system that's free, works with 64 bit Matlab and runs on Windows?
It can be a system that supports only one developer. It can be 32 bit itself, if it'll work. It will be installed on the same machine as the Matlab in use, which is a Win7 Ultimate x64 machine.
You might be interested in using Subversion or Git, which are tried-and-true, general-purpose SCMs.
I'd recommend mercurial using the TortoiseHg interface. There is a 64bit windows version available for download. It includes a set of windows shell extentions so it works nicely from the explorer window.
It's easy to set up and use and it's saved me on numerous occasions. Mercurial works well with binary files so MATLAB mat files and fig files can all be placed in version control. I'd say it's essential i you're using guide. In developing GUI's with guide there have been occasions where guide has crashed and was unable to reopen the fig file again. Fortunately a quick roll back in Mercurial to the last previous working version and I was back working again.
To be honest I've never really been that impressed with MATLAB's integration with SCM, it just seems to be a tacked on option rather than integrated. Something like NetBeans shows how you can integrate SCM in the development environment. So I wouldn't try to get MATLAB "to use" SCM rather just use Mercurial (or whatever you choose) alongside MATLAB.
Oh and it's free as well.
For SVN, I have written a Matlab-GUI for committing (and checking differences in) code for when I'm too lazy to launch another application to commit my changes (or for when there is no nice, free client, like on OS X).
You could do something similar for any other version control system, and then you don't need to worry about whether Matlab supports it.
I've been using git to track my matlab code and it's been very useful. If you do go this route, make a .gitignore file and put the following in it
*.asv
*.fig
*.mat
The reason for the first one is that you don't want to archive your autogenerated backups. Since .mat and .fig files can be large and are generally generated by your code, I don't archive them either. One exception is gui figs; I create a gui directory and put a new .gitignore file in it with
!*.fig
which tells git not to ignore .fig files in that directory