Practice. Expect to practice with your version control system before you go live. This means you need to have a copy of your data. If you are exporting data from CVS to Subversion, it is probably a good idea to keep the import files around for a while in case you have to go back. Version control systems are generally forgiving (that is the whole point over having version control right?), but you can mess things up. For example if you accidentally import several GB of binary files and then delete them, it might cause problems with your backups because that data will still be there.
Training. Make sure everyone gets at least some training on how to use the system. A short list of how to accomplish common tasks can make everyones life a lot easier and may head off problems down the road.
Backups. Your data must be backed up automatically. Just copying a directory doesn’t mean you’ve backed up anything useful. You don’t really know if you’ve got a backup until you test it. When you are setting up your backup you should do a test restore to another machine and then checkout your data to make sure it works. You should probably repeat this every few months depending on how important your data is.
Decide what to keep. You need a clear policy as to what goes into version control and what doesn’t. Some people recommend putting everything under version control. However, I can’t think of a whole lot of reasons to keep a binary iso under version control. Generally you want to put stuff in the repository that might have other versions. Personally, I don’t like keeping binary libraries in Subversion. I have a separate repository for those types of files. I do think it is a good idea to keep your configuration files in the system. It is a real lifesaver to be able to go back to a previous version of a backup script to see why it is failing now, or to see what has changed in httpd.conf that is making Apache act funny.
Remote access. If you want to make your repository accessible over the internet, you should plan for it when you set it up. With Subversion this is easy because you can plug it into Apache 2. Keep in mind that you want to use the same url from inside the network as outside. This is usually just a matter of putting a DNS entry on your internal network that points to your private ip address while the public DNS entry points to your public address.
