SVN version number into specific files after any revision change

Question

In our project we got a request to put the SVN root revision number (not the last modified one) into our lib headers and provide an function in the library which will give the last commit's revision number.

I have already found this question so I know about the $Id$ or $Revision$. What I do not know if it is possible to force SVN (without additional scripts) to update some specific files (headers and an .cpp) after every commit.

E.g.: I modify a .cpp file and I commit it, but after the commit not only the modified .cpp file will be updated but the lib header files and a small .cpp file too with the commit's revision number.

The purpose of this request is to provide the possibility to the our library users to check the revision number of the code even when they are copied the files into places where the SVN is not reachable.

Update: Compiling will be done in the environment where the SVN is not available.

Answer 1

1. Please, use standard terms and definitions in order to get definitive answer - "SVN root revision number" is something, unknown in the normal SVN-world. Is it "Global Revision ID of repository"?
2. SVN-keywords are file-specific and does not correlate with Global Revision number
3. You can't commit forcibly unchanged files with changed, but you can commit these needed files (with some tricks) in post-commit hook after committing related files (but remember, $Revision$ in these .cpp and .h will be at least Revision+1 for real sources - and can be more than +1, if post-commit hook will not block commit during it's execution)
4. You can get and use Repo-Revision in your code and sources without svn:keywords and|or hooks and additional commits: for the cost of one additional operation in build-process and introducing of some changes into .cpp and .h in repository. Read about SubWCRev, part of TortoiseSVN (linux-equivalent with added value also exist: SvnRev) and see at Keyword usage example, note recommendation in "Tip". SvnRev workflow is slightly different - it doesn't process template, but build headers, which must be included in approppriate place

Answer 2

In our C/C++ projects we have a mix of 2 different approaches to this:

1/ Make uses subwcrev with an input file: version_info.src producing an include file version_info.inc - this is included by our code.

static cstring_t LastCommitDate = "@(#)SVN Info: Highest Commit Date $WCDATE=%H:%M %a %d-%b-%Y$";
static cstring_t InfoGenerated  = "@(#)SVN Info: Generated $WCNOW=%H:%M %a %d-%b-%Y$";
static cstring_t VersionRange   = "@(#)SVN Info: Built From Revision $WCRANGE$";
static cstring_t MixStatus      = "@(#)SVN Info: $WCMIXED?Mixed:Single$ Revision";
static cstring_t ModStatus      = "@(#)SVN Info: $WCMODS?Has:No$ Local Modifications";
#define CURRENT_REV_NUMBER $WCMIXED?0xffff:((uint16_t)$WCRANGE$)$
$WCMIXED?#define _MIXED_REV_BUILD_:$
$WCMODS?#define _BUILD_INCLUDES_MODIFICATIONS_:$
#ifdef _DEBUG_
#else
$WCMODS?#error *** SVN - Local Modifications Are NOT Permitted Within A Release Build! ***:/* SVN - OK for Release No Local Modifications */$
$WCMIXED?#error *** SVN - Mixed Revisions Are NOT Permitted Within A Release Build! Please Run a svn update!***:/* SVN - OK for Release Single Revision */$
#endif

This includes our version information for us and will not let us make a release build with modified code.

2/ On some of our projects we make use of python with the svn bindings from our build script(s) to generate the version information needed into include files. This is more powerful as it can check for the presence of files that are used by the build but have not been added to the repository.