> > 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'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).
> > 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.
- Bill
