«
»

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.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!

    This entry was posted on 5 Jun, 2008 at 11:38 am and is tagged with , , . Trackback.

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

  1. Gary Kwong Says:
    June 5th, 2008 at 2:25 pm

    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:
    August 14th, 2008 at 5:19 am

    Whatever happened to getting one produced nightly?

  3. The Rumbling Edge :: Amaya, Mercurial m-c & c-c bundles, and Ubiquity commands Says:
    August 30th, 2008 at 3:12 pm

    […] 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:
    November 10th, 2008 at 2:24 am

    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:
    November 22nd, 2008 at 1:41 pm

    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).

    Thanks

  6. Tony Mechelynck Says:
    May 3rd, 2010 at 7:40 pm

    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 http://www.rumblingedge.com/mozilla-mercurial-source-bundles/ Configuring wasn’t hard, thanks to https://developer.mozilla.org/en/Build_Documentation 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 client.py 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:
    December 1st, 2010 at 1:14 pm

    Incidentally, we are now building a bundle every weekend; see https://developer.mozilla.org/En/Developer_Guide/Source_Code/Mercurial#Bundles.

Leave a Reply