In part one of this series, you learned what Subversion is and how it can help you, in addition to the terms you’ll need to become familiar with in order to use Subversion in your development process. Part two of this series goes into more specific detail about potential development environments that may work for you.
Subversion creates a bunch of hidden files and folders inside of every directory in your Working Copy that’s checked into SVN. If your Working Copy is on your local computer, you’ll see these as .svn directories if your system preferences allow you to see hidden files and folders. You don’t need to worry about these, and you never really need to look at them, but as a result, it is not recommended that your Working Copy be on your live production box. If you decide not to listen to me, you should at least consider adding a few lines to your .htaccess to deny prying eyes access to your .svn directories.
Working Copy & Repository on your local machine
Create a Working Copy on your local machine, create the Repository on your local machine, and FTP/SFTP the files once they’re committed. This will really only work if you are the only developer, or your local machine is the only machine changing files. (Okay, that’s not entirely true – you can set up the Repository on a network drive and have multiple developers Check Out their own Working Copies to their own computers, but I have run into issues running Subversion over a network.)
If you’re running OSX on your local machine, see this tutorial on WikiHow on how to set up Subversion locally. If you’re running Windows, there is an exceptional walkthrough on The WebSqueeze written by Christopher Hyne that is a must-read. Setting up Subversion on Mac or PC is really quite painless, and this is a perfectly valid way to go.
Pros: Easy, local setup. No external services to set up, your workflow doesn’t change that much, and you don’t need an internet connection to commit things to your repository.
Cons: Possible challenges with running Subversion over a network, you still have to upload your files manually, and you don’t get the benefit of a slick gui with which to view revision history, as you would using Beanstalk or Unfuddle for hosted solutions, or by setting up Trac (a gui reporting interface/wiki/ticket system) on your server. You can set up Trac on your local machine with Python and some extra work, but that’s always been too much trouble for me. Just MHO though – it works great for some people.
Working Copy on your local machine, remote Repository
For my personal stuff, since I use Mosso as my web host, which does not currently provide Subversion (though I hear they’re working on it), I use a third party Subversion host, like Beanstalk or Unfuddle. I create my Repository on Beanstalk or Unfuddle, Import whatever files I may have created for the project already, Check Out a Working Copy to my laptop, and I’m all set. I work on files on my laptop, test them on my local installation of Apache/PHP using XAMPP, Commit them to Beanstalk or Unfuddle (depending which service I’m using to host my Repository), and upload them via FTP/SFTP to the development server area.
The result is a little extra work – I have to deal with SVN on top of FTP/SFTP, but the security of knowing my ass is covered and I have a detailed revision history makes it entirely worth it to me.
One benefit to using a third-party SVN host, such as Beanstalk or Unfuddle (besides the fact that it gives you SVN capabilities if your server doesn’t support it) is that you get a shmancy web interface with which to view your revisions. Below is a screenshot of the Unfuddle web interface. You can see that it gives me a nice, organized view of all of the history, including revisions messages, numbers and person committing. (This is a project for JPM Morgan that I worked on with my friend Vidyut Luther.)
In getting Vidyut’s blog url, I see his latest blog posts states that he can, in fact, use Subversion on Mosso, by using Expandrive. I haven’t tried it yet, and he has, so if you’re interested in exploring that as an option, check out his blog post about it. I may give it a shot at some point, but I do like the simplicity of working with a third-party SVN host. I don’t have to administer anything, just create the Repository and go.
Remote Branches on dev, remote Repository, rsync to live
One way of handling your development environment is to set up a Repository on the remote server, Check Out a Working Copy on a dev area on the remote server, such as dev.example.com, and set up individual Branches for each developer. An SVN Branch is simply a copy of the filesystem separate from the main version, called the Trunk. Using Branches allows you to save your half-broken work frequently without interfering with others, yet you can still selectively share information with your collaborators.
In this scenario, no one ever touches the live files directly, ever. Ever ever. Everything gets pushed to dev for review, and once it’s approved, you run the rsync script and rsync is the only utility that ever moves stuff over to live. It may sound confusing, but check out this simple blog post that explains how it can be done.
This can be daunting to set up, since there will be directories on live you may want to skip during the rsync (uploaded images, cache files, etc), but once it’s set up, it generally works like a charm, and it insures that no one ever screws up the live server, since no one is ever touching the live server.
Creating Branches is incredibly easy – check out the section on Branches in the free Version Control with Subversion book. They cover this concept and process very well. To give you an idea of what Branches look like, we’ll use their example structure, with a project named calc. This is what the original directory structure looks like:
You can see in this example, the ‘branches’ directory is currently empty, since we haven’t created any branches yet. The three file icons represent the total files in the project, which live in the Trunk.
Once we create a Branch, named ‘my calc branch’ (since it’s a Branch within the ‘calc’ project), you can see that a new directory is shown in the ‘branches’ directory, and a copy of the files from the Trunk live there:
Parts of each Branch can be selectively merged into the Trunk, so each developer can work on their tasks within their own Branch, break (and hopefully fix) as many things as they need to, Committing their work as they go, without affecting the main Trunk until the revisions are merged.
If you didn’t want to use Branches, you could add a staging server in this process. At a place I used to work, we had a development version that was actively worked on, a staging server, and a live server. We would Commit changes to the development server, rsync over to the staging server, and the staging server would automagically rsync every 10 minutes to live. Nothing was synced to staging unless we had kicked the tires and done QA on it on the development box, and if we couldn’t wait the 10 minutes, we could do a manual push to live by running the rsync script directly from the command line.
These are just a few of the possibilities. How are you using Subversion? Leave your configuration in the comments! And keep your eyes out for the next section that deals with the basic Subversion commands you’ll need to get started and optional gui applications you can use to make your Subversion experience easier.
