Just what Jim said, only without the "but seriously now" caveat. Telling people not to do something is great, but we need to get out of the temporary state where they're able to somehow get away with it.
--Mark > Mike Kupfer writes: >> I've got a mail filter that flags putback notifications that touch a >> class action script. Every couple months I've been reviewing the >> accumulated putback notices to make sure nobody has introduced new >> dependencies on SCCS keywords. >> >> Can someone think of a better way to keep the class action scripts >> clean? Can we assume that the chances of introducing a new dependency >> are sufficiently slim that this isn't worth worrying about? > > Probably the very best way to do this would be to get the gates and > gatelings moved over to Mercurial quickly so that such treachery won't > work any more than trying to check for $Id$ strings. ;-} > > Seriously, though, I don't think there's a lot that we can automate > here. I noticed when searching for and fixing class action scripts > that there are *many* clever ways to go wrong, and I suspect an > automated checker would just introduce a false sense of security. > > I think a note to the RTI Advocates would probably be a better > approach. > > -- > 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 > _______________________________________________ > scm-migration-dev mailing list > scm-migration-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/scm-migration-dev >
