All, (please keep me on CC:, I'm not on the list. thx)
I think I may have painted myself into a corner, and am seeking advice (even help ;-). In order to benefit from the recent putback of ofmt.c et. al to Nevada in our project gate (which was based on build 107), I created a clone of both the project gate (ilb-merge-clone) and (on-swan) Nevada (nv-merge-clone), and then did the following in ilb-merge-clone, in approx. this order: - reparent to nv-merge-clone - hg pull -u - hg merge (there wasn't much to do there, we have almost no overlap with existing files) - hg commit - hg reparent to our opensolaris gate - hg recommit -m "nv_111 merge" - hg push (to the opensolaris ilb gate) (I'm not 100% sure at which stage I did the re-parenting) I created webrevs vs. ilb and nevada, as well as build on sparc and x86 and ran rudimentary tests on a machine bfu'd with these bits. We've had two (minor) changes pushed into the ilb gate since. the problem (in case it's not yet obvious): in a fresh clone of the osol. ilb gate, when I do a webrev vs. nevada, I see *tons* of files. ofmt.c, which is present in the workspace, is shown as "new" file in the webrev - basically, it looks like hg is at a completely different rev than Nevada. I suspect the recommit may have been a mistake here ... If anybody has a suggestion how I can get our gate into a sane state (ie where hg agrees with the code and with me :-) without recreating it, I'd be more than grateful to hear/read it. TIA Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion'
