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:
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
I manage a development shop consisting of 5 developers. We utilize SVN in the following way for our website:
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.
As you already identified the best way to do this is using branching and tagging. A good example of how to do this would be as follows.
Major development
When you need to make a small change to live you can now do the following:
There is a really good fee book on subversion that explains this all in excruciating detail here:
http://svnbook.red-bean.com/
If you can find the time I'd strongly suggest a read.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With