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 folder when I am ready to push the changes live.

I am now adding a staging site, which will reside on the same server. It will simply be another folder on the same server.

The issue is that I will be working on somewhat larger changes to the site on the staging server that may take up to a week of testing. During that time, I may want to make a small cosmetic change to the live site that requires no testing. Let’s take an example:

1. Assume my local, staging, and live site all begin on revision 1.
2. I make major changes locally, commit them, and update my staging server. Local and staging are on revision 2, live is still on 1.
3. Someone asks for a simple text change on the live site.
4. Ugh. Now I have to revert my local copy to revision 1, make the small change and commit it. Now I update to the live site to revision 3, which has the small change.
5. I want to keep working on my major changes, so I update my local copy back to revision 2, and keep working.
6. And so on….

This forces me to keep track of revsions and constantly be updating and reverting. Is there a better way? I feel like I am supposed to be using branching and tags here, but I don’t understand how exactly.

Thanks,
Jonah

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.