Release management in SVN

Question

When I look in the SVN log I really wish I could see markers that tell me when releases were done. I've seen this in other version control systems such as PVCS and Perforce.

Can this be done in SVN? I've done a little bit of research and so far it looks like this sort of thing is not supported.

Edit

We don't want to have to copy our source to a different folder for each release. This results in a huge amount of unnecessary duplication of files on the developers machine and only gives us a record of the revision number of each release. I can do that using a text document!

Edit2

My goal is to have a single view that shows me a chronology of my releases, between which I can see all of the code changes that took place between each release. This then makes it easier to compile release notes.

Answer 1

Not as such. The accepted way to do releases in SVN is to have a "tags" directory where your release source is copied for each particular release. For example /tags/release-0.11 ... There isn't anything preventing you from messing with the tags directory by accident, out of the box, but some people like to set up pre-commit hooks to prevent accidental commits to release tags.

Here's a decent article describing a release process in SVN.

Answer 2

The marker would be the commit message written when a tag for the release is made (a svn copy to the /tags). Atleast that is the most common method used.

Answer 3

Copying the trunk to a tags path in the svn repository is the way to achieve this. It is an svn copy, so doesn't end up with duplicates of files on the svn repository server. You only have duplicate files locally if you chose to checkout a svn path other than the trunk. Commits on those working copies then go back to the svn path they were checked out from.

This is essentially a specific conventional implementation of branching in svn. Take a look at the online svn book for more details.

Answer 4

FYI,

SVN copy is not hard-copy, it's just linking therefore won't take any space other than changed files. And those versions will take space anyway. So creating a copy for every release will not take any space.

Answer 5

My goal is to have a single view that shows me a chronology of my releases, between which I can see all of the code changes that took place between each release.

Have you investigated the Tortoise SVN revision graph? If you tag each release (which as others have pointed out does not involve copying files, either on the server or the workstation), then you can see all the revisions in chronological order, with the tags indicating actual releases. You can diff between releases and/or trunk by hilighting the two revisions you are interested in and selecting diff from the context menu.

Answer 6

Additionally, if you know which revisions you are comparing you can do an SVN diff and you will see which files have changed and how between the two revisions.

Not sure about your total setup but someone mentionned TortoiseSVN. That's definitively a good start. I personally use Eclipse with the subclipse plug-in and it allows me to perform diffs in a graphical environment between revisions. As long as you have your project your can compare any revision to any other revision and as such you don't need to have all kind of file duplication.

Also, we usually set up three directories in each repository. Branches, Trunk and Tags. As someone noted, Tags are used specifically for identifying a release.

Answer 7

Take a look at the SVN Book's topics:

Tags and Browsing the Repository

Tags and Branches are "copy on write", meaning that there are not extra copies in the repository. Generally an individual developer would not need to have a local copy unless he needed it for a reason (I.E. developing on a branch).

If you tag each release, then you can see the tags by browsing the repository. The above links talk directly about the command line tools, but there are also GUI tools like TortoiseSVN on Windows. You can get history, do comparisons, etc.

To see the changes made in a release, you would just show a log of the trunk from the revision of the tag you want back to the previous tag's revision +1. It sounds like extra work, but it is pretty simple once you get used to it.

With our build tools, we also commit back a file with some version number information back to the trunk, and the comment has the version number of the build. If your main code is in the trunk, this can also work as a marker for what is in a build (look between the version commits).

Answer 8

While Subversion does not provide release management in and of itself, version control tools are not typically tasked with this activity. What you are looking for is an activity/issue/change management tool that can interact with Subversion.

To that end we use Jira at my place of work and we link it with Subversion. Jira provides a roadmap and change history that includes issues in each release. Each one of those issues has links to the changes in source code control. Thus you can link changes in source code with released versions.

I think it's generally better to keep these two tools separate. Though Perforce in particular tries to tie the two together, they do so only simply. There are some things, like emailing users of changes to issues, adding comments to issues, adding attachments to issues that are much better done in a specialized piece of software like Jira. On the other hand Jira is not very good at versioning, merging and branching source ... which is better handled in a specialised piece of software like Subversion.

For full disclosure, there are other tools than Jira like Bugzilla, Trac, IBM Rational Jazz, etc. that can do the same thing with Subversion that Jira does though with varying levels of functionality.

Answer 9

Richard, tags are very close, but I wonder if what you need might not be a dedicated release branch.

For this, make a branch from trunk early on called something like 'Release'. Then work on trunk as normal, when you're ready for a release, merge your changes from trunk into 'Release'. This is the only way that you should modify release.

You can then tag from release if you want, not 100% necessary.

But what this will give you is a branch that has a subset of the trunk's revisions in it. Find out your release dates with:

svn log --stop-on-copy svn://server/project/branches/release

This will give you a list of release dates (with the revisions). To see what's in each release do:

svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>

Also note that by working this way, you aren't limited to a strictly sequential release of everything in trunk - you can cherry pick revisions, excluding revisions if you don't want to release them just yet, but still including subsequent revisions.

Answer 10

+1 for using the commit message.

For a project I created an SVN user called build. The build machine used this login for SVN. Whenever the build machine/process did a build it also updated a file and the SVN commit message was the version/other identifier for the build.

Then we also created a tag for that build. This way in the trunk we could see the builds when/where they are interspersed with other changes.

So my suggestion (simplest way to do it) is to create another files called build (or anything else you want) and append to that or just modify it in your build script/process and then check it back in/commit it with the name of the release version as the commit message. Simple. It will then show up in your history queries.

Answer 11

I encounter the same problem and the way I have tried to fix it for my company is to have a 'release' folder in trunk, this folder only contains the actual executable or what needs to be part of deployment.

I create a new folder for each release starting with '1.0.0.0' in 'release' folder and also tag the code with same release folder name i.e 1.0.0.0 in the case.

I am not sure if it is the right way to do it but it solves my problem to find out executable that I have deployed.

Answer 12

If you follow the normal svn convention of "tags/branches/trunk" at the root of your repository, developers typically would not want check out the entire repository, only from the trunk down.