-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Micah Cowan wrote: > To group: It seems to me that the questions I'm asking Chris right now > are going to be common ones, unless we change the trunk Wget's version > to give some indication as to when its last update was performed. > > We could use the output of svnversion in the version string itself, as > described in > http://subversion.tigris.org/faq.html#version-value-in-source . I'd > probably also want to have development versions of svn describe their > path, so that it will tell us when it actually came from a bugbranch, etc. > > What do you think? I've submitted a bug against this at: > https://savannah.gnu.org/bugs/index.php?20358
I've done some basic, preliminary work towards this end: http://addictivecode.org/pipermail/wget-notify/2007-July/000011.html However, I'm not satisfied with the direction this fix is taking (essentially, include the output of svnversion in the version string). For one thing, it's completely useless if it is built by someone who exported the source, rather than checked it out. For another, it doesn't distinguish between different branches within the same revision. If we do add a --bug option as Tony suggested, then perhaps it would be useful to add: extern const char *FOO_id = "$URL$ $Rev$"; to the top of every file FOO.c. Then we could have --bug spit out all of these; this would allow us to determine precisely where each file came from, and what branch. As a bonus, we could throw in MD5 checksum strings as well, so we can note if any of the files have been changed (I'm not sure how useful that'd truly be, though, as (a) it'll make dealing with small changes from downstream packagers more cumbersome, and (b) we'll have to do something a little fancy to deal with line-ending discrepancies between platforms). One issue with this is it still doesn't deal with changes to .h files. We could use macros for those, I suppose, but the problem is that this will only tell you what version of the .h file got #included by the module that implements --bug, and none of the other modules: so if some things got recompiled, but not other things, this information may be misleading (though, perhaps, a little better than nothing). It _might_ be nice to have something update the version number (to something like wget-1.11rYYYYMMDD[.N]) whenever a change is made. Since, in general, I'll be handling changes to the trunk and release branches in the form of merging bug branches in, it would be easy enough to roll a tool that combines bug merging with updating the version stamp, but I'm not sure that's what I want to do since (a) it makes it harder to deal with really trivial bug fixes, and (b) it removes the opportunity for devs to go ahead and merge their own changes in--say, when I'm on vacation for a few weeks or whatnot, or the change is truly a no-brainer, or... Anyway, these are the things I'm currently pondering, and I'd love to get some feedback or new ideas. Maybe the "problem" isn't even really big enough to deserve a solution, I dunno... but it would be nice. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGktlR7M8hyUobTrERCF/+AJ9kJvRbqMZMdOK7iPjOD24AEmBETACeNP8H CnaTXk9RMvTz3bwBKOzX9lI= =LjMF -----END PGP SIGNATURE-----
