On Sat, 6 Oct 2007, Ulf Jordan wrote:
svnversion -c might be better, but it doesn't recurse, and has an interesting output format in the general case (but sed will fix it!)
The issue of how to derive version numbers from svn revision information is indeed non-trivial, as shown by our discussion here and on other lists like the Subversion users' list.
To obtain a global revision number from a working copy there is a very good example in the svn FAQ (it's the only one in a red box, so I guess it's really frequently asked):
http://subversion.tigris.org/faq.html#version-value-in-source
However, I believe we don't want the superiotool version to increase just because there are other commits in the v2 tree, so the example needs adapting by adding -c to svnversion.
Attached is a patch that:
* derives the superiotool version number from the latest committed change to superiotool files (NOT the latest svn up of the superiotool directory)
* strips away extra information from svnversion, to arrive at a single version number like 2828 instead of 2814:2828M ("this build is made up of files with latest modification in rev 2814 to 2828 plus local modifications").
* does not recurse down into subdirectories or svn:externals (there are no such things in superiotool for the moment)
* does all the work in determining the version number at build time
* depends on GNU make features (although it could be rewritten more portably using a version.h file instead, like my previous patch)
This approach could easily be combined with a traditional version number from a #define in superiotool.h, as Robinson pointed out.
Corey: if you apply this patch to current svn superiotool, does the trailing garbage go away?
/ulf