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? _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire