Bill Sommerfeld <sommerfeld at sun.com> writes: >> > WES-3 Should we set CODEMGR_WS in the non-teamware case? >> >> We've been back and forth a few times on the use of CODEMGR_WS, my >> view (which I think was shared by stevel) is that CODEMGR_WS, while >> originally used by and for teamware, has effectively become generic at >> this point, and that picking different variables to hold the workspace >> root merely because the SCMs differ would create yet another thing for >> users and the tools to keep track of with little benefit. > > what I think would make sense would be to set a different, > non-teamware-specific variable. So a teamware workspace would get > CODEMGR_WS and the TBD additional variable; mercurial would just get the > TBD additional variable.
I'll leave that for others (Mike?) to comment on, I think. I'm still not entirely sold either way. >> I'm taking that to mean "Why did wx change, other than to complain >> about hg?". > > Yes. > >> The original plan (sch, stevel's, and to a lesser extent >> mine) was that to the greatest degree possible everything should use a >> common set of code for the checks, which in this respect was the new >> code. > > ok. > >> > WES-11 Lines 2435-2448: doesn't hg have a different way of recording the >> > committer's name in .hgrc ? Shouldn't we use that if available? >> >> It does, and that specifies the author name in the changeset. Do you >> mean that we should attempt to pull the information that Hg would make >> use of out of their settings, or that we should attempt to reflect the >> info in their actual changeset (as they may differ). >> >> (if there's more than one changeset, there maybe more than one author, >> too. I'm not sure how that would fit in) > > I'd think that the way to go would be to use the author info from the > outgoing committed changeset(s), or, in the case where the webrev > contains changes not yet in a changeset, the author info that hg *would* > use for an "hg commit". (This is probably something that could be > cleaned up after the initial putback). Ok. >> > usr/src/tools/scripts/nightly.sh >> > >> > WES-13 I thought bringovercheck was going to be nuked as part of this wad. >> >> That was my original plan, yes. But we will be integrating to onnv >> while TeamWare is still in use, both for ON and SFW, bringoverchk has >> to stay around until all the gates using it are no longer using >> teamware, at least. > > Last I checked, the bugs that spawned bringovercheck have pretty much > all been slain, so it could be retired now even for teamware. > Hm, in that case I think, again, it'd be best if I left that for others to respond to. Thanks, -- Rich
