[crossfire] SVN revions in version

[Mark Wedel]

Alex Schultz wrote:
> A few times, tracking the svn revision instead of the $Id strings has
> been brought up. IMHO this should be done, both in the client and
> server. I propose we implement it as follows in both:
> 
> Create a version.h file containing something like:
> 
> #include "svnversion.h"
> 
> #define BASE_VERSION "2.0.0-dev"

  It should actually get that version number from autoconf, like it does now. 
Then as part of that, for official releases, the -dev tag can be removed from 
configure.ac


> In release tarballs, the "-dev" postfix to BASE_VERSION will be removed
> and it will be adjusted to ignore SVN_REV. Then have a defaultly blank
> svnversion.h file, which the building process will create simply in the
> form of:
> 
> #define SVN_REV "5678"
> 
> The ./configure stage will check for the presence of .svn and the
> svnversion command, while the build process will run svnversion.


  The check for .svn would be better done in the makefile.  configure can check 
for svnversion.

  In addition, if the makefile doesn't find a .svn directory, or does not find 
svnversion, it should create a svnversion.h file with an empty SVN_REV, eg:

#define SVN_REV ""

  To the best of my knowledge, there isn't really any way to include a file if 
it exists, don't include it if it doesn't.  So it is just a lot simpler to 
always include it.

  You really don't want the svnversion.h file to be any part of SVN, because 
otherwise people will accidentally check it in and now have a version number 
that isn't correct.



> The
> build process running svnversion because not all revisions require
> ./configure to be re-run. Also, it will only write svnversion.h if a
> check shows that it was checked out from official crossfire svn, this is
> to ensure all revision numbers correspond to the same repository.

  I think checking for official repository checkout is probably overkill and 
isn't needed.  After all, if a developer really wants to have a bogus SVN_REV 
number, there are a lot easier ways to do it.

> 
> This version would both be used in the client for outputing to the
> console instead of the rcs-id values, and the server will use this
> version for reporting to the metaserver as well as console output. Does
> this model make sense to everyone?

  That sounds fine to me.