On Tue, 05 Oct 2010 09:16:36 -0500, John Arbash Meinel <j...@arbash-meinel.com> wrote: > I've been thinking about it, and I'm pretty confident that what you are > trying to do is inherently "criss-cross". Specifically consider a > semi-ideal case: > > upstream > > A release 2.0 > | > B release 2.1 > | > C release 3.0 > > with debian doing: > > A > |\ > B d deb 2.0-1 > | | > C | > \| > e deb 3.0-1 > > And ubuntu doing: > > A > |\ > | d deb 2.0-1 > | | > B u ubuntu 2.0-1ubuntu1 > \| > v ubuntu 2.1-1ubuntu1 > > > These graphs are, inherently, criss-cross, because you don't have a > single point of convergence. Both 'ubuntu' and 'debian' make new changes > vs the upstream, and never does one fully supersede the other. ubuntu is > constantly pulling from debian, but debian *never* pulls back from ubuntu.
This will be the case for the vast majority of branches for at least the medium term I think. > Let's draw it combined: > A > |\ > | d > | |\ > B | u > |\: | > | \ | > | :\| > C | v > \| > e > > (and that is with the 'ideal' case that C is actually a descendant of B > and not A, though if it isn't you can usually fake it: > A > |\ > B C > |/ > C' > ) This "faking" is exactly what we are doing. > Anyway, in the above graph, B and d are competing as common ancestors. > If you were to strictly use d as the base, then you would get the > changes from d => e, but that would include the A=>B changes. (d does > not include B, so those changes would try to be 'replayed') > > If you used B as the base, then you would be trying to merge in the 'd' > changes a second time. > > Now, what matters is what is explicitly changed by each revision. > Because if "d - A" is strictly adding debian/, and not touching the > actual content, then there are likely no conflicts in a per-file sense. > > That is what '--weave' should be able to handle, since it does per-file > merging. Would '--weave' perform at least as well if "d - A" doesn't have that restriction? > However, if we can't introduce a new revision in the 'debian' line, then > it is really hard to find a single common base between the import lines. Thanks for looking at this. I realise my characterisation of "better" is fuzzy, which doesn't help. >From our discussions it seems like the biggest improvement we could make right now would be to improve the message when the user hits this situation. Is anyone able to suggest a good phrasing based on the improved understanding of the problem? We can always extend it in to a help topic if it isn't particularly terse. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
