Keep from losing your mind with SVN
Thursday, April 1, 2010
There are a lot of version control systems out there, and to be honest, most of them have pretty useful guides on how to get them working. But over the years, I've had a lot of web people (namely designers, content writers, and SEO folks) ask me how to set up SVN on their systems, and in most cases those guides go right over their heads. This is not an insult to people who are too busy to learn the intricacies of version control, it's a statement of the fact that most people who geek out about this kind of thing have a hard time speaking in simple English without a variety of jargon that makes the explanation more complicated than the question. So let's get straight to it!
WTF is SVN?
There are a variety of version control systems, but SVN is SubVersioN, a system first developed by CollabNet Inc. The way the fundamental system works, you need a centralized server that runs a version of the SVN server application. The idea is that all of your code is stored on that server, so any number of developers can "check out" their code. This code is stored in what is called a "repository", which stores not only the latest version of all the files, but every version that someone has ever "checked in" to the repository. This means that multiple people can work on the same source code without over-writing each other, and if you lose every single file on both your live site and your home site, it's all safely stored in the repository.There are a lot of different sites that collect the different services you can use. The best guide I've found so far is this one at Straw Dogs, that has the 10 best free available svn systems. I personally choose beanstalk, which is actually $15 a month if you want to do more than one repository, but it's really easy to set up multiple users and you can actually view your files very simply through a web interface.
Note: there are other version control systems such as CVS and Git, but SVN is much more commonly integrated in the tools that I often see the aforementioned groups using, so this is the only system I'm going to describe here.
Make it Work
Now, assuming you've gotten yourself an SVN server set up, it's time to integrate with your chosen application. In Dreamweaver, you'll need to go where your sites are set up (you'll need the advanced tab).Here is the screen you should see:
As you can see, it only supports subversion, but your repo can be in a variety of protocols (http, https, svn, svn+ssh), so just make sure that you make it match the setting that your chosen service uses.
Now, as you modify files from the file manager, you will see a green check by a file when it is "checked out" for editing. After you've made the changes to your satisfaction, you can "check them in" to the repository, which will make a version of the file in the system. You have a small window to type a commit message, which is usually very useful for describing to other developers what you've done (eg, initial checkin, updating or changing systems).
Is that it?
For most developers in the range I had specified earlier, this is enough for your needs. Most of the time these developers are only changing files on a server that is not live, and once the site goes live, any changes are made as tweaks. This works fine, as you can upload your files to make sure they work, and then check them in once you're happy with them. But there are systems that I think are more useful for managing changes.Multiple environments
SVN is most useful when you're using it to commit changes from a staging server of some kind. In my personal environment, I've set up XAMPP to create a virtual apache installation on my local machine. Then, the local versions of my files are in the directory that serves up the files from http://localhost/ so that I can make sure it works on my local machine before uploading to the dev server. This is especially useful when you need to make changes to the site and don't want to see them on the live server until you're sure they work. In this case, you work completely locally and check in and out all the files from there. Then you can upload them to the live site.Auto-Push
I won't go into the details of how to do this here, but there are a variety of methods that you can use to actually push files automatically from a repository to a live server. This allows you to develop in potentially three environments (which the standard for most serious application developers). In this version, you make all your changes and so forth on your local machine or a machine you've got ready for development. Then, when you feel like you've got a decent product, you can send it to the staging server, where your clients/testers can see a demonstration of the site. Once they've decided that what they're seeing is what they wanted, you can commit those changes to the repository, which will update the files on the live site.I feel like this is the best way to go, especially for sites with dynamic content in a database. In those cases, you can check out the changes on the staging server first. This is helpful, because in a lot of cases if you have a wordpress or other database-driven site, it's fairly hard to synchronize database changes between different servers.