{"id":532,"date":"2013-09-19T07:49:53","date_gmt":"2013-09-19T14:49:53","guid":{"rendered":"http:\/\/blog.mozilla.org\/axel\/?p=532"},"modified":"2013-09-19T07:49:53","modified_gmt":"2013-09-19T14:49:53","slug":"a-tale-of-convert-and-convert","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/axel\/2013\/09\/19\/a-tale-of-convert-and-convert\/","title":{"rendered":"A tale of convert and convert"},"content":{"rendered":"

Or, how I made converting gaia to gaia-l10n suck less.<\/p>\n

Background: For Firefox OS, we’re exposing a modified repository to localizers, so that it’s easier to find out what to work on, and to get support from the l10n dashboards. Files in the main gaia repository on github like <\/p>\n

apps\/browser\/locales\/<\/span>browser.en-US.<\/span>properties<\/pre>\n
should become<\/p>\n
apps\/browser\/browser.properties<\/pre>\n
and the localizable sections in manifest.webapp<\/code>,<\/p>\n
{\r\n…\r\n  \"locales\": {\r\n    \"en-US\": {\r\n      \"name\": \"Browser\",\r\n      \"description\": \"Gaia Web Browser\"\r\n    }\r\n…\r\n}<\/pre>\n
are exposed in manifest.properties<\/code> as<\/p>\n
name: Browser\r\ndescription: Gaia Web Browser<\/pre>\n
We’re also not supporting git on the l10n dashboard yet, so we need hg repositories.<\/p>\n
I haven’t come across a competitor to hg convert<\/code> on the git side yet, so I looked on the mercurial side of life. I started by glancing of the code in hgext\/convert<\/code> in the upstream mercurial code. That does a host of things to get parents and graphs right, and I didn’t feel like replicating that. It doesn’t offer hooks for dynamic file maps, though, let alone content rewriting. But it’s python, and it’s open-source. So I forked it<\/a>.<\/p>\n
With hg convert<\/code>. Isn’t that meta? That gives me a good path to update the extension with future updates to upstream mercurial. I started out with a conversion of mercurial 2.7.1, then removed all the stuff<\/a> I don’t need like bzr support etc. Then I made the mercurial code do what I need<\/a> for gaia. I had to disable some checks that try to avoid commits that don’t actually change the contents, because I don’t mind that happening. And last but not least I added the filemap and the shamap of the initial conversion<\/a> of hgext\/convert<\/code>, so that future updates don’t depend on my local disk.<\/p>\n
Now I could just run hg gaiaconv<\/code> and get what I want. Enter the legacy repositories for en-US. We only want fast-forward merges in hg, and in the conversion to git. No history editing allowed. But as you can probably guess, the new history is completely incompatible with the old, from changeset one. But I don’t mind, I hacked that.<\/p>\n
I did run the regular hg gaiaconv<\/code> up to the revision 21000 of the integration\/gaia-central<\/code> repository. That ended up with the graph for revision 4af36780fb5d<\/a>.<\/p>\n
\"gaia-central<\/a><\/p>\n
I pulled the old conversion for v1-train, which is the graph for revision ad14a618e815<\/a>.<\/p>\n
\"old<\/a><\/p>\n
Then I did a no-op merge of the old graph into the new one<\/a>.<\/p>\n
\"merge\"<\/a><\/p>\n
That’s all good, but now future conversions via gaiaconv<\/code> would still pick up the non-merged revision. Well, unless one just edits the generated shamap, and replaces all references to 4af36780fb5d with cfb28f851111<\/a>. And yes, that actually works<\/a>.<\/p>\n
\"more<\/a><\/p>\n
Tadaaa, a fully automated conversion process, and only forward merges.<\/p>\n
Repositories involved in this post:<\/p>\n