On Mon, 04 Oct 2010 17:01:01 -0500, John Arbash Meinel <[email protected]> wrote: > On 9/29/2010 11:23 PM, James Westby wrote: > > What merge package does is first merge the two upstream revisions > > together, taking the tree from whichever has the highest version number. > > > > ---B---F > > / / / > > / / .-D--. > > \ A-= H > > \ `-E-` > > \ \ > > C------G > > > > Currently it will then just merge H in to G (the target). This can > > generate conflicts, which are very, very confusing to users, as it's > > incredibly hard to explain why they are getting them. > >
> Does merging D & E generate conflicts itself? It would seem that if > merging to G generates conflicts, then you should have gotten a conflict > in the intermediate stage as well. (offhand the best you can usually > hope for is more understandable conflicts, unless you have a real > 'criss-cross' merge and we are selecting a very poor base.) It is not a real merge. We create a new revision with D & E as parents, and the contents of the later of the two (defined in terms of upstream version numbers). So, no, there is no possibility of conflicts at this stage. > A > /|\ > E D B > |\|\|\ > | H F C > \ \| | > \ I | > \ | > \ | > \| > G > Now you have a genuine criss-cross. As the lcas are E and B (ancestors > of both I and G that are not superseded by a more recent ancestor.) > Just using 3-way merge (vs say --weave) I would expect this to conflict > more than merging H => G, because of our specific base selection (when > we find a criss-cross 3-way goes to the next base, which will be A, > which then will try to merge (I-A) into (G-A). That's unfortunate. Is there a way we could use our increased knowledge about the revisions involved to merge with a strategy that would make this situation better? Would it be beneficial to have some concrete examples to try out? Thanks, James -- ubuntu-distributed-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
