Users who installed a build of Minefield before 24 November and have been using automatic update since then may be in for a surprise: you are no longer using Minefield or testing mozilla-central!

On 24 November, the Firefox code branched: mozilla-central continues as the repository for all new code. After code has been tested in mozilla-central, it is ported to the 1.9.1 repository, a more stable codebase leading to Firefox 3.1.

Right now, we have many more nightly testers on the stable branch (1.9.1) than we do on mozilla-central. But we really want to catch regressions in mozilla-central before they land on the stable branch. If you are a nightly tester, please go download and install a new Minefield build today! (Windows, Mac, Linux).

Update: to figure out whether you’re running mozilla-central or a 1.9.1 branch nightly, just look at the application title: it will say Minefield for mozilla-central, or Shiretoko for 1.9.1. You can also check the About dialog.

On the Firefox development branches, the version number is always “pre”: for example, 3.1b1pre. This makes it easy to distinguish between nightly builds and release builds. To produce a release, the release team creates a “minibranch”. This minibranch exists for the following reasons:

• To allow bumping the version numbers to the release version, for example: 3.1b1.
• To isolate the release process and allow the main development tree to re-open as quickly as possible.

This is a long-standing tradition in CVS, but we haven’t really done it before 3.1b1 in Mercurial. This week, mozilla-central grew a new branch: the GECKO191b1_20081007_RELBRANCH. Pushing this branch to mozilla-central caused some unexpected side effects for developers:

1. Developers who issued a normal hg pull -u got the following message:

   adding 171 changesets with 234 changes to 110 files (+1 heads)
   not updating, since new heads added
   (run 'hg heads' to see heads, 'hg merge' to merge)

   Yes, a new head was added; but this head is on a named branch and shouldn’t affect developers who aren’t on that branch. This is a bug in Mercurial that will be fixed in future versions. To work around the problem, just run hg up, which will update you to the latest revision of the default branch.

2. hg heads shows branch heads. Normally, developers working on the default branch don’t care about heads on other branches, and don’t want release branch heads showing up when they issue the hg heads command. The Mercurial developers are aware of this issue and will fix it in a future version. In the meantime, use the following command to see only the heads of the default branch: hg heads default.

Note: even with the above bugs fixed, hg pull -u isn’t the exact equivalent of hg pull; hg up: in the case where no new changes are available on the remote server, no update will be performed. This only affects trees where the working directory is not at the tip revision. This slightly unintuitive behavior is considered a feature by the Mercurial developers, not a bug.

Recently we opened up mozilla-central for checkins for Mozilla 1.9.1/Firefox.Next. As people on IRC have started using the repository, one of the major complaints has been that cloning the entire repository for the first time can take a very long time over a slow network… and for flaky networks, it may be impossible to clone at all.

There is a solution: instead of cloning directly from hg.mozilla.org (hg clone http://hg.mozilla.org/mozilla-central/), download a changeset bundle and unbundle it to create a local repository.

1. Download a mozilla-central bundle. For the moment, I’m hosting one here. I’m going to ask the mozilla release team to produce one nightly and host it on the mozilla FTP server. The bundle file is approximately 65MB.
2. Create a new, empty repository:

   $ hg init mozilla-central

3. Un-bundle the real mozilla-central changes to that repository:

   $ cd mozilla-central;
   $ hg unbundle /path/to/mozilla-central.bundle

4. Tell mercurial where you normally want to pull from by copying the following content into your mozilla-central/.hg/hgrc file:

   [paths]
   default = http://hg.mozilla.org/mozilla-central/

5. Pull any additional changes that happened since the bundle was created:

   $ hg pull

6. Update your working directory to the latest change:

   $ hg up

   Happy hacking!