On Mon, 2008-07-07 at 17:28 -0400, James Carlson wrote: > Shawn M Emery writes: > > > > In the near future it would be nice to have some form of keyword > > expansion whether in one form or another. If everyone is in agreement > > then we may want to consider the keyword extension for mercurial which > > allows fairly easy interface to expand and contract keywords: > > > > http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension > > I'm certainly not in agreement. All of the uses I've seen so far of > keywords have been swill -- places where someone thought that the SCCS > ID number on a single file somehow correctly labeled an entire module > version, and where we were doing obviously at-best-questionable > design. It may as well have printed __FILE__, __LINE__ and __DATE__. > > If we're to have version numbers printed by utilities at all, then at > a minimum, let's make them administratively useful. They should > relate _directly_ to the version number advertised as part of the > packaging system so that we don't have to play fetch-a-rock with > module versus package versus system revision history. This stuff > should obviously work together rather than just being disjoint bits. > > (Having a big database of MD5 and SHA-1 checksums searchable on > checksum is a nifty hack around the problem ... but it's still a > problem, and shouldn't need a hack. You should be able to go directly > from advertised version number to verified checksum in one step.) > > Short of that, please, no %I% or $Rlog$ spewage. We've got a nice > chance to clean up some ugly history here.
All of this makes perfect sense for ON, Solaris etc. In our case we would like to have a single versioned script available for people to download and run on their systems for diagnostic purposes. No install, no package, no entry in any database anywhere. We can version the single file manually but we'd like to avoid that... -Mark
