David, I've fixed the minor ordering issues you listed and I've now submitted the WebRTI.
> please do confirm that your SCCS comment is simply > the one for 6521207. Yes - I confirm this. I'm aware that I'll need to do some filemerging when I putback, as both my workspaces edit some of the same files, but luckily I have some practice with teamware merging now ;) - Dermot David.Comay at sun.com wrote: > Dermot, > >>> webrev-bison-03 >>> =============== >>> > >>> One comment concerning "webrev" or perhaps your wx active file. It >>> looks like you have the CR listed as "6521207," (note the trailing >>> comma) rather than "6521207". > >> I didn't realize the sccs comment would be used >> like this. I've re-done all the changes, removing >> the comma after the bugid. > > It will be used if you're using "wx" to manage your SCCS comments. > Otherwise, it's just for the webrev output and you need to manage the > comments manually. > >>> usr/src/cmd/bison/install-sfw >>> usr/src/cmd/bison/install-bison >>> >>> The changes between these two files are fine but I want to >>> confirm that you did a "workspace filemv" (or "sccsmv") between >>> install-sfw to install-bison. It sort of looks like you did >>> this (the SCCS id incremented) but the file name of >>> install-bison looks like you froze the ident string before >>> doing the move. > > This looks OK now. > >>> Also, "install-bison" has a bug of other CRs listed in the >>> webrev. It's unclear to me why you have them there (they >>> definitely should not be there) although again perhaps this is >>> confusion on the part of webrev and the rename taking place. > > Although this still lists the extra CRs. I'm guessing it's webrev > being confused but please do confirm that your SCCS comment is simply > the one for 6521207. > >>> usr/src/pkgdefs/SUNWbison/prototype_com > > AND > >>> usr/src/pkgdefs/SUNWbisonS/prototype_com > >>> Could you please sort the list of entries based on file name >>> (third field?) >> >> >> OK - done. > > It looks like this was semi-sorted ;-) with the directories appearing > first, then followed by the other files. I was hoping it would be > completely sorted as I find it easier to read. > >>> usr/src/pkgdefs/SUNWsfinf/prototype_com >>> >>> As these are in blocks based by component, could you just sort >>> that initial block (since "sfw" comes before "share".) >> >> >> OK - done. > > I noticed the new entry for usr/share/info/dir in the prototype_com but > there isn't an entry in for usr/share/info in usr/src/Targetdirs. > However, there is one in the "gm4" webrev. Were you planning on > integrating these separately? If so, it seems the "gm4" one would need > to be done first and then when you resync with the gate, you'll need to > resolve the conflict with usr/src/Targetdirs and > usr/src/pkgdefs/SUNWsfinf/prototype_com. > > The alternative is to create a unified workspace that contains both of > these commands so you don't have to resync, resolve and then collapse > the delta. I would check with Mike Sullivan on how he would like to > see this come in. > >>> webrev-gm4-05 >>> ============= > >>> usr/src/pkgdefs/SUNWgm4S/prototype_com >>> >>> Could you please sort the list of entries based on file name >>> (third field?) >> >> >> OK - done. > > Same comment as above regarding doing a full sort rather than putting > the directories all together, followed by the other files. > > dsc
