|
Replies:
25
-
Last Post:
Feb 7, 2007 11:41 AM
by: stevel
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
keywords in the post-Hg world
Posted:
Jan 29, 2007 1:45 PM
|
|
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
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
3) Port all keywords to 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.
My personal vote is to:
- Eliminate the #ident %Z% keywords (since the what(1) string is
replaced by the build, anyway).
- Replace %I% for module versions with the Hg revision number
Thoughts? Flames?
cheers,
steve
[1] http://www.opensolaris.org/jive/thread.jspa?messageID=39328
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
James C. McPher...
James.McPherson@Sun....
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 1:59 PM
in response to: stevel
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 2:23 PM
in response to: James C. McPher...
|
|
James C. McPherson wrote:
>
> 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?
Yeah, that's what I was trying to get at. The revision number is ONLY
specific to a repository - it has no meaning in any other repository.
i.e.: jmcp's revision 142 could be completely different from
/ws/onnv-gate's revision 142. This is the same behaviour as the SCCS
deltas though.
>> 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.
>
thanks for the input
cheers,
steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 2:46 PM
in response to: stevel
|
|
On Mon, 2007-01-29 at 14:23 -0800, Stephen Lau wrote:
> > 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?
>
> Yeah, that's what I was trying to get at. The revision number is ONLY
> specific to a repository - it has no meaning in any other repository.
> i.e.: jmcp's revision 142 could be completely different from
> /ws/onnv-gate's revision 142. This is the same behaviour as the SCCS
> deltas though.
why not include a scope, using the basename of the workspace/repo (or
some other repo-defined keyword) followed by the integer revision
number?
onnv-gate:142
on10-patch:142
jmcp-random-bugfix:142
This is more a proposal for what goes into places where %I% is used now;
the details (specific format, separator character, and interpolation
mechanism -- SCCS style? RCS-style? One keyword/token? Multiple
tokens?) need to be worked out.
- Bill
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 2:55 PM
in response to: sommerfe
|
|
Bill Sommerfeld wrote:
> On Mon, 2007-01-29 at 14:23 -0800, Stephen Lau wrote:
>>> 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?
>> Yeah, that's what I was trying to get at. The revision number is ONLY
>> specific to a repository - it has no meaning in any other repository.
>> i.e.: jmcp's revision 142 could be completely different from
>> /ws/onnv-gate's revision 142. This is the same behaviour as the SCCS
>> deltas though.
>
> why not include a scope, using the basename of the workspace/repo (or
> some other repo-defined keyword) followed by the integer revision
> number?
>
> onnv-gate:142
> on10-patch:142
> jmcp-random-bugfix:142
Sure, that seems fine to me... we can take the basename of 'hg root' and
append ':$revision' and it should get that.
Whoever has scripts (PTS?) that look for a monotonically increasing
aspect of that will have to do some trivial work to change it to parse
the rev # out of it - but that's a small price to pay.
> This is more a proposal for what goes into places where %I% is used now;
> the details (specific format, separator character, and interpolation
> mechanism -- SCCS style? RCS-style? One keyword/token? Multiple
> tokens?) need to be worked out.
I'd vote for RCS-style. How about $Rev$?
cheers,
steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 3:26 PM
in response to: James C. McPher...
|
|
>>>>> "jmcp" == James C McPherson <James dot McPherson at Sun dot COM> writes:
jmcp> Does the rev# change from my repo to that gate repo? Or rather,
jmcp> with the delivered binaries/files, whose rev# will I see if I run
jmcp> a modinfo on a module?
The implementation that we discussed would bake the revision string into
the (source) file when it is pushed/pulled into a repo. (I assume it
would also get set by the initial commit, and then changed when pushed
into the gate.)
So for delivered binaries/files, you'd see the revision as it appears in
the gate.
mike
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,253
From:
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 2:11 PM
in response to: stevel
|
|
On Mon, Jan 29, 2007 at 01:45:47PM -0800, Stephen Lau wrote:
> My personal vote is to:
> - Eliminate the #ident %Z% keywords (since the what(1) string is replaced
> by the build, anyway).
> - Replace %I% for module versions with the Hg revision number
One thing to note about replacing the ident line is that even files that
aren't compiled (shell scripts, data files, config files) have it, and that
some people may be relying on these lines in some weak form. For instance,
I will do a "what =nightly" (the "=" is a zsh-ism) to see what version of
nightly I'm running.
I agree that compiled objects don't really need the line, though it doesn't
hurt to have them in place (except for the extra work it'll cause the Tonic
team to figure out how to support them).
As for %I%, I'd really like to see a better solution than this. If nothing
else, the number is non-unique across workspaces (like %I% is, but more
so), although a pairing of that with the short changeset hash might be
interesting.
The real problem with driver versioning as it stands (and Steve's proposal)
is that when a driver is made up of multiple source files, modifying any
one of those ostensibly changes the driver. But the "version" is kept in
only one of those files. Thus the developer has to make a conscious
decision to apply an "empty delta" to the file with the version string in
order to bump it. That's not always done -- either deliberately or not --
and makes the version string next to useless.
My preference would be to replace it with the build date and/or the
changeset hash of tip when the gate was built. That's a lot of info to
shove into the modinfo line, so the question that gets raised in my mind
is, "what are the actual requirements from Sun's service folks and anyone
else who uses modinfo output to look for a version number?"
Aside from these two uses of keywords, do we care at all about the rest?
My off-the-cuff answer is "no, let's ditch 'em", but we should probably do
an analysis of how they're actually being used
Danek
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 8:42 PM
in response to: dduvall
|
|
> The real problem with driver versioning as it stands (and Steve's proposal)
> is that when a driver is made up of multiple source files, modifying any
> one of those ostensibly changes the driver. But the "version" is kept in
> only one of those files. Thus the developer has to make a conscious
> decision to apply an "empty delta" to the file with the version string in
> order to bump it. That's not always done -- either deliberately or not --
> and makes the version string next to useless.
>
> My preference would be to replace it with the build date and/or the
> changeset hash of tip when the gate was built. That's a lot of info to
> shove into the modinfo line, so the question that gets raised in my mind
> is, "what are the actual requirements from Sun's service folks and anyone
> else who uses modinfo output to look for a version number?"
I strongly second these points.
--
meem
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
812
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 11:05 PM
in response to: meem
|
|
On Tue 30 Jan 2007 at 12:42PM, Peter Memishian wrote:
>
> > The real problem with driver versioning as it stands (and Steve's proposal)
> > is that when a driver is made up of multiple source files, modifying any
> > one of those ostensibly changes the driver. But the "version" is kept in
> > only one of those files. Thus the developer has to make a conscious
> > decision to apply an "empty delta" to the file with the version string in
> > order to bump it. That's not always done -- either deliberately or not --
> > and makes the version string next to useless.
> >
> > My preference would be to replace it with the build date and/or the
> > changeset hash of tip when the gate was built. That's a lot of info to
> > shove into the modinfo line, so the question that gets raised in my mind
> > is, "what are the actual requirements from Sun's service folks and anyone
> > else who uses modinfo output to look for a version number?"
>
> I strongly second these points.
I've occasionally contemplated what it would be like to bump
MODREV_1 to, well, MODREV_2.
Among other changes to modules, I think the build date, builder, machine
info, contact information, stock symbol, etc. would be things I would
like to store in the driver (in an elf section I think) at build time,
and modinfo would be reworked to display the expanded info.
Well, I can dream...
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,172
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 30, 2007 8:09 AM
in response to: dp
|
|
Dan Price wrote:
> On Tue 30 Jan 2007 at 12:42PM, Peter Memishian wrote:
>> > The real problem with driver versioning as it stands (and Steve's proposal)
>> > is that when a driver is made up of multiple source files, modifying any
>> > one of those ostensibly changes the driver. But the "version" is kept in
>> > only one of those files. Thus the developer has to make a conscious
>> > decision to apply an "empty delta" to the file with the version string in
>> > order to bump it. That's not always done -- either deliberately or not --
>> > and makes the version string next to useless.
>> >
>> > My preference would be to replace it with the build date and/or the
>> > changeset hash of tip when the gate was built. That's a lot of info to
>> > shove into the modinfo line, so the question that gets raised in my mind
>> > is, "what are the actual requirements from Sun's service folks and anyone
>> > else who uses modinfo output to look for a version number?"
>>
>> I strongly second these points.
>
> I've occasionally contemplated what it would be like to bump
> MODREV_1 to, well, MODREV_2.
>
> Among other changes to modules, I think the build date, builder, machine
> info, contact information, stock symbol, etc. would be things I would
> like to store in the driver (in an elf section I think) at build time,
> and modinfo would be reworked to display the expanded info.
>
> Well, I can dream...
>
> -dp
>
Well, I'd like to make sure that no one tries to put this information
into the data segment since that would make wsdiff's job so much more
difficult.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber dot eng dot sun dot com http://blogs.sun.com/barts
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
770
From:
US
Registered:
6/17/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 2:12 PM
in response to: stevel
|
|
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
> 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
> 3) Port all keywords to 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.
>
> My personal vote is to:
> - Eliminate the #ident %Z% keywords (since the what(1) string is
> replaced by the build, anyway).
This isn't true of all consolidations (though I wish it was), I believe NWS
at least doesn't do the mcs post-process magic.
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,253
From:
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 2:15 PM
in response to: richlowe
|
|
On Mon, Jan 29, 2007 at 05:12:23PM -0500, Richard Lowe wrote:
> This isn't true of all consolidations (though I wish it was), I believe
> NWS at least doesn't do the mcs post-process magic.
I have to say, as fascist as Matt Simmons was, I certainly can appreciate
his desire for the whole world (or select pieces thereof) to be like ON. :)
Danek
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 2:24 PM
in response to: richlowe
|
|
Richard Lowe wrote:
> 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
>> 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
>> 3) Port all keywords to 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.
>>
>> My personal vote is to:
>> - Eliminate the #ident %Z% keywords (since the what(1) string is
>> replaced by the build, anyway).
>
> This isn't true of all consolidations (though I wish it was), I believe
> NWS at least doesn't do the mcs post-process magic.
True - but this isn't a mandate for NWS. If NWS wants to keep them,
they are welcome to.
-steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Jan 29, 2007 5:07 PM
in response to: stevel
|
|
Sending this to opensolaris-code for additional feedback, thoughts...
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
> 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
> 3) Port all keywords to 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.
>
> My personal vote is to:
> - Eliminate the #ident %Z% keywords (since the what(1) string is
> replaced by the build, anyway).
> - Replace %I% for module versions with the Hg revision number
>
> Thoughts? Flames?
>
> cheers,
> steve
>
> [1] http://www.opensolaris.org/jive/thread.jspa?messageID=39328
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 5, 2007 5:09 PM
in response to: stevel
|
|
Just to poke this thread some more, the overwhelming consensus I've seen
has been to:
- Stop using keywords for module versions
I'd like to just eliminate the use of keywords entirely, if this is the
case. There doesn't seem to be a use for them, other than the
misleading use of modinfo to determine a driver version. And it's been
sufficiently pointed out in this thread that that is a poor decision
given the other better alternatives.
Does anyone see a problem with dropping keywords in their entirety?
If people see the need for versioning beyond what is available via 'mcs
-p', mdb's ::showrev, etc. - we could look into embedding something
about the build repository & changeset tip into an ELF section
somewhere, but this may require modifications to modinfo/what to support
that. (We could either create a new section and make wsdiff skip it, or
add to .comment).
cheers,
steve
* For those interested, I did write up a Mercurial keywords extension -
and it worked, but it brought the time to do a 'hg clone' up from 2m41s
to 20m32s. Obviously this is undesirable :)
Stephen Lau wrote:
> Sending this to opensolaris-code for additional feedback, thoughts...
>
> 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
>> 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
>> 3) Port all keywords to 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.
>>
>> My personal vote is to:
>> - Eliminate the #ident %Z% keywords (since the what(1) string is
>> replaced by the build, anyway).
>> - Replace %I% for module versions with the Hg revision number
>>
>> Thoughts? Flames?
>>
>> cheers,
>> steve
>>
>> [1] http://www.opensolaris.org/jive/thread.jspa?messageID=39328
>
>
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,795
From:
GB
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 6, 2007 12:47 AM
in response to: stevel
|
|
Stephen Lau wrote:
> Just to poke this thread some more, the overwhelming consensus I've seen
> has been to:
>
> - Stop using keywords for module versions
>
> I'd like to just eliminate the use of keywords entirely, if this is the
> case. There doesn't seem to be a use for them, other than the
> misleading use of modinfo to determine a driver version. And it's been
> sufficiently pointed out in this thread that that is a poor decision
> given the other better alternatives.
>
> Does anyone see a problem with dropping keywords in their entirety?
No problem at all in fact quite the opposite it is a good thing to drop
keywords they only confuse people in to thinking they have information
that they really don't have.
I also talked to some Sun field engineers who initally said that we
should keep this, I think explained all the caveats that were discussed
here and they instantly changed their mind to drop keywords.
--
Darren J Moffat
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
James C. McPher...
James.McPherson@Sun....
|
|
|
|
Re: [osol-code] Re: keywords in the post-Hg world
Posted:
Feb 6, 2007 2:13 AM
in response to: darrenm
|
|
Darren J Moffat wrote:
> Stephen Lau wrote:
>> Just to poke this thread some more, the overwhelming consensus I've
>> seen has been to:
>>
>> - Stop using keywords for module versions
>>
>> I'd like to just eliminate the use of keywords entirely, if this is
>> the case. There doesn't seem to be a use for them, other than the
>> misleading use of modinfo to determine a driver version. And it's
>> been sufficiently pointed out in this thread that that is a poor
>> decision given the other better alternatives.
>>
>> Does anyone see a problem with dropping keywords in their entirety?
>
> No problem at all in fact quite the opposite it is a good thing to drop
> keywords they only confuse people in to thinking they have information
> that they really don't have.
>
> I also talked to some Sun field engineers who initally said that we
> should keep this, I think explained all the caveats that were discussed
> here and they instantly changed their mind to drop keywords.
I also had misgivings about dropping keywords, but then I stood
back for a few minutes and thought about it.
We've got a unique hash which identifies "binary X". We can create
a publishable mapping (ie, on sunsolve) between that hash and the
version of the source that it is based on.
The various automagical tools that Support Services people make
use of can definitely be re-targeted to make use of said hash(es).
My remaining concern is/was secure sites, where Sun has to send
an SSE onsite to do things. Reading a unique hash over the phone
line is going to be a pain in the rear (and yes, it will happen),
but I think the benefits of the hash will outweigh the downsides.
Steve: full speed ahead!
cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,795
From:
GB
Registered:
3/9/05
|
|
|
|
Re: [osol-code] Re: keywords in the post-Hg world
Posted:
Feb 6, 2007 2:36 AM
in response to: James C. McPher...
|
|
James C. McPherson wrote:
> Darren J Moffat wrote:
>> Stephen Lau wrote:
>>> Just to poke this thread some more, the overwhelming consensus I've
>>> seen has been to:
>>>
>>> - Stop using keywords for module versions
>>>
>>> I'd like to just eliminate the use of keywords entirely, if this is
>>> the case. There doesn't seem to be a use for them, other than the
>>> misleading use of modinfo to determine a driver version. And it's
>>> been sufficiently pointed out in this thread that that is a poor
>>> decision given the other better alternatives.
>>>
>>> Does anyone see a problem with dropping keywords in their entirety?
>>
>> No problem at all in fact quite the opposite it is a good thing to
>> drop keywords they only confuse people in to thinking they have
>> information that they really don't have.
>>
>> I also talked to some Sun field engineers who initally said that we
>> should keep this, I think explained all the caveats that were
>> discussed here and they instantly changed their mind to drop keywords.
>
> I also had misgivings about dropping keywords, but then I stood
> back for a few minutes and thought about it.
>
> We've got a unique hash which identifies "binary X". We can create
> a publishable mapping (ie, on sunsolve) between that hash and the
> version of the source that it is based on.
Why is it needed that you map a given random binary to source files ?
The wsdiff tool may help here though.
Sun already has the finger print database which maps the binaries going
back all the way to Solaris 2.0 and patches to MD5 hashes.
> The various automagical tools that Support Services people make
> use of can definitely be re-targeted to make use of said hash(es).
>
> My remaining concern is/was secure sites, where Sun has to send
> an SSE onsite to do things. Reading a unique hash over the phone
> line is going to be a pain in the rear (and yes, it will happen),
> but I think the benefits of the hash will outweigh the downsides.
It isn't that hard, plus even on secure sites like that you should be
able to get the hashes off site after all they are public information
after all!
--
Darren J Moffat
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
James C. McPher...
James.McPherson@Sun....
|
|
|
|
Re: [osol-code] Re: keywords in the post-Hg world
Posted:
Feb 6, 2007 2:42 AM
in response to: darrenm
|
|
Darren J Moffat wrote:
> James C. McPherson wrote:
....
>> We've got a unique hash which identifies "binary X". We can create
>> a publishable mapping (ie, on sunsolve) between that hash and the
>> version of the source that it is based on.
>
> Why is it needed that you map a given random binary to source files ?
> The wsdiff tool may help here though.
ignore wsdiff for the moment, and remember that not everybody
out there in Services-land cares about the source, just the
mapping of patch numbers to bugids. That is why we need it.
> Sun already has the finger print database which maps the binaries going
> back all the way to Solaris 2.0 and patches to MD5 hashes.
I was wondering when you'd bring that up.
As I mentioned to Rich Lowe on irc a little while ago, this has
turned into one of those "oh, we've got a nifty tool to do that
already ... just nobody used it" kinda scenarios. Time, I think,
for some evangelising on the fingerprint db.
>> The various automagical tools that Support Services people make
>> use of can definitely be re-targeted to make use of said hash(es).
>>
>> My remaining concern is/was secure sites, where Sun has to send
>> an SSE onsite to do things. Reading a unique hash over the phone
>> line is going to be a pain in the rear (and yes, it will happen),
>> but I think the benefits of the hash will outweigh the downsides.
>
> It isn't that hard, plus even on secure sites like that you should be
> able to get the hashes off site after all they are public information
> after all!
And the other already-invented-here response is "gee, that would
appear to be tailor made for including on the EIS distribution."
So to me, it looks like problem solved.
cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,795
From:
GB
Registered:
3/9/05
|
|
|
|
Re: [osol-code] Re: keywords in the post-Hg world
Posted:
Feb 6, 2007 2:52 AM
in response to: James C. McPher...
|
|
James C. McPherson wrote:
> Darren J Moffat wrote:
>> James C. McPherson wrote:
> ....
>>> We've got a unique hash which identifies "binary X". We can create
>>> a publishable mapping (ie, on sunsolve) between that hash and the
>>> version of the source that it is based on.
>>
>> Why is it needed that you map a given random binary to source files ?
>> The wsdiff tool may help here though.
>
> ignore wsdiff for the moment, and remember that not everybody
> out there in Services-land cares about the source, just the
> mapping of patch numbers to bugids. That is why we need it.
Patch numbers to bugids is nothing to do with the source and sunsolve
already provides that mapping via the patch readmes.
Patches really have very little to do with putbacks/changesets because
of the way patch breakdown and rollup occurs.
>> Sun already has the finger print database which maps the binaries
>> going back all the way to Solaris 2.0 and patches to MD5 hashes.
>
> I was wondering when you'd bring that up.
>
> As I mentioned to Rich Lowe on irc a little while ago, this has
> turned into one of those "oh, we've got a nifty tool to do that
> already ... just nobody used it" kinda scenarios. Time, I think,
> for some evangelising on the fingerprint db.
Maybe if the link on the front page of the internal and external
sunsolve for it was moved from the security section people might use it
more :-)
--
Darren J Moffat
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 7, 2007 10:45 AM
in response to: stevel
|
|
I've updated the SCMMigrationTasks page on the genunix wiki. The
'implement keywords' task has now become 'strip SCCS keywords from ON'.
That should be a fun putback for someone to do ;-)
cheers,
steve
Stephen Lau wrote:
> Just to poke this thread some more, the overwhelming consensus I've seen
> has been to:
>
> - Stop using keywords for module versions
>
> I'd like to just eliminate the use of keywords entirely, if this is the
> case. There doesn't seem to be a use for them, other than the
> misleading use of modinfo to determine a driver version. And it's been
> sufficiently pointed out in this thread that that is a poor decision
> given the other better alternatives.
>
> Does anyone see a problem with dropping keywords in their entirety?
>
> If people see the need for versioning beyond what is available via 'mcs
> -p', mdb's ::showrev, etc. - we could look into embedding something
> about the build repository & changeset tip into an ELF section
> somewhere, but this may require modifications to modinfo/what to support
> that. (We could either create a new section and make wsdiff skip it, or
> add to .comment).
>
> cheers,
> steve
>
> * For those interested, I did write up a Mercurial keywords extension -
> and it worked, but it brought the time to do a 'hg clone' up from 2m41s
> to 20m32s. Obviously this is undesirable :)
>
> Stephen Lau wrote:
>> Sending this to opensolaris-code for additional feedback, thoughts...
>>
>> 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
>>> 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
>>> 3) Port all keywords to 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.
>>>
>>> My personal vote is to:
>>> - Eliminate the #ident %Z% keywords (since the what(1) string is
>>> replaced by the build, anyway).
>>> - Replace %I% for module versions with the Hg revision number
>>>
>>> Thoughts? Flames?
>>>
>>> cheers,
>>> steve
>>>
>>> [1] http://www.opensolaris.org/jive/thread.jspa?messageID=39328
>>
>>
>
>
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 7, 2007 10:53 AM
in response to: stevel
|
|
as Rich just reminded me - this should preferably be scriptable, so we
can run it just prior to putback.
cheers,
steve
Stephen Lau wrote:
> I've updated the SCMMigrationTasks page on the genunix wiki. The
> 'implement keywords' task has now become 'strip SCCS keywords from ON'.
> That should be a fun putback for someone to do ;-)
>
> cheers,
> steve
>
> Stephen Lau wrote:
>> Just to poke this thread some more, the overwhelming consensus I've
>> seen has been to:
>>
>> - Stop using keywords for module versions
>>
>> I'd like to just eliminate the use of keywords entirely, if this is
>> the case. There doesn't seem to be a use for them, other than the
>> misleading use of modinfo to determine a driver version. And it's
>> been sufficiently pointed out in this thread that that is a poor
>> decision given the other better alternatives.
>>
>> Does anyone see a problem with dropping keywords in their entirety?
>>
>> If people see the need for versioning beyond what is available via
>> 'mcs -p', mdb's ::showrev, etc. - we could look into embedding
>> something about the build repository & changeset tip into an ELF
>> section somewhere, but this may require modifications to modinfo/what
>> to support that. (We could either create a new section and make
>> wsdiff skip it, or add to .comment).
>>
>> cheers,
>> steve
>>
>> * For those interested, I did write up a Mercurial keywords extension
>> - and it worked, but it brought the time to do a 'hg clone' up from
>> 2m41s to 20m32s. Obviously this is undesirable :)
>>
>> Stephen Lau wrote:
>>> Sending this to opensolaris-code for additional feedback, thoughts...
>>>
>>> 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
>>>> 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
>>>> 3) Port all keywords to 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.
>>>>
>>>> My personal vote is to:
>>>> - Eliminate the #ident %Z% keywords (since the what(1) string is
>>>> replaced by the build, anyway).
>>>> - Replace %I% for module versions with the Hg revision number
>>>>
>>>> Thoughts? Flames?
>>>>
>>>> cheers,
>>>> steve
>>>>
>>>> [1] http://www.opensolaris.org/jive/thread.jspa?messageID=39328
>>>
>>>
>>
>>
>
>
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,813
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 7, 2007 11:30 AM
in response to: stevel
|
|
Stephen Lau writes:
> I've updated the SCMMigrationTasks page on the genunix wiki. The
> 'implement keywords' task has now become 'strip SCCS keywords from ON'.
> That should be a fun putback for someone to do ;-)
"not it!"
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Stephen Hahn
sch@eng.sun.com
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 7, 2007 11:35 AM
in response to: carlsonj
|
|
* James Carlson <james dot d dot carlson at sun dot com> [2007-02-07 11:30]:
> Stephen Lau writes:
> > I've updated the SCMMigrationTasks page on the genunix wiki. The
> > 'implement keywords' task has now become 'strip SCCS keywords from ON'.
> > That should be a fun putback for someone to do ;-)
>
> "not it!"
That seems more than fair. Couldn't we make the keywords removal an
incremental process, via one of the code cleanliness filters? (As we
did for the CDDL version change...)
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen dot hahn at sun dot com http://blogs.sun.com/sch/
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,253
From:
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 7, 2007 11:38 AM
in response to: Stephen Hahn
|
|
On Wed, Feb 07, 2007 at 11:35:52AM -0800, Stephen Hahn wrote:
> That seems more than fair. Couldn't we make the keywords removal an
> incremental process, via one of the code cleanliness filters? (As we
> did for the CDDL version change...)
For generic ident strings and the handful of other random uses of keywords,
that's perfectly reasonable. I think for the module versioning, that
should be taken care of all at once.
Danek
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,156
From:
US
Registered:
3/9/05
|
|
|
|
Re: keywords in the post-Hg world
Posted:
Feb 7, 2007 11:41 AM
in response to: Stephen Hahn
|
|
Stephen Hahn wrote:
> * James Carlson <james dot d dot carlson at sun dot com> [2007-02-07 11:30]:
>> Stephen Lau writes:
>>> I've updated the SCMMigrationTasks page on the genunix wiki. The
>>> 'implement keywords' task has now become 'strip SCCS keywords from ON'.
>>> That should be a fun putback for someone to do ;-)
>> "not it!"
>
> That seems more than fair. Couldn't we make the keywords removal an
> incremental process, via one of the code cleanliness filters? (As we
> did for the CDDL version change...)
Sure, they're not harmful to leave in the Hg sources... though the
modversioning ones might be worth taking out more proactively.
-steve
--
stephen lau // stevel at sun dot com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
tools-discuss at opensolaris dot org
|
|
|
|
|
