Merging named branches

Given the rapid release cycle of Firefox, every 6 weeks the Firefox branches are getting merged as follows:

1. mozilla-beta -> mozilla-release
2. mozilla-aurora -> mozilla-beta
3. mozilla-central -> mozilla-aurora

Due to the fact that our own named branches exactly map the Firefox branch repositories, we also have to merge our branches at the same day. There are some steps involved which have to be executed for each of the listed branch merges below:

1. mozilla-beta -> mozilla-release
2. mozilla-aurora -> mozilla-beta
3. default -> mozilla-aurora

Merging a branch

To merge the code of a branch into another one follow the steps as given below. For safety reasons all three merges will be explained separately. That will ensure that no accidental failures could happen. If you trap into merge conflicts read the section about Resolve Merge Conflicts.

Merge 'mozilla-beta -> mozilla-release'

1. Create a tag on the mozilla-beta branch with the name RELEASE_BASE_YYYYMMDD and review it before pushing the changeset.
   
   

   $ hg pull -u && hg up -C mozilla-beta
   $ hg tag RELEASE_BASE_`date +%Y%m%d`
   $ hg out
   $ hg push
   

2. Merge the code from the mozilla-beta branch into mozilla-release, create a tag with the name FIREFOX_RELEASE_VERSION (e.g. FIREFOX_RELEASE_6.0), and review all the changes before pushing the changeset. Changes which should not land on mozilla-release have to be removed manually.

3. $ hg pull -u && hg up -C mozilla-release
   $ hg merge -r mozilla-beta (or apply an already existent merge patch - don't do both)
   $ hg diff
   $ hg commit -m "Merge mozilla-beta to mozilla-release for Firefox %VERSION%" (or hg qfinish tip)
   (diff branches)[1]
   $ hg tag FIREFOX_RELEASE_%VERSION%
   $ hg out
   $ hg push
   

   [1] diff branches

Merge 'mozilla-aurora -> mozilla-beta'

1. Create a tag on the mozilla-aurora branch with the name BETA_BASE_YYYYMMDD and review it before pushing the changeset.
   
   

   $ hg pull -u && hg up -C mozilla-aurora
   $ hg tag BETA_BASE_`date +%Y%m%d`
   $ hg out
   $ hg push
   

2. Merge the code from the mozilla-aurora branch into mozilla-beta, create a tag with the name FIREFOX_BETA_VERSION (e.g. FIREFOX_BETA_6.0), and review it before pushing the changeset. Changes which should not land on mozilla-beta have to be removed manually.
   
   

   $ hg pull -u && hg up -C mozilla-beta
   $ hg merge -r mozilla-aurora (or apply an already existent merge patch - don't do both)
   $ hg diff
   $ hg commit -m "Merge mozilla-aurora to mozilla-beta for Firefox %VERSION%" (or hg qfinish tip)
   (diff branches)[1]
   $ hg tag FIREFOX_BETA_%VERSION%
   $ hg out
   $ hg push
   

   [1] diff branches

Merge 'default -> mozilla-aurora'

1. Create a tag on the default branch with the name AURORA_BASE_YYYYMMDD and review it before pushing the changeset.
   
   

   $ hg pull -u && hg up -C default
   $ hg tag AURORA_BASE_`date +%Y%m%d`
   $ hg out
   $ hg push
   

2. Merge the code from the default branch into mozilla-aurora, create a tag with the name FIREFOX_AURORA_VERSION (e.g. FIREFOX_AURORA_6.0), and review it before pushing the changeset. Changes which should not land on mozilla-aurora have to be removed manually.
   
   

   $ hg pull -u && hg up -C mozilla-aurora
   $ hg merge -r default (or apply an already existent merge patch - don't do both)
   $ hg diff
   $ hg commit -m "Merge default to mozilla-aurora for Firefox %VERSION%" (or hg qfinish tip)
   (diff branches)[1]
   $ hg tag FIREFOX_AURORA_%VERSION%
   $ hg out
   $ hg push
   

   [1] diff branches

Resolve merge conflicts

While merging a branch into another branch merge conflicts could occur, e.g.for utils.js:

merging lib/addons.js
merging lib/utils.js
warning: conflicts during merge.
merging lib/utils.js failed!
9 files updated, 4 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon

The main reason for it is that code has been drifted apart across those branches. To solve the conflicts you will have to work really careful and always have to inspect the code before changing it. Make sure to also execute the test to prove its functionality.

When the merge command gets executed and conflicts exist, Mercurial will tell you about the affected files. Open your editor and search for the '<<<<<<<' pattern. Blocks of affected code are bounded by '<<<<<<< local' and '>>>>>>> other' lines. You simply have to choose the correct block and delete the other one. In most cases you will simple delete the content between '<<<<<<< local' and '=======' and leave the section between '=======' and '>>>>>>> other'. But please always re-check which code is the correct one.

After the changes have been saved, call resolve for each file which had merge conflicts and then return to the merge steps for the appropriate branch.

$ vi lib/utils.js
$ hg resolve -m lib/utils.js

Diff branches before pushing merge

For any merge, before you tag and push the merge do a diff between the merged branches.
They should be identical except .hgtags

Make sure to add all these changes to the merged branch, otherwise they will be ommited for all subsequent merges.

$ hg diff -r mozilla-release:mozilla-beta
$ // manually bring the changes to the merged branch
$ hg add .
$ hg commit --amend

Creating a new ESR Branch

Whenever a new ESR build of Firefox is released, a new named branch has to be created for the appropriate Mozmill tests. Given that this new branch is based off the release branch, the merge from beta -> release has to be done first.

Steps to do to actually create this branch are the following:

$ hg up -C mozilla-release
$ hg branches
$ hg branch mozilla-esr%VERSION% (like mozilla-esr31)
$ hg branch (check that the new branch is selected)
$ hg push --new-branch (Create the new named branch on the remote repository)