your thoughts wanted on bzr team UDD focus

[James Westby]

On Wed Dec 02 23:01:01 -0500 2009 Robert Collins wrote:
> https://bugs.edge.launchpad.net/udd/+bug/491711 is a bug I've filed
> about merging specific files better; please provide feedback about
> whether you think it might work for you.

Thanks, sounds about right. We don't need much information to do this
particular merge, just THIS and OTHER in the script I posted.

I wonder about performance, for this we could register for any basename
of "changelog", but other things may want to do some fairly intensive
checking of whether they can handle the file in question based on its
contents.

> I've marked it high, because things that make bzr-builddeb etc easier
> and simpler will help in maintenance of that code and its
> understandability.

Yes.

> What do you need to be able to drop merge-package?

Something that can merge two strands of development contained in one
branch. merge-package is there because of this case you can get in to


    debian upstream     .----B----------G
                       A      \          \
    ubuntu upstream     `------+---C      \
                         \      \   \      \
    debian                \      E---+------H
                           D----`     \
    ubuntu                  `----------F

(Apologies to anyone using a screenreader)

In words:

  * Debian and Ubuntu ship the same upstream release (A) packaged
    in the same version (D).

  * Debian updates to a new upstream release (B), packaged as E.

  * Ubuntu leap-frogs Debian to an even newer upstream release (C),
    packaged as F.

  * Debian then packages the latest upstream release (G) as H.

Ubuntu now wishes to merge H in to F.

To bzr it seems as if it needs to merge (B, E, G, H) in to (C, D, F),
so this is what it will do. However, this means that it will try and
merge the changes in C and (B, G). This does not go well, as it dutifully
gives what it sees as legitimate conflicts, but what you see is all the
upstream changes conflicting.

The issue is that there are missing arcs (B, C) and (C, G), which would
tell bzr that this is one line of development.

merge-package works around this. It knows that the links should be there,
and it can't put them in, so it creates a new node, I, that is the tree
of G, but with (G, C) as parents. It then merges this to H, and then
finally in to F. This means the final merge is approximately (E, G, H) in
to (D, F) as we want.

It does have some issues of its own (such as how to explain what has gone
wrong if the I->H merge fails, and simply not being "bzr merge" as it should
be), but it is better than the conflicts with plain merge.

I would really like it to go away, for many reasons, including so that I am
no longer asked what it does, and either have to try and explain the
above, or to just tell people they are better off not knowing.

To get rid of this we need something that knows to first merge G->C, and
then that in to H->F. This will still require the user to resolve conflicts
on the G->C merge, but a simple "revert" invocation can be used at that stage,
and we have the possibility to automate that for packaging (possibly still
called merge-package).

Thanks,

James