Translations-copying script fails

The copy-translations-from-parent.py script, used to open translations for a new Ubuntu distroseries, has a habit of failing in production after succeeding on test servers.

Here's my guess at what may be going wrong: once a POTemplate has been copied into the new series, it becomes part of an existing message-sharing equivalence class. Nowadays, new POFiles are created for all templates in an equivalence class at once. There may be circumstances where a POFile already exists in the older series, but gets created in the new series before the existing one can be copied. This breaks the copy: there already is a POFile for that template and language!

To maintain integrity of POFileTranslator, we really want the copy and not the fresh POFile — so we can't simply back off from copying the version from the previous series. And new POFileTranslator records may already refer to the fresh POFile, so we can't just delete the fresh one either. At a minimum we'd have to delete attached POFileTranslators as well.

Something similar probably holds for POFileTranslator, which is even more worrying because of the larger volume. But at least there, it's safe to skip duplicates.

Now that we no longer need to copy massive numbers of TranslationMessages for each Ubuntu opening, it may make sense to abandon MultiTableCopy altogether and re-design this whole procedure to operate on a transactional, per-template basis.

See also bug 576822 (which could have saved us some time here) and bug 778430 (which we want to keep in mind while fixing this one).