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.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
