"Bouncing" between branch imports and branch exports.

Bug #490668 reported by Jeroen T. Vermeulen on 2009-12-01
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

The imports from branches and exports to branches can "bounce around" a bit if the import and export branches are the same one: a change in a branch gets imported, the changes get exported back to the branch (updating only the PO files' timestamps), and those changes to the branch get imported again. It does seem to stop somewhere, but I'm not sure why yet.

As far as I can tell this is not an actual problem, but it does cause unnecessary branch and import activity. Two ways in which we could cut the cycle:

(a) Make the import-from-branch script ignore the commits made by the export-to-branch script.

(b) Stop the importer from updating a POFile's timestamp when an import has no changes.

I thought we designed it explicitely in such a way that this is not a problem. It should stop simply because exports happen only daily, and PO files timestamps are also not a reason enough to do an entire commit. What am I missing?

Changed in rosetta:
status: New → Incomplete
Jeroen T. Vermeulen (jtv) wrote :

It may well be to do with the fudge factor: the timestamp on the PO file is from the beginning of the import transaction, whereas the timestamp on the bzr commit is from the end of the export—exactly the wrong way around for the check that skips the commit if it risks overwriting changes from another source. So the check "fudges" by a few hours at the risk of doing a few unnecessary commits.

The bouncing data itself is pretty safe: the repeated imports are marked as published so won't overwrite anything in the database, and the repeated exports are skipped if there is any risk of them overwriting anything in the branch. It's just that there may be a few extra imports of identical copies of the file, much as we sometimes saw with the same Ubuntu package being built for multiple architectures. And the POFile timestamps get updated unnecessarily.

This could also be a result of bug #362848: at least we've had someone complain about this though they were manually merging the exported branch into what was later imported.

This is either a duplicate of bug 515051or the other way around.

More useful data in bug 515051.

Changed in rosetta:
status: Incomplete → Triaged
importance: Undecided → High
tags: added: code-integration

And my comment: "Probably the simplest solution to this problem is to not update PO file header and date_changed unless at least one translation has changed as well."

Jeroen T. Vermeulen (jtv) wrote :

Yes, I think I prefer option (b) as well.

Emilien Klein (emilien-klein) wrote :

Another perfect example of this bug (or bug 515051):

http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/217
This is a commit for 4 .po files that have not a single useful modification.

Severin Heiniger (severinh) wrote :

The main branch of the LottaNZB project is also affected: https://code.edge.launchpad.net/~lottanzb/lottanzb/main Unfortunately, the "bouncing" doesn't seem to stop, as nds.po is exported daily without any useful modification. This is quite annoying as it clutters the branch with useless revisions.

Francis J. Lacoste (flacoste) wrote :

dpm's rationale for 'Medium' (Low since we don't use Medium):

This hasn't got directly to do with upstream translations sharing, but it might become more of an issue when upstream sharing gets widely used and translations precedence starts kicking in. It'd be great if upstream maintainers in Launchpad could fully automate the translations process, and having the same branch for translations imports and exports is the way to go. However, they cannot use this feature right now, due to commits being done even if translations have not changed.

Changed in launchpad:
importance: High → Low
Curtis Hovey (sinzui) on 2012-12-16
tags: added: translations-branch
removed: code-integration
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers