Using SVN With a Staging and Live Website

Question

I currently have an svn repository on my hosted web server. I work locally, commit my changes to the repository on my server, and then run an \"svn update\" via ssh in my live

Answer 1

I manage a development shop consisting of 5 developers. We utilize SVN in the following way for our website:

• Developers commit all enhancements or bug fixes to our 'dev' branch before marking a job as complete.
• Jobs are tested on a staging box running the latest code in the dev branch.
• Once a job passes testing, the revisions for that job are merged to our trunk branch.
• Our live web servers run the trunk branch. Periodically, they are updated via a 'publish' script which updates SVN on the live servers and does some other things as well (such as obfuscates and minimizes CSS and JavaScript).

This allows small bugs to get through the pipeline quickly and larger jobs to take as much time as they need in development and testing.

Since each developer is responsible for merging their own jobs and each merge consists of a smaller set of code changes, they go pretty smoothly. It is a lot less hectic than the older pattern of having a merge manager create a major enhancement branch for a set of enhancements. Since other developers typically work together on a set of enhancements, you would end up with a merge manager who merged code they didn't write, which becomes particularly frustrating when you have merge conflicts.

In fact, this method kind of mirrors the methods that versioning systems like Git and Mercurial attempt to promote by way of how they structure their repositories. With those versioning systems, each developer has their own 'local' repository. When they want changes from another 'repository', they have to merge them with their local code, then commit a valid 'merged' version.

You can also use tagging as Andy mentioned in his answer to this question. It may work for you, but I prefer to put the responsibility of merging on the developers who write the code rather than a central senior developer or publish manager. They tend to go more smoothly that way.