James Carlson wrote:
> Ali Bahrami writes:
>> Of course this is not perfectly seamless --- the person integrating
>> process_mapfile will still be confronted with some confusing errors,
>> and will have to augment the exception file to make them go away.
>
> Right; there'll need to be some sort of guidance to other gatelings
> about fixing such problems either way. But how many of these
> "special" files exist? If we're talking about four or five files that
> have crept into the 30K+ ON file list over the last 20+ years, then
> maybe it's not something to worry too much about.
Meaning "just go ahead and change em," or "leave 'em as they are"?
>> Note that mapfilechk itself falls foul of this. I thought
>> about mapchk (a bit generic), or map-filechk, or other other
>> permutations, but I think mapfilechk is really the best name
>> for it, and fits the pattern set by the other tool names.
>
> There are other permutations possible here, including saying that
> users must name their mapfile either exactly "mapfile" or
> "mapfile_<something>", and all others go unchecked.
>
> I don't feel strongly about it. It just seemed like a simple fix to
> me when faced with the twin problems of delivering a default .NOT file
> (how?) and making .NOT processing work right.
This was my suggestion, and was related to our mutual dissatisfaction
with some of the findunref work from the tools integration.
Basically, the tools currently check for
${REPO}/.hg/cdm/${tool}.NOT
and exclude entries there. This is directly analagous to the
${CODEMGR_WS}/wx/${check}.NOT files that folks used with Teamware/wx.
I suggested that Ali add, in addition, the file
${REPO}/exception_lists/${tool}
which, if existent, would specify on a tracked, per-repository basis
files that were known to not be compliant with particular checks.
On further thought, it seems like there's overlap, right? *.NOT entries
SHOULD, on integration, be migrated into exception_list/* files.
?
>> The issue with cadmium however is orthogonal to this. Whether or
>> not I provide an exception mechanism for mapfilechk, cadmium's
>> .NOT processing isn't right, and needs a fix.
>
> Agreed; that's .NOT right. ;-}
Indeed.
>> > In either case, the changes should be quite easy to test using a
>> > binary compare (nightly -w).
>>
>> In the context of my mapfile project (6785284), we have already
>> discussed the idea of having the nightly builds verify that the
>> versioning details of a given object have not changed, or if they
>> have, of flagging them so that the gatekeepers will note the change
>> and ask about it. I've also been thinking that it would not be
>> difficult to augment wsdiff to make that comparison --- it's on
>> my list to look into, right after mapfilechk.
>
> Actually, what I was saying was that renaming the files (even old
> ones) shouldn't be rejected just out of hand, because testing to make
> sure that the change itself was complete and correct would be fairly
> trivial, and wouldn't involve re-running any special test suites.
>
> Adding a version number change check to '-w' is an added dimension.
> It sounds like a worthwhile thing to me, and something that wouldn't
> suffer from any of the file name problems that checking map files
> would. I agree that it's separate.
You're now talking about checking the shared objects, instead of the
mapfiles. Seems reasonable, but I still would like mapfile changes to
be more directly tested, even when wsdiff is not invoked.
--Mark
