Okay, back to this task (I've been context switching a bit lately, sorry for the delay).
On Wed, 2008-11-12 at 08:33 -0800, Erik Nordmark wrote: > As I said, I can cope with whatever you do in clearview. But one more > point to consider. > > >> 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. > > Are you sure the extra changesets don't make your future merges more > complicated? I'm not sure. I do know that the ipobs-specific changed files don't cause merge problems (they would have with teamware). > My experience from teamware (I did a number of rather large merges for > IP instances) is that future merges became a lot easier if did a wx > redelget after each merge with onnv-gate. The reason is that this moves > forward the common ancestor. Without this the common ancestor remains > back when Phil first took his child of onnv-gate. With teamware the old > common ancestor meant that the same diffs show up over and over again in > filemerge. > I haven't seen this with mercurial, but I've also switched to almost > always doing a reci after I merge with my parent. (That is easier for > refactor-gate since it doesn't have many children.) As long as we keep the original hg repos with a history of past changesets around, then I'm fine with doing a recommit to collapse out the ipobs development changesets. In order to make sure that the merge burden is minimal for this exercise (and because there were some minor changes made to the ipobs bits that were integrated that weren't applied to clearview-ipobs), I'll advance the clearview-ipobs repo to the snv_103 label and do a merge there. That way, when we reparent clearview-noipmp, the set of changesets to merge will be a small known quantity. -Seb
