Lincoln Loop

Subversion for Web Developers

I switched from Ubuntu Linux to a Mac last week. I knew the new system would force me to adapt my workflow a bit so I figured it would be a good opportunity to break some bad habits.

One of those bad habits was how I manage site and code updates. My typical cycle was to build the site on a local development server, upload the site, present to client, then go through a tweak → upload → tweak → upload cycle until the site was perfect. This development approach, although popular, is flawed for a few reasons:

• No revision backups are maintained, unless you are manually doing them. You break it, you buy it.
• The constant uploading for tweaks is inefficient and slow.
• It simply breaks down when trying to work with others on the same code.

Enter Subversion. It solves all these problems and has some other really nice features to boot. Luckily, right about the time my Mac arrived, Circle 6 did a fantastic right up on using SVN to manage your websites. If you aren’t familiar with Subversion, go read their series now, the rest of this will make a lot more sense.

My situation is a little different from their’s. I don’t need or want to keep a Subversion repository on my live server. I’m the only one that needs access to it, so I wanted to host my repository and development server locally. The first step is to get all the necessary software installed:

1. If you are doing PHP development, install a MAMP environment from MacPorts (tutorial here)
2. Install Subversion from Martin Ott’s binary.
3. Create ~/svn folder for repositories and use ~/Sites for my checkouts and development.
4. Test.

Once you’ve got everything is working, lets create our first project.

cd ~/svn
svnadmin create domainname.tld
mkdir -p domainname.tld/trunk/public_html

At this point, if you have existing project files, move them into public_html (or whatever you want to call it). If you have any files that you want to keep outside of the web directory, but in subversion, copy them into the trunk directory.

Now import your files into the project.

cd ~/svn/domainname.tld
svn import trunk file:///Users/shortname/svn/domainname.tld/trunk -m "initial import"

Our repository is ready for action, now let’s checkout a copy to work on.

mkdir ~/Sites/domainname.tld
cd ~/Sites/domainname.tld
svn co file:///Users/shortname/svn/domainname.tld/trunk trunk

Edit to your heart’s content, commit changes, test the site locally using MAMP, WEBrick, Django’s development server, whatever.

Once we’re done, we need to upload the changes to the production server. This is where I got a little stuck. Logging into the live server and doing an svn update or export seemed like too much work and I wasn’t thrilled about opening up my personal network for access. I needed to be able to push updates to my webserver. Subversion wasn’t really what I needed, but Rsync was perfect for the job.

I created a quick shell script that would run this command:

rsync -avuz --exclude-from='exclude-files.txt' trunk/public_html/ myuser@domainname.tld:~/public_html

Save outside of your Subversion repository in ~/Sites/domainname.tld as upload.sh and make it executable. Notice the exclude-files.txt file in that command? We’ll create that in the same directory and put a list of files we don’t want to upload like Subversion information and development config files. Here is a sample one from a WordPress project.

.DS_Store
.svn
wp-config.php
.htaccess

Manually upload any necessary config files one time and then just run ./upload.sh to update. If you wanted to update the live server on every commit, you could move upload.sh to ~/svn/hooks/post-commit.

So far, this system has worked very well for me. Got a better solution? I’d love to hear it. Tune in next week for details on automatically creating a message in Basecamp on every commit.

Comments

• May 4, 2007 at 4:32 p.m. #
  Jared mentioned:

  Pete,

  Nice thorough write-up, but I must say I’m surprised that you don’t host your Subversion repository remotely. Even though you may not need other devs access it yet (I am sure the day will come), it is still useful.

  Firstly, you can access the repository from anywhere. This has saved me many times under many different circumstances.

  Secondly, it removes the need for rsync. In my workflow I usually have a deploy.sh that performs 'svn export’ onto the live server’s web directory (svn export exports just the files, no .svn meta info).

  Additionally, you can develop the minor tweaks on the development server and still check in the changes if you’re working from a working svn copy.

• May 4, 2007 at 6:12 p.m. #
  Peter Baumgartner chimed in with:

  Thanks for the feedback Jared. Does your SVN repo live on the same server as the live site? I assume so, otherwise the svn export seems a little heavy for small changes. Does deploy.sh live on that server as well?

  One thing I like about rsync is that is only moves changed files and won’t overwrite files if they are newer on the server. It is also simpler to exclude config files that need to be different between the development and live server.

  You’re correct though, this method doesn’t scale to multiple users.

• May 4, 2007 at 6:48 p.m. #
  Jared responded:

  We have a few servers that are located, quite literally, next to each other, so a full 'svn export’ isn’t a big deal. Plus, if you’re only worried about one file or directory, you can just export that one item:

  svn export svn:///example.com/some_directory/some_file.htm

  Not quite as elegant as rsync, I admit.

  deploy.sh lives on the server, yes. It is in my project folder in the repository so it lives where ever a copy of the files do.

  Additionally, it doesn’t require much httpd.conf editing to restrict access against .svn directories so I’m thinking about using working copies for my live PHP sites (I already do this for my Django apps).

Comments are closed for this post.