On Tue, 2008-11-11 at 23:16 -0800, Erik Nordmark wrote: > Sebastien Roy wrote: > > I believe the result of this little experiment is that we should simply > > reparent clearview-noipmp to onnv, pull/merge/commit, and let the > > children absorb the result. The impact will be as-if clearview-ipobs > > were still the parent of clearview-noipmp, I think. > > That sounds dangerous to me since there is no way to find mismerges;
What I said was that files that didn't differ in contents didn't get merged. If they weren't merged, then how could they have been mismerged? > you'd depend on testing and/or eye-balling the code after hg merge. > With refactor-gate having > Summary of changes: 103882 lines changed: 29811 ins; 61135 del; 12936 > mod; 217112 unchg > I do not want to rely on eye balls to verify that the reci+merge didn't > mess things up. > > It is much better to have the parent (clearview-noipmp) in both the > non-recheckin state and in the recheckin state, i.e., two CWDs with > identical file content but with different changesets. > > From there you can then create a clearview-ipmp-reci by > - clone clearview-noipmp-reci > - copy over all the modified files from clearview-ipmp. > The result of that is that clearview-ipmp-reci has a single change set > and identical file content to clearview-ipmp. > > Repeat this for each level down. > > Once the dual CWDs (normal and reci) have propagated all the way down to > refactor-gate, then we can rename the reci CWDs to be the normal ones > and throw away the old. We could do that too; I'm just not sure it's necessary. The extra ipobs changesets are not doing any harm, and they'll get collapsed away when projects are ready to integrate themselves. I admittedly don't understand the source of the risk you're worried about. -Seb
