Hi Stephen,
Stephen Lau wrote:
We've had contentious discussion on this already [1], but we need to get
resolution on this to move forward on the SCM Migration.
Mike Kupfer & Danek noted that the following are currently in use:
%?% (not an SCCS keyword)
%D% current date (yy/mm/dd)
%E% date of newest delta (yy/mm/dd)
%G% date of newest delta (mm/dd/yy)
%H% current date (mm/dd/yy)
%I% SID (%R%.%L%.%B%.%S%)
%L% level (see %I%)
%M% module name
%N% (not an SCCS keyword)
%R% release (see %I%)
%T% current time (hh:mm:ss)
%U% time of newest delta (hh:mm:ss)
%W% shorthand for %Z%%M%\t%I%
%X% (not an SCCS keyword)
%Z% what(1) marker ("@(#)")
%e% (not an SCCS keyword)
%s% (not an SCCS keyword)
The options I've seen are:
1) Eliminate the use of keywords entirely
I'm not keen on this option, unless you/we/us can come up with
some whizbang blindingly obvious replacement.
2) Eliminate the #ident %Z% keywords (which is the bulk of the keyword
usage in onnv), and port the remaining ones to a new format
Seems like a good thing.
3) Port all keywords to a new format
Better - we've got the opportunity to make a big change, so it seems
an ideal time to go for a new format.
The most contentious issue seems to be the use of %I% in modules such as
drivers. (James & Alan: this is why I've cc'd you, since I don't know
who else would know people in PTS who might have an opinion). The
general consensus from the ON developers I've talked to is that the use
of %I% to identify module versions is.... poor. That being said, PTS
uses it - for better or for worse. One thought that we had was to
replace it with the the Mercurial monotonically-increasing revision
number (not the 12 character hex hash). It gives the ever-increasing
factor that people may expect, but doesn't identify uniqueness (since
the revision number is relative to each repository). However, this is
the same behaviour as %I% - so perhaps it's okay.
I like the monotoically increasting revision number aspect - it's
something that Support ppl (not that I'm one any more) can use with
automated tools as well as onsite etc.
Does the rev# change from my repo to that gate repo? Or rather,
with the delivered binaries/files, whose rev# will I see if I
run a modinfo on a module?
My personal vote is to:
- Eliminate the #ident %Z% keywords (since the what(1) string is
replaced by the build, anyway).
+1
- Replace %I% for module versions with the Hg revision number
Subject to my questions above, a +1 on this from me.
cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
