Collision branches

[Martin Pool]

On 8 September 2011 07:48, James Westby <jw+debian at jameswestby.net> wrote:
> Hi,
>
> Thanks for fixing the bugs that were preventing merge proposals for
> getting filed for collisions.
>
> This had led to a surge in the number of such merge proposals. This is
> mainly due to a backlog, but there have been 10 or so in the two days
> since.

Yes, I'm also glad it got unblocked but also a bit alarmed at how many
mps were created with no apparent real meaning.

>
> You can see the extent of this by searching for ubuntu-branches at
> http://reports.qa.ubuntu.com/reports/sponsoring/index.html
>
> Colin has valiantly reviewed some of them (maybe half, thanks Colin,)
> and has found that in none of the cases so far were the collisions
> "real" in the sense that someone pushed and someone else uploaded
> something different.
>
> There was one case at
>
>  https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ibus/oneiric-201108121834/+merge/73916
>
> which seems to indicate a bug though.
>
> From my previous experience going through these merge proposals the
> majority of issues will be caused by the representation of quilt
> in the branch.
>
> Can the Bazaar team do something to stop this influx of merge proposals
> that must be sorted, leaving just "real" ones? Does this have to involve
> work on looms?

I looked into a few of them and they weren't all clearly due to quilt
problems, but perhaps most of them are (or I didn't understand the
cause from a glance.)

I think we can handle this without blocking on looms by doing a
smarter merge that unapplies and reapplies the patches.  There is some
work towards this in eg <https://bugs.launchpad.net/bugs/608675> which
Jelmer is working on - we may need extra work to hook it up into the
udd importer.

What we should probably do next is look at the merge proposals that
were filed and work out whether each one

- is a real conflict in a sensible form
- is not a real conflict and shouldn't be generated at all (some have zero diff)
- could be either avoided or better presented by smarter quilt
handling or something else

Martin