>>>> 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. > > Some of the scripts used to also verify CRs against bugtraq+, > but that all broke when we migrated to bt2 :) > > They tend to check for merge turds, multiple deltas, ident string > issues (all those go away, right?), copyright correctness, files in conflict > or uncommitted, and packaging correctness.
These five are all correctly dealt with by hg pbchk: - Merge turds change, they don't go away. - Ident string issues become "is it present?" instead of "is it wrong?" - copyright correctness is unchanged - files in conflict becomes branchchk - uncommitted files don't change This one doesn't change at all: - packaging correctness is unrelated to SCM >>>> 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. > Okay, so I should probably add a general high level note like: > * Mixed (closed and open) source integrations > - You should have one RTI with all of the relevant output, as > outlined below and in webRTI, for both gates. Yes, that is correct, though you might want to also say explicitly that they will need to do two hg pushes, one from each repo. >>>> 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. > > Do you think the above high level note is sufficient? As modified, it's gettin' there. :) --Mark
