While I prefer subversion over CVS, that's not a high priority. If time is short I would leave that to last, and not make it first.

I think it is a bad idea to try to release through svn update. I would say that a high priority should be a defined release process which includes having development, staging and production environments. Code should be moved from development to staging, tested there, then released to production. When you release to production you want to release what was put on staging, and not what is current.

If you want to make people use source control, the best approach is to deliberately and regularly overwrite production files with files from source control. Get management on board with this. Then when you do so it won't be your fault for having broken someone else's change, it will be their fault for having not used source control. If you can't get agreement on this point, then source control is a lost cause and you should be looking for a better job. (The fact that they are letting you accomplish an important work project on your own time over a long weekend is frankly a pretty bad sign...)

Rather than have one Apache file for all of the development sites, I would suggest having one copy of Apache per development site, each of which is on a different port. You can then let every developer check out the source code on their own user account. This will require development-specific configuration information. I've used several approaches for this in the past. A simple one is to have a well-defined configuration file which is per server and is not in source control.

This is the core that you need. Your other changes can and in my opinion should be treated as an ongoing project. I would recommend not biting off too big a refactoring job up front. It is better to finish something useful than it is to not finish something big.