Getting mozilla-central with limited bandwidth

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 clone, 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:
    default =
  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!

Atom Feed for Comments 7 Responses to “Getting mozilla-central with limited bandwidth”

  1. Gary Kwong Says:

    If I’m not wrong, I occasionally combine steps 5 and 6 to get |hg pull -u| instead. It does a pull and updates at the same time.

  2. Mossop Says:

    Whatever happened to getting one produced nightly?

  3. The Rumbling Edge :: Amaya, Mercurial m-c & c-c bundles, and Ubiquity commands Says:

    […] internet connection. No matter how long you try, it does not seem to finish, so I resorted to Benjamin Smedberg’s bundle file that saved me lots of […]

  4. Gerry Healy Says:

    Thanks for this, worked like a charm.

    I’m living in Nepal at the moment and one of the biggest frustrations is the less than reliable internet access, let alone the speed. I’m hoping to submit some patches to Thunderbird that will make it a little more usable as an IMAP client under these conditions.

  5. NGUYEN Manh Hung Says:

    Until last week, I could still manage to bundle the repository and unbundle it successfully.

    But today, after updating the repository, it doesn’t work anymore! I could still bundle the repository, but when I unbundled it: eventhough the terminal output didn’t give out any errors, the directory was empty. There were some .i files in the .hg folder, and nothing else.

    I have been retrying for several times. The unbundle action still works well on the old repository, but not on the new repository.
    However, I could build installers/langpack successfully on the new repository.

    So, I wonder if Mozilla has done something to the hg tree? Do you have any ideas about this? And what should I do to fix this?

    Thanks in advance,
    NGUYEN Manh Hung
    (Vietnamese Localization Team).


  6. Tony Mechelynck Says:

    Yesterday I compiled SeaMonkey. Never compiled any Mozilla app before. Getting the source was a breeze, thanks to the above, and to the bundles at Configuring wasn’t hard, thanks to and its subpages. I had enough free disk, swap and memory space. All in all, it was easier than I had thought. :-)
    Here are the remarks I have for whoever else might be tempted:
    1. Only the trunk repositories (mozilla-central and comm-central) are publicly accessible to hg pull & update. For 1.9.1 and 1.9.2 there are bundles but no up-to-the-minute public repository.
    2. Steps 5 and 6 above are unnecessary, at least for SeaMonkey: “python checkout” includes them as its first step.
    3. *TIME*. It took my computer some 12 hours to complete the make. (First-time make with configure and full build, no packaging or install yet. I had not specified parallelism because this is my only machine and I didn’t want to clog my CPU too much. Total CPU use including other apps such as my running instance of SeaMonkey browser & mailer was still about 100%, with the running SeaMonkey and the make about equal between 45 and 50% each, and everything else including Xorg sharing the rest. This is a single-CPU machine running openSUSE Linux 11.2, with an AMD Duron clocked at 1.2 GHz.)

  7. Dustin J. Mitchell Says:

    Incidentally, we are now building a bundle every weekend; see

Leave a Reply