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? 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.) Erik
