Hi, On Monday 25 September 2006 23:09 Nicolas Weeger (Laposte) wrote: > > 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). > > Agreed, having the exact revision number would be really nice to see the > exact issue. I agree and highly recommend this (using revision number). I use it in Gridarta for a long time already.
You actually can get the last change revision number instead of the latest update revision number out of the subversion client: svn info --xml doc | xql /info/entry/commit/@revision -cv XML is such a wonderful thing (read: Life can be so easy ;-) $ rpm -qf $(which xql) perl-XML-XQL-0.68-150 > > 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. > > Well, that's what tags/branches are for, i guess :) Yes. If used correctly, a release tag semantically is nothing else but a symbolic name assigned to a specific repository revision. (The symbolic name is assigned using svn cp, and please use svn cp with remote URLs for that, creating a symbolic name locally neither makes sense nor is it a lot of fun) Cher :) -- Christian Hujer Free software developer mailto:[EMAIL PROTECTED] http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB
pgp3Aixuoe92b.pgp
Description: PGP signature
_______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire