For those using hg transplant to backport changes. Using the -m flag of transplant causes a merge commit to occur. This means two heads (could be branches) are merged into one. For some not yet fully understood reason this causes a hg merge to perform a large batch of changes, probably recursively performing the full changes of the branch that was transplanted from.
I think for backports it is better not to use -m, because it artificially says you moved over everything that was supposed to be moved over. However, in fact you didn't. Just don't make a merge commit. I found out that this is easy to deal with in the propagation, since transplant can be used in the following fashion: % cvs transplant --log -b Jun2010 -p 456afbaaf416 -p 0ee83fdb0e97 -m 63f8c7be221a applying 63f8c7be221a 35864:63f8c7be221a merged at cfbfaf940bb2 % Which in this case means: ignore changesets 456afbaaf416 and 0ee83fdb0e97, and at changeset 63f8c7be221a pretend a merge was done, which happens to be correct. (Actually, without the -p and -m opts, transplant will ask per changeset what to do with it, so it seems better suited to do regulated propagation merges.) ------------------------------------------------------------------------------ _______________________________________________ Monetdb-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-developers
