Comment 29 for bug 653307

Disregard my last comment (#28), that failure turns out to be due to the already-broken data on Launchpad. I still can't reproduce this problem in a local run of the importer isolated from the branches on Launchpad. I've tried arranging my localbranches/ directory to have the branches stacked upon each other similarly to how they are on Launchpad, but that doesn't reproduce it. I still have no plausible theory for how this system caused the same randomly generated revision ID to be associated with different tree contents.

The list of currently affected imports appears to be:

http://package-import.ubuntu.com/status/dsdo.html
http://package-import.ubuntu.com/status/ayaspell-dic.html
http://package-import.ubuntu.com/status/commons-daemon.html
http://package-import.ubuntu.com/status/docbook-xml.html
http://package-import.ubuntu.com/status/igaelic.html
http://package-import.ubuntu.com/status/libcommons-net-java.html
http://package-import.ubuntu.com/status/icu.html
http://package-import.ubuntu.com/status/autofs.html
http://package-import.ubuntu.com/status/libzip.html

At least that's shorter than the original list.

In the absence of a better idea, I suggest we try deleting those imports again, verifying that the deletions really worked this time (i.e. that those branches are completely absent from Launcphad), then reimport, and cross our fingers.