Before you can convince developers who've never used version control software, you have to be prepared to answer every question, worry and doubt they'll have. You'll be inundated with questions like:
- What was wrong with the way we were working before? We never had any trouble! (when you probe further, you'll hear about all kinds of problems that they did have, but conveniently forgot, or that they didn't perceive as problems).
- How will we get our stuff deployed to the site?
- Where is my stuff kept?
- Why are there so many extra steps to do something that should be easy?
- Why are you putting these barriers in my way? I just need to get my work done!
The accepted answer to the question you linked is a good start. You need to demonstrate:
- To the developers: This will save your hide someday.
- To the managers: You can accurately track who's been doing what on the project.
- To the accountants: You will ultimately save time (and thus money) by having safety nets (for when things go pear-shaped) and keeping developers developing and not deploying.
- To the sysadmins: This will keep developers off their servers.
You can't just install version control (Subversion or otherwise) and call it a day. People will revert to their old ways because it's easier (it's probably not, it's just what they're used to). You need to get a handle on source & configuration management and designing processes to support your workflow(s) as well as your tracking requirements.
You've got at least two completely separate and distinct environments (dev & production), preferably three (dev, staging & production), right? If not, start there. People should not be making changes to a live website at random! And if possible, developers should be able to run their projects right from their workstations, so that they can test prior to checking in.
Your applications should be completely self-configuring. That is, you should not need to manually fiddle with them each time you deploy them into a given environment. Deployment should be more or less "hands off" or at least scripted. Once you have that set up, you'll need either your own scripts, a Continuous Integration system, or a combination of both, to handle the deployments.
You can use a post-commit hook script to update your website in the dev environment. So as soon as a developer commits his changes, they'll go out to the dev site to be looked at.
My own setup is thus:
- CruiseControl.NET runs on each server I deploy to.
- Upon committing, the CCNET service on the dev server picks up the change, pulls the project from SVN, compiles & deploys into the Tomcat app server (it's a Java web app).
- After a successful deployment, CCNET creates a tag in the repository representing the code that I just deployed.
- After I perform my own testing, the CCNET configuration on the staging server is updated to point at the tag that dev created, and we force the build.
- After a successful build in staging, another tag is created.
- After final acceptance testing is signed off on, we update the CCNET configuration for the production server and force the build.
- After a successful build in production, another tag is created.
My CCNET configurations are also stored in Subversion and deployed through CCNET, so we don't have to touch the files on the servers directly - we update them, commit, and trigger a "build" which pulls the updated configuration down to that server.
What do all the tags offer me?
- I can roll each environment back to a previously known good state if something goes wrong.
- I can move forward with development on feature set B while waiting on feature set A to be promoted to production during our scheduled maintenance window later in the week.
Other tools, such as RedGate's Deployment Manager, can make this even more automatic.
In order for all of this to work, you need to have a solid, agreed-upon process that everyone follows. It's also beneficial to have a strong separation of duties - your developers shouldn't be deploying, and your admins shouldn't be mucking around in code.
OK, so you've set all of this up, everyone (including management!) says they're on board, what's next?
Revoke access to the non-development servers for all of your developers. No more FTP, no more shell, nothing. Maybe read-only access to some logs, if you have them there.
They will whinge. They will cringe. They will get mad at you. "You're taking away all my access!" "You're getting in my way!" "This will take me 10 times longer to make a simple change!" "You're a monster!" "You make Satan look like a really nice guy!"
Doesn't matter. As long as there's "an easier way", the right way will be ignored. This is why you need management on-board and watching your back.
The first time something gets to production and brings the database server down because the load of live traffic is too much, you'll revert to the previous version of the app and things will be back to normal in 5 minutes. You'll be a hero.
That you're saying you need to "strip .svn entries before branching out" is a worry to me. Either you're describing your process poorly, or you're doing something wrong.
Edit: Just remembered something else. You've got a backup strategy for your repository, right? If not, and the drive fails with data lost, everything will be blamed on you & Subversion, not on the failed hardware (despite the fact that hardware failure can happen anywhere).
