Subversion and branching strategies


What is Subversion

Subversion is an open source application used for revision control. It is sometimes abbreviated to SVN in reference to the name of its command line interface. Subversion boasts many advanced features, such as atomic commits, versioned directories, and good support for binary file formats, fast branching and tagging.
The open source Apache project can be found at http://subversion.apache.org/

How to use SVN when developing

 

 

 

  1. Developers check out from SVN onto there own machine, all development is local and when the code is complete it is checked back into the SVN Repository.  It is advisable to do this as often as possible i.e. minimum once per day.
  2. To deploy to staging an SVN checkout/update is completed to staging; this may be automated via the use of cruise control
  3. To deploy to staging an SVN checkout/update is completed to live; this should not automated via the use of cruise control, it can be a copy of a update to staging.

 

What is a good branching and release strategy

Branching and merging is the key to effective use of a version control system playing a crucial role in software development. There are multiple schools of thought with regard to branching, I suggest using the most common, which uses a main development trunk.  In this scenario the bulk of the development work is done on the main trunk.

Whenever a release version is ready, a separate branch should be created for the release. This occurs when you release a new version of your application for acceptance testing or into production.

Meanwhile, any development work would continue on the main branch. The real advantage of this approach is that you can deploy maintenance releases (bug-fixes) to a production release version without having to release an unstable version of the code main trunk.

Note: You will eventually want to integrate changes made in a release back into the main development trunk. For example, you might want to apply a bug fix made in the release branch to the development branch as well.

Variation: An example of a variation on this strategy is to branch in order to work on a major new feature or refactoring work which may or may not be included in the next release. That way the work can be completed in isolation, without compromising daily builds or release schedules.

 

 


Leave a Reply

Your email address will not be published. Required fields are marked *