Many projects use SubVersion nowadays to store their project code. 

The question, is how to release your current code properly to the public. You probably don't want your users to check out your current development code. Either you want them to check out a certain version (release) or you want to present them with a download archive containing the code. Beside this, in released software you sholud have some files and metadata that differs from development version ones (i.e. readme files, manifest strinsgs, etc)

This article show you how to release a simple application from SubVersion as an archive file ready for deployment.

The base layout of svn repository sholud be like this:

  • there sholud be a directory named 'trunk' that always contains the most recent version of the software. This is the development branch, so to say.
  • ther sholud be also a 'branches' and a 'tags' directory. If you don't have these, you'll need to create them: 
    $ svn mkdir -m "Creating branches directory" svn://your-svn-repository/branches
$ svn mkdir -m "Creating tags directory" svn://your-svn-repository/tags

All release files, like doc, maniferst and reame files sholud be markedin to be develoment quality. This means that you don't display version numbers, but simply show a uniwque string  (i.e '__%HEAD&__') to indicate you're working with a development quality product. Also  this way. 

Before to release this code to the public, you want to tweak a few things. Since this is not general development, you create a Release Branch. This release branch is basically a copy of the current code in the trunk. Changes to that branch are stored seperately from the development code, so I can easily tweak it to release quality.

Creating the release branch is really easy. Let's say you want to release version 1.1.0 of yourapp. I just copy the code in subversion. Note that I don't download and store the code on my local machine. SubVersion is smart and duplicates the code on the server. This can save you valueable bandwidth, especially when you're working on a large project.

Well, create the Release Branch which is named,for example, RB-1.1.0.  You shold use a naming convention for releases

$ svn copy -m "Creating release branch 1.1.0" https://your-svn-repository/yourapp/trunk https://your-svn-repository/yourapp/branches/RB-1.1.0

You can now do two things. Either to checkout a seperate working copy of the release branch or to change your current working copy (which is using the trunk) to use the release branch. 

Just check out your code as you'd normally do, but make sure you specify the release branch. I've also specified to store this code in a directory named yourapp-1.1.0 so I don't confuse it with the trunk code, which is stored in a directory named 'yourapp'.

$ svn co https://your-svn-repository/yourapp/branches/RB-1.0.0 yourapp-1.1.0

You could also swich my current working copy to the release branch. This may be useful if your project is very huge and you don't want to download the whole thing again. Switching between a release branch and the trunk is usually more efficient because you only need to download the differences between the two.

$ svn switch https://your-svn-repository/yourapp/branches/RB-1.0.0

Okay, now you can work on the release branch. Branding it with the right version number among other things. For example it might be a good place to put two SQL files to install or update a database you are using. You might want to update the changelog, readme, manifests and other documentation. In big projects you can easily write a script to perform required change, these scripts could be manintained in trunk area as part of development process. It is a good idea to maintain also a packaging script.

When you commit changes, they will be applied to the release branch only, not not to the current development code.

When you're done you may switch back to the current development code:

$ svn switch https://your-svn-repository/yourapp/trunk

The code in the release branch is now ready to be shipped out. We want to mark this code as being Relese 1.1.0. This is called tagging. A tag is nothing more than a copy of the repository on a give moment. Technically, a branch and tag are the same. However, the conventions I use dictate that you don't change the code in a tag because it represents a certain state of your code, in this case the state the code was in at the time of Release 1.1.0.

Now, to actually create a release tag, named REL-1.1.0, we use the same procedure as with the creation of the release branch. Just note the differences in the source and destination repositories.

$ svn copy -m "Tag release 1.1.0" https://your-svn-repository/yourapp/branches/RB-1.1.0 https://your-svn-repository/yourapp/tags/REL-1.1.0

With the REL-1.1.0 tag we can create an archive that we can distribute to our users. Because we don't want to include svn metadata in our release we can't use checkout for this. SubVersion allows us to export our code, which is basically a check out, but without all the svn metadata. This is ideal to ship to our customers.

$ svn export https://your-svn-repository/yourapp/tags/REL-1.1.0 yourapp-1.1.0

Next I can tar up the yourapp-1.1.0 directory (using packaging script) and deploy it.

This article is greatly inspired from of the original 2006 work of Ariejan de Vroom "SVN: How to release software properly".