Sebastien Roy wrote:
> 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?
My point is that for the files that do get merged you no longer have the
intented content of the files.
Having a separate clone prior to the pull/merge means that you have
something to verify the merge against.
> 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.
The merges I have to do are extremely complicated (because much of what
I have to merge with are fixes that aren't necessary in refactor-gate,
and filemerge can no longer deal with the set of diffs to ip.c, etc.)
Hence I do automatic verification each time I merge with something post
a recheckin in my parents.
If you don't think this is necessary due to you guys having a smaller
set of changes, then go ahead. Just let me know when you've completed
either manual inspection of every line of code, or repeated all your
IPMP and iptun regresssion tests, and at that point in time I'll pull
down your merge.
Erik
