As part of bug 939834 I've just landed some productization changes to mozilla-aurora and wanted to merge Aurora down to Central. This is what I get when I pull the changesets from Aurora to Central: 189 changesets, 1680 changes to 327 files. Problem is that merge ends with 42 unresolved conflicts. I tried to start a merge with kdiff3 but it's quite a mess, changed strings all over the place. How do you work on repositories? Which one is you main repository (aurora, beta, central)? Note also that you can't do changes like this one http://hg.mozilla.org/l10n-central/eo/rev/b7452b02e1e7
I temporarily transplanted the changeset into l10n-central, will need a lot more time to look into this. http://hg.mozilla.org/l10n-central/eo/rev/aa566396eccb
> How do you work on repositories? Which one is you main repository (aurora, > beta, central)? I add the patches or corrections from contributors to each repository as they come, either Central or Aurora (usually Aurora). I myself follow Central. A translation tool generates the diffs, getting the missing translations from either repository, then I patch, commit and push. For us it is a bit like two different products. > Note also that you can't do changes like this one > http://hg.mozilla.org/l10n-central/eo/rev/b7452b02e1e7 I know, it's happened before :(, I'm sorry. I've been trying to know how that happened. The file contents are ok though. I'll double check the translation tool (that file should be in the "blacklist"). > I temporarily transplanted the changeset into l10n-central, will need a lot more time to look into this. http://hg.mozilla.org/l10n-central/eo/rev/aa566396eccb But the patch applies cleanly to l10n-central, should I go ahead and patch it?
Yes, the patch worked so I transplanted that to l10n-central, it's already OK. This is the basic idea of working with merges. 1) You work on l10n-central, and that's fine. 2) When you need to do changes on Aurora, you should do this. a) Do your changes and commit to mozilla-aurora b) Import in l10n-central the new changes > hg pull -r default ../mozilla-aurora > hg merge Check if everything looks good and commit this merge > hg commit -m "Merge Aurora to Central" In this way you'll have changes on both Aurora and Central, without any risk of differences. 3) On merge day, you follow this instructions to merge Aurora and Central https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Uplifting?redirectlocale=en-US&redirectslug=Uplifting_a_Localization_from_central_to_aurora It may seem complicated, but once you've done the first merge, and you always follow 2) for changes in Aurora, is as simple as writing those 3 lines of code. The problem is to do the first merge. I hope to find some time in the next days to look into this (first I need to check and fix all other locales, I'm leaving merge problems for last).
(In reply to Francesco Lodolo [:flod] from comment #3) > The problem is to do the first merge. I hope to find some time in the next > days to look into this (first I need to check and fix all other locales, I'm > leaving merge problems for last). Forgot to add. In the meantime you're free to continue working on your repositories ;-)
Ok. I've done some clean up, for example, we had %S...%S in aurora and %1$S...%2$S in central, for the same entity in the same file. Do you want to give another try? If there's something else I can try to do to make the merge easier, just say so.
There are still 24 file that fail to merge. As I said, I plan to come back to this later in the cycle.
(In reply to Francesco Lodolo [:flod] from comment #6) > There are still 24 file that fail to merge. As I said, I plan to come back > to this later in the cycle. Just to clarify: don't worry and keep working, we'll try to fix this but it not urgent. And thanks for the help ;-)
Tried a merge again but there are still conflicts. Should we close this as wontfix?
If you tell me the commands you are trying to run, I'll run them here and see if I can resolve the conflicts. If it doesn't work, then wontfix is a possibility, but I'd like to try to resolve it and see if we can follow comment #3 in the future.
You need to define a merge tool (e.g. k3diff) https://mercurial.selenic.com/wiki/MergeToolConfiguration Assuming you have this structure (two folders at the same level with clones of the repositories) (parent folder) |--l10n-central |--mozilla-aurora These are the commands cd l10n-central hg pull -r default ../mozilla-aurora hg merge Once you fixed all the conflicts, you can commit and push. Once merged, to uplift your changes at the end of the cycle you can follow https://developer.mozilla.org/en/Uplifting_a_Localization_from_central_to_aurora
Just one question. The first conflict is aboutAccounts.dtd. The difference being: aurora: <!ENTITY aboutAccountsConfig.manage.label "Administri"> central: <!ENTITY aboutAccountsConfig.syncPreferences.label "Preferoj de Speguli"> But that's ok, the sources (aurora, central) have different entities. How am I supposed to solve the conflict? (I will not ask for each one ;), but I need to know how to handle these cases, because they happen a lot).  http://hg.mozilla.org/releases/mozilla-aurora/file/tip/browser/locales/en-US/chrome/browser/aboutAccounts.dtd  http://hg.mozilla.org/mozilla-central/file/tip/browser/locales/en-US/chrome/browser/aboutAccounts.dtd
You should have the chance "Use X for all merge conflicts", in this case you should keep central's version since the result will remain on Central.
Ok, it's done. Anything else I should do now? Can you do your productization changes?
(In reply to Eduardo Trápani from comment #13) > Ok, it's done. Anything else I should do now? Can you do your productization > changes? Thanks! All productization changes were done by manually applying the changes to the repo, from now on it should be easier for me. Besides following the MDN article, my suggestion is to periodically merge down aurora to central to avoid conflicts in future.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
I will. Thanks for walking me through it!
You need to log in before you can comment on or make changes to this bug.