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.
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.
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.
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?
2) Did my way of tying the diverged ancestry back together make sense?
3) Do we want to retroactively replace history with a less contorted
version?
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.
Max.
signature.asc
Description: OpenPGP digital signature
-- 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
