[crossfire] SVN notes/thoughts

[Mark Wedel]

  Been a few days since we moved to SVN.  With the transition, there are some 
changes that can be made.

  One point is automatically rebuilding the archetypes when the arch tree changes.

  My thought here is that lib/Makefile can run svnversion and puts that in a 
state file (.collect.svn.new).  Then, the process compares that file with the 
old one (.collect.svn) - if different, it runs the collect and moves the file 
over.  If the same, it just doesn't do anything.

  In this way, a collect would automatically be done whenever the archetypes are 
updated.

  One minor issues is that svnversion reports the version the respective tree is 
updated to.  Given that all of crossfire is in the same crossfire repository, 
you do get the case where the number of svnversion can be different, but for the 
actual component, there haven't been any changes made.  This is because 
svnversion returns the version that the tree is at, relative to last update. 
Real life example below:

[hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (591) % svnversion .
4963
[hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (592) % svn update
At revision 4969.
[hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (593) % svnversion .

  As you can see, there were no changes in the arch tree relative to the 
versions, yet svnversion returns a different value.  What this really means is 
that such a method would result in archetypes being recollected more often than 
strictly necessary.  OTOH, unless you update the arch tree, this isn't an issue.

  I think similar logic could also be used to embed the version number into the 
client and server binaries.  That way, when someone reports a bug, it is very 
clear what version they are running.  By using a state file, it means we don't 
need to recompile and relink everytime (if we just used svnversion to blindly 
write a .c/.h file, then everytime it would recompile and relink that component).

  In both of these cases, we also need to handle the case for the official 
releases, where there will not be any SVN information in the downloaded source 
code, and the user may not even have svn tools installed.

  Configure can easily enough be updated to look for svnversion to cover that case.

  In the case of lacking the svn data itself, I'd think the makefiles could just 
check for .svn files - I'd rather not have to reconstruct the makefiles for the 
official versions.  In terms of the version string, I think the file that 
inclues it would have to be part of the distributed version so that it is there 
for the compiled in.  Including the SVN version in officially released 
distributions shouldn't cause any problems IMO.

  thoughts/comments?