[Monetdb-developers] About the use of hg transplant
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.)
Fabian, Thanks for the analysis and explanations! One minor(?) point, though: So far (as far as I'm aware), we used assume an implicite order of our branches, e.g,. Feb2010 -> Jun2010 -> default, and we used hg merge to "propagate" (many/all) changes "from left to right", e.g., from Feb2010 to Jun2010 or from Jun2020 to default, while we used hg transplant to selectively "back-port" individual changes "from right to left", e.g., from default to Jun2010 or from Jun2010 to Feb2010. Do you now suggest to "symmetrically" use hg transplant for both "forward propagation" and "back-porting"? Thanks! Stefan On Sun, May 09, 2010 at 11:23:54AM +0200, Fabian Groffen wrote:
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 ^^^ "hg" for us that don't use your alias/script, I suppose ;-) 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 Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4199 |
On 09-05-2010 12:47:19 +0200, Stefan Manegold wrote:
Fabian,
Thanks for the analysis and explanations!
One minor(?) point, though:
So far (as far as I'm aware), we used assume an implicite order of our branches, e.g,. Feb2010 -> Jun2010 -> default, and we used hg merge to "propagate" (many/all) changes "from left to right", e.g., from Feb2010 to Jun2010 or from Jun2020 to default, while we used hg transplant to selectively "back-port" individual changes "from right to left", e.g., from default to Jun2010 or from Jun2010 to Feb2010.
Do you now suggest to "symmetrically" use hg transplant for both "forward propagation" and "back-porting"?
No, but transplant is able to leave out changesets that e.g. are marked with "do not propagate", or changesets that are in fact transplants (and hence contain the same change that's already in the sources).
% cvs transplant --log -b Jun2010 -p 456afbaaf416 -p 0ee83fdb0e97 -m 63f8c7be221a ^^^ "hg" for us that don't use your alias/script, I suppose ;-)
sorry, probably should have better called my script "kwik" :)
participants (2)
-
Fabian Groffen -
Stefan Manegold