10

In a VS2010 solution (not .NET), I'm looking to include the svn revision number as part of the application version.

we do not use makefiles at the moment, only the VS solution/project settings.

I'd like to get the working copy revision number at compile time, store it into a variable, so it can be used later on in the code to display the version number.

So far, I've successfully used svnversion to get the latest version of the working copy as a pre-built event.

"C:\Program Files\CollabNet\Subversion Client\svnversion.exe" -n $(SolutionDir)

At build time, I can see the correct revision number being returned into the output console.

Now, the question is, how can store this value into a variable that can be used within the code?

I've tried defining a pre compiler variable (_SVNREV) and using it to save the result from the above cmd, directly from the pre-build event box, but that doesn't work.

_SVNREV="C:\Program Files\CollabNet\Subversion Client\svnversion.exe" -n $(SolutionDir)
%_SVNREV%="C:\Program Files\CollabNet\Subversion Client\svnversion.exe" -n $(SolutionDir)
%_SVNREV="C:\Program Files\CollabNet\Subversion Client\svnversion.exe" -n $(SolutionDir)
$(_SVNREV)="C:\Program Files\CollabNet\Subversion Client\svnversion.exe" -n $(SolutionDir)

none of these actually work.

RESOLUTION: I was heading nowhere trying to update a variable from within the VS env. so I took another route, calling a script as a pre-build step, that gets the svn revision of the working copy and then creates a header file with that info.

Here's the svnrev.bat for anyone interested:

@echo off
set cmd="C:\"Program Files\CollabNet\Subversion Client"\svnversion.exe -n %1 "
set versionfile=%1/version.h
FOR /F %%i IN ('%cmd%') DO SET SVNVER=%%i

echo Detected program revision %SVNVER% in %1
echo #pragma once > %versionfile%
echo #define _SVNVER "%SVNVER%" >> %versionfile%
fduff
  • 3,671
  • 2
  • 30
  • 39
  • Have you missed 'svn keyword substitution' or have I missed the point of your question ? – High Performance Mark Aug 21 '12 at 14:46
  • 2
    'svn keyword substitution' will only occur when you commit a file to svn. svn will then replace a reserved variable with its value. This doesn't work in this situation. – fduff Aug 21 '12 at 14:54
  • How about setting up client side post-update and post-commit hooks? [TortoiseSVN](http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks) has them. Hooks work in unison, updating the same variable, which is SVN revision. – Dialecticus Aug 21 '12 at 15:57
  • Also, see the answer to this, possibly related question: http://stackoverflow.com/q/2738673/395718 – Dialecticus Aug 21 '12 at 16:07

4 Answers4

6

the best guess i came up with so far is to generate a header file in the pre-build event that contains the svnversion.

e.g. i create a batch-script version.bat:

@echo off
FOR /F "tokens=*" %%i IN ('call svnversion') DO echo #define SVNVERSION "%%i" > svnversion.h

and wherever i want to get the svnversion, i simply #include "svnversion.h"

umläute
  • 28,885
  • 9
  • 68
  • 122
3

If you're doing builds, you should have a standard build system. I recommend using Jenkins. It's open source, and easy to use.

One of the neat tricks Jenkins has is inserting in some nice environment variables for your use:

  • SVN_REVISION - The Subversion revision number
  • BUILD_NUMBER - The build number in Jenkins
  • JOB_NAME - The job name in Jenkins

Once you start using Jenkins for your builds, the latter two environment variables will probably become more valuable than the Subversion revision itself since the latter two will link your code back to the project, and all sorts of good information.

Jenkins is a continuous build engine. You can set up a Jenkins job to build on command, whenever there's a checkout, or at certain times of the day. You can even send a build-on-command via a wget on a URL.

By using a build server, you eliminate the good possibility that the configuration of a particular system has some sort of side effect on the build. The build server is a known configuration and will produce your official builds.

This is a bit more than you probably wanted to know. (Specifically, you could have used the svnversion command to retrieve the revision number, and then proceed from there). But, it will greatly improve your build process.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • thanks for that, we do use Jenkins. the *problem* is that these variables are only available once in Jenkins, i.e. when code has been committed. And it's the same problem, how do you pass these variable down to the source code at compile time then? – fduff Aug 21 '12 at 15:34
  • 1
    Doesn't Jenkins checkout the code and compile? That's when Jenkins will insert the revision number. When a developer does a build, I check if SVN_REVISION has been set or not. If not, it's set to _dev build_. This way, I know if the build is from Jenkins (and thus offical) or from the developer. Besides, you really don't know the revision until the code has been committed. Otherwise, you get the revision number that the developer checked out from which doesn't include their changes. – David W. Aug 21 '12 at 18:07
1

You can run the command wrapped in a batch file. The Batch file could produce a header file like version.h containing the version string as:

#define SVN_REV 12345

"#define SVN_REV " is echo'd by the batch script. The SVN rev is from the command which you have.

Now you can include this header in the code and use the #define as you want.

gammay
  • 5,957
  • 7
  • 32
  • 51
1

I've seen people parse svn info for the version number and write it to a file, then set up the compile to slurp the file into the compiled code.

Tricky thing about SVN: In the older versions (where there's a .svn file in every subdirectory), the version number was only guaranteed to be correct for the project root directory. Any other directory would bear the version number for the last commit in that subtree. I don't know what version you're using but watch out for that if you're a couple revs back!

Jason
  • 3,021
  • 1
  • 23
  • 25