At the moment (as far as I can tell) the revision string is #defined into many files, which are not necessarily recompiled when running make, even if the revision string has changed, unless a clean build is chosen deliberately. The result of this is that testing network play requires either producing clean builds each time the revision changes, or excluding/hardcoding the revision string. I think it ought to be possible to change the revision without having to do a clean build. A quick test shows that even with the current code, recompiling only the files affected by a revision change is more than an order or magnitude faster than compiling a clean build. Furthermore, since the revision string is rarely accessed, I don't see any need for it to be #defined everywhere. It could instead be defined into a single-purpose .cc file which is always rebuilt, with every other bit of code accessing it via the corresponding .h file.
What do you think? I realise that it is still possible to 'shoot yourself in the foot' by building with a dirty working tree, but I think that's much less problematic than having a build based upon a 'correct' working tree having traces of older revision numbers in it. This is a problem that caught me out earlier, although I didn't realise what had happened until later, after I started thinking about how the revision string was updated.