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 Shawn. -- James Carlson wrote: > Valerie Bubb Fenwick writes: > >> On Fri, 27 Jun 2008, Will Fiveash wrote: >> >>> On Fri, Jun 27, 2008 at 09:46:11AM -0400, James Carlson wrote: >>> >>>> For now, until the transition, leave them in place as they are, and do >>>> *NOT* build any code that relies on those strings. (Such code was >>>> almost invariably kludgey anyway.) >>>> >>>> >> Actually, Jim, our recommendation is to start removing them now. >> > > Actually, Valerie, you've misunderstood what I wrote. I'll try again. > > Leave the SCCS %.% ident strings themeselves in place. That's the > stuff that's in the current prototype files and checked by the current > tools (including both the 'wx' that's in the ON gate and the one in > the SCM Migration gate). We shouldn't change any rules until the > prototype files themselves and the tools change. > > Don't remove them yet. > > However, do *not* build any code that relies on the contents of those > strings. If you do have such code, rip it out. Do it as soon as > you're able, and search with sunsolve first (as we probably filed a > bug on it some time ago). That includes swilly printf("My version is > %I%\n") stuff. Such code, as I noted above, is and was almost > invariably kludgey anyway -- that includes code using a "program > version number" extracted from an SCCS ID from a single file out of > dozens or more that were part of an executable. > > If you absolutely, _positively_ must do so, then create a file that > you update manually with some version number that's of meaning to you. > I strongly recommend against doing this, though. There's no good > reason for it -- version numbers come for free in the packaging, and > those version numbers actually mean something useful about the > software, rather than just being an artifact of how it was built. > > >> The SCM migration team will not be, to the best of my knowledge, fixing >> all of these instances themselves - that's why they filed bugs, to help >> share the load (and let the subject matter experts decide how they >> wanted to handle version strings going forward and fix any kludgey code) >> > > True, but returning to the original poster's question in this > particular case: existing and new files (until the Mercurial > transition) should be built with SCCS keywords strings. Using "wx" > will make sure that this happens. > > When we switch over, folks will type "hg nits" instead of "wx nits." > The copyright checks in the Mercurial tools have the opposite > assertion: they request that you yank out SCCS keywords strings, as > they're no longer meaningful for files integrated via Mercurial rather > than via Teamware. > > It might have been possible to demand that folks stop putting SCCS > keywords into new files prior to the transition, but that's not what > we decided to do in the interest of having a "clean" transition. > >
