>> SCM folks: Do you have any advice on this section? >> >> Advocates >> ... >> * Workspace checking is highly recommended, as it is easy and quick and has >> prevented many problems; also, many problems which could have easily >> been prevented were from workspaces which were not checked. >> >> I don't think we have any workspace checking scripts yet for advocates >> based on mercurial, do we ? ( a question I've also asked the CRT....) >> >> Or would a CRT be able to safely run "hg pbchk" on someone else's >> gate? (it's not generally possible to run "wx" on someone else's >> gates, due to permission issues with the wx files) > > It should be possible, unless the permissions on .hg/ cause similar > problems. > > There is no wschk under Mercurial at this point, no.
Ditto on both. Don't know of any workspace checking scripts. If I recall correctly, the benefits generally fall into two categories: (ab)use of sccs, and "insufficient knowledge of packaging details." The former goes away, and the latter is still valid. >> I'll do the appropriate <code> markup</code> in the actual document, >> but wanted to spare you all the headache of parsing an HTML document. >> >> One open question: How do we expect to handle bug fixes that cross >> closed & open source? I believe the answer is all in one RTI, but >> I figure this document would be a good place to cover it. > > That would be my answer, but the 3 of you have a better idea of that > than I would. Yes. One RTI. Two "hg push" commands. The output of two "hg outgoing -v" commands in the RTI. >> Original: >> http://opensolaris.org/os/community/on/crt/rti-nits/ >> >> SCCS Keywords >> * For Nevada builds 97 and later: >> - ident usage (whether #pragma, ident, or .ident) should be cleaned up >> incrementally. If you touch a file, you should remove these strings. >> The hg keywords (part of hg nits and hg pbchk) command should >> correctly complain about this. So look for clean hg keywords output. >> - Any other usage SHOULD have been cleaned up prior to the Mercurial >> transition, but it's possible that some was missed. For this, please >> advise the developer to remove the usage entirely. If that is an >> unacceptable answer, and you deem the usage to be an interface, the >> keywords may be replaced with their static expansion (or incremented >> therefrom), or the user may use "hg id" or "hg log" output for >> version information. The hg id command refers to the entire >> repository, while the hg log command refers to a file or set of files. >> * For Solaris 10 Updates and older sustaining releases: >> - same text we have now (with the note on %I% being removed once 96 is >> closed. > > Given this page is ON-specific, I guess we don't need to be clearer > about this only applying to gates in Mercurial (and that being the > difference between 10 and NV)? > >> The following "paperwork items" in the bug (CR) should be done: >> .... >> * With respect to the Suggested Fix text, .... >> - Each source module's full path (e.g., usr/src/.../foo.c) should be >> specified in the Suggested Fix text. Further, this text field should >> contain the diffs for each affected module. Context diffs (diff -c or >> diff -u, or sccs diffs -C or hg pdiff) are preferred if they will fit. >> ... >> - ... disappear shortly after integration. [ was: "putback" ] >> ... >> - The diffs should be pointing the "right" way. webrev, sccs diffs >> and hg pdiff will get this right; using diff from the command line, >> make sure you do diff old new. >> ... >> >> * For Nevada builds 97 and later, the RTI should have your `hg outgoing -v` >> in the putback -n section and a pointer to your webrev in the comments >> section. For Solaris 10 updates and older sustaining releases, the RTI >> should also have your `putback -n` in the putback -n section and a >> pointer to your webrev in the comments section. Should probably mention that, if you changed code in both open and closed repos, you'll need the output of "hg outgoing -v" for both. Similarly for webrev pointers. >> ... >> >> * Other more general nits: >> - No bug IDs in the source code; the sccs delta comments and >> the Mercurial changeset descriptions cover that. > > "or the" not "and the", I think.
