3rd party software customizations

[Cristiano Cortezia]

> hg transplant is your friend.


Sure it is. But as far as I know, it will only help me pick changesets, not
pieces of code. In the mentioned strategy, the new vendor release is
dropped as a whole in the vendor branch, composing one single changeset,
and thus decreasing transplant's usability.
 Still, transplant is very useful for moving changesets around branches
without merging their histories while keeping them "decoupled". But it
seems a bit dangerous sometimes. I mean, will mercurial's merging algorythm
be able to correctly analyze the presence of a changeset, which is common
between two branches under merge, when it was in fact transplanted from one
to another (or from a third branch common to both of them) ? My impression
is that it won't.
 Anyway, thanks for the pointer.


Em 17 de abril de 2012 09:29, Lars Marowsky-Bree <lmb at suse.de> escreveu:

> On 2012-04-17T08:38:36, Cristiano Cortezia <cristiano.cortezia at gmail.com>
> wrote:
>
> > I have one more question, regarding this subject. How do you proceed when
> > it is not desirable to accept the whole new vendor release, but to pick
> > only some of the changes to your customization branch (i.e. taking
> > bugfixes while leaving new features unmerged) ?
>
> hg transplant is your friend.
>
>
> Regards,
>    Lars
>
> --
> Architect Storage/HA
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> Imendörffer, HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120417/db6dcd0c/attachment-0002.html>