Tracking Versions, Builds, Revisions, with TortiseSVN

Question

I am the sole developer on a project and have been using tortoiseSVN for quite a while. Now Id like to start getting version information working correctly in the project I.E. show Major Version, Minor Version, Update, Build/Revision in the log files and in Help > About etc...

I cant seem to find the best fit. svn keywords Revision seemed like a good idea but the information it inserts into files is not in a friendly format for updating resources.

$rev$ is expanded to $Revision: 72 $

on the other hand subwcrev nearly makes it but I cant get it to write the correct revision to the version file. In other words if I run

subwcrev c:\myproject c:\myproject\version.in c:\myproject\version.h

it will write the current revision (72) correctly but if I then commit (now revision 73) and check out that revision at a later stage the actual revison in the project will be 72.

Am I taking a wrong approach to this? Should I take a different approach and just use an auto incrementing build number in Visual Studio?

What do you do in your organization?

Answer 1

First off, are you using tags in svn to track your major, minor versions etc? If not I would start there. I create a tag for each release of a project and simply name it 1.0, 1.1, 2.0 etc.

Second, you may want to look into a continuous integration / build server such as Cruise Control.

Answer 2

Subwcrev is a good tool for finding the status of a working copy. I wouldn't use it for tracking build numbers as subversion status numbers change quite frequently. It also sounds like it would be a pain keeping everything organized if another developer started working on this project.

Use the visual studio tool to track build numbers and use subversion to tag releases.

Answer 3

WordAligned has a very good summary article which you might like to read:

The Trouble with Version Numbers

Answer 4

To address your questions:

Am I taking a wrong approach to this?

Printing the revision number in the file itself is useful, but that revision number counts for the file only. Other files in your project will probably have different revision numbers and that will make it difficult for you to track down what group of files actually went into a build.

Should I take a different approach and just use an auto incrementing build number in Visual Studio?

No, stick with the one in subversion. Don't rely on your development tools to tell you what version your file is, use the version control system instead.

What do you do in your organization?

We use tagging. Once the files in our project are at a point to where we feel like we can deploy it to production, we tag that group of files (usually giving it a date in %Y%m%d format). Tagging has a lot of benefits to it.

From that tag, we'll build and deploy. We don't have a proper build server or continuous integration server yet. We're still small like you but we're getting there :-)

EDIT: I should have pointed out that Tagging is useful because it will tell you what state your whole project was in (it's a snapshot of all the files in your project regardless of revision number). It's also handy if you have to roll back to a previous revision. This is, of course, after you have been tagging for a while.

Answer 5

Ok, will add part of an answer.

In terms of a version number (never mind the mechanics) the subversion revision number is pretty useful - you probably want to control the Major and Minor but then using the revision number from there (3rd or 4th element) is nice. More importantly, even if you didn't specifically tag the repository at release you still have a means to get to the code in the right state.

Which brings us to Mechanics - this will vary somewhat dependent on language. In a C# assembly you want to modify AssemblyInfo.cs to have the desired values, in other languages I'm not sure off the top of my head (will edit in response to helpful comments!). If you are able to do this right you'll be able to identify the code for all your assemblies in a deployed project.

So... how do you get your AssemblyInfo.cs or equivalent right in a release build? By having a build script (MSBuild or whatever) do it for you - getting the build file right is probably painful (I've had it done for me before), especially when you start adding complications like pulling revision numbers but there are other tools that can help, which brings me to the desirability of a Build Server.

One of the things I recently discovered about TeamCity is that you it has system variables that you can insert into your build script - so I have the TeamCity build number (comprising the SVN Revision and TeamCity count of build) as my identifier - our release packages are build artifacts created by TeamCity so my ability to identify a specifc build is fairly good. I'm sure that other servers have similar capabilities. I haven't yet done this, but my next step will be to create "release" builds within Team City that I can trigger manually - its my intention that this will automate the step of creating a tag in Subversion as well as some other steps (e.g. tweaking web.config).

More pointers to answers than a real answer but the tools are there already (MSBuild with Community tasks, TeamCity, others...) its just a question of stringing them together.

Answer 6

In order to univocally know where a piece of code is coming out of a Subversion repository, you need two informations:

1. the revision number
2. the branch (or tag) where the code was pulled from

if you don't have both, you can never be sure where you checked out the code from. Since I don't trust managers not to abuse a manual numbering scheme (just reuse the same release number so that the customer doesn't notice that you sent a patch...), those information are part of the build and automatically retrieved when building the application.

To achieve this, I have a custom Ant task that retrieves the information and make it available as Ant property. You're then free to include them into a property file or a Java class.

The information is in my case displayed as "RELEASE_1.0/3454" or "TRUNK/4565".

The non-technical release name is defined as project.version in the [build.properties][2]. The advantages (...) is that you can override this value with a -D option and reuse the same version number.