A rather tricky UDD merge

[James Westby]

On Wed Nov 18 18:26:35 -0600 2009 Max Bowsher wrote:
> I have merged the subversion package from sid aiming for lucid. The
> merge was ... interesting ... and I'm initially chronicling my
> experiences here - they can go into a bug once I understand exactly what
> bug I'm filing.
> 
> In a nutshell, "bzr merge-package ../debian/sid" produced lots of
> spurious conflicts. This turned out to be because it was trying re-merge
>  changes from 1.6.{3,4,5}dfsg-1 into 1.6.5dfsg-1ubuntu1 which already
> contained them.
> 
> The underlying cause here was that the karmic|lucid branch contains an
> import of the 1.6.5-1ubuntu1 version without any recorded bzr ancestry
> tying it to Debian revisions. It seems potentially relevant that the
> 1.6.5-1ubuntu1 upload was a merge from sid, where the previous merge was
> from experimental.

Thanks for tracking this down. I can't say without looking what the
cause of this was, it's possible the merge from experimental is
involved, though in theory the code doesn't really care where the
merges come from. I'll be able to look at the logs of the import and
hopefully that may give a clue.

> I was able piece the history back into a sane state by:
> 
> 1) Making a commit containing no changes with left-parent the Debian
> upstream-1.6.5dfsg revision, right-parent the Ubuntu upstream-1.6.5dfsg
> revision - i.e. tying together the two upstream-1.6.5dfsg imports in
> history.
> 
> 2) Merging said commit into the Ubuntu packaging branch, having the
> effect of replacing all the differing file-ids in the Ubuntu branch with
> the ones from the Debian branch.
> 
> 3) Merging the Debian 1.6.5dfsg-1 revision into the Ubuntu branch (i.e.
> the version which the Ubuntu branch was based on, but did not record
> ancestry for), and dealing with the conflicts mainly by "bzr revert"ing
> them, except where there was a file-id conflict, in which case picking
> the text of the Ubuntu version *but* the file-id of the Debian version.
> 
> At which point I was in a position to simply "bzr merge" (not
> merge-package) the debian/sid branch into karmic|lucid branch, resolve
> the genuine conflicts between ubuntu and debian packagings and commit.

It sounds like you took the right approach to fixing it to me, does anyone
on the bzr team have any suggestions for ways it could be improved?

I hope that no-one else has to go through this, but I'm at a loss for ways
to do this except for ensuring that all merges are accurately tracked.
I'm not sure that merge-package should be automating those steps for you
if it can detect the situation.

> The branch, by the way, is at lp:~maxb/ubuntu/lucid/subversion/merge. I
> recommend you examine it with "bzr qlog" if at all - the history is too
> tortuous for a non-graphical visualization.

Thanks, I'll take a look, and also try the original merge-package myself.

> So the open questions:
> 
> 1) What should the importer have actually done? Why didn't it record any
> ancestry from Debian against the 1.6.5-1ubuntu1 import?

I will investigate this.

> 2) Did my way of tying the diverged ancestry back together make sense?

To me, yes.

> 3) Do we want to retroactively replace history with a less contorted
> version?

I don't think we do.

> 4) When an upload to unstable occurs with a higher version than the
> version in experimental, should the importer pull experimental into
> unstable before importing? That would seem to make sense to me, and
> would eliminate one notable source of diverged upstream import branches
> when the importer needed to pull the upstream import into an ubuntu branch.

This is what is supposed to happen, assuming that the experimental
changelog entries are included in the unstable upload. If not then
I don't think we should be inferring a relationship, as it would cause
other issues if a merge was later attempted.

(Consider someone doing some long-term work in experimental when a new
 upstream is released. As the work in experimental wasn't ready for
 unstable they would just upload the new upstream to unstable and
 then merge back. Granted, they wouldn't be likely to be using the
 importer, but it illustrates the issues with inferring relationships
 that the changelog doesn't include.)

Thanks,

James