Sebastien Roy wrote:
> On Mon, 2008-11-10 at 10:30 -0800, Erik Nordmark wrote:
>> Did you figure out how to transition the clearview CWDs post Phil's
>> push? We need to do some coordination with refactor-gate. And if you
>> figure out how to do this for clearview-ipmp and clearview, then we can
>> just apply the same technique for refactor-gate.
>
> I simply did the following:
>
> 1. took a clone of clearview-noipmp
> 2. reparented to onnv
> 3. hg pull + hg merge
>
> The result was surprising (in a good way). Only the files that differed
> in content and that had changed in both the parent and child were
> flagged as needing to be merged; the rest were silently updated.
>
> 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;
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.
Erik
