Adblock Plus and (a little) more

Dealing with source code in Mercurial · 2008-10-20 13:00 by Wladimir Palant

Dear Lazyweb,

I like it a lot that checking out XULRunner code is a simple hg clone command now rather than a special checkout script — but how do you check out the source code of a specific release? One would think that hg clone -r FIREFOX_3_1b1_RELEASE will do the trick, yet after compiling I noticed that the last changeset (the one that changed the version number) didn’t make it in. hg up -r 197f83ad7678 fixed this but is there a straightforward way to check out a particular release without having to know any changeset identifiers or branch dates?

And while we are at it, can it be that the old checkout script removed much stuff that you don’t need for XULRunner? I made sure to remove Mercurial metadata and the browser/ directory before importing the source code into TomTom HOME repository, and yet the number of code lines jumped from slightly less than 2 million (1.9.0.3) to over 3 million (1.9.1b1). Is it really only new testcases?

Update: Axel Hecht gave me the right tip — hg clone without a tag followed by hg up -r FIREFOX_3_1b1_RELEASE actually works.

Tags: mozilla

Comment [9]

1. Dirkjan Ochtman · 2008-10-20 13:42 · #

   I think you built wrong… I’m fairly sure that hg clone -r FIREFOX_3_1b1_RELEASE includes the branding. As you can see, the changeset tagged _RELEASE (cf9d…) is a child of the changeset updating the branding (197f…), so those changes must be included in the working dir you got by cloning the _RELEASE tag.

   Not sure where the size increase came from, exactly. I think some stuff got included in the repo that was previously imported using the checkout script. Might that account for the difference?

   Reply from Wladimir Palant:

   I checked out twice, and both times config/milstone.txt was saying “1.9.1b1pre”. I see however that the checkout where I didn’t run hg up is on default branch while the other one is on GECKO191b1_20081007_RELBRANCH. So I guess choosing a tag isn’t sufficient, you have to choose a branch as well. Which still leaves me with the question about how this can be done in a generic way (I don’t want to look up branch name).

2. Gavin Sharp · 2008-10-20 13:56 · #

   Perhaps the problem is that the tagging changeset that introduced the FIREFOX_3_1b1_RELEASE tag (revision f0260e2ac67c) didn’t land on the “default” branch?

   Reply from Wladimir Palant:

   Looks like it, see my answer to the comment above. However, branch is named in such a way that it cannot be guessed – it needs to be looked up. Which unfortunately isn’t acceptable in my case (even though I checked out XULRunner myself this time, it will not always be like this and I don’t want to require people to google just to follow the generic XULRunner update instructions).

3. Gavin Sharp · 2008-10-20 14:19 · #

   It probably wouldn’t be too hard for the release team to push the tag commit to the default branch as part of the release process. File a bug in mozilla.org::Release Engineering?

4. Robert Kaiser · 2008-10-20 16:00 · #

   Does it help to do a “hg up -r FIREFOX_3_1b1_RELEASE” after cloning?

   The difference in checked out code is easily explained: cvs operates on a file basis, so you can just check out a specific set of files, and we had trimmed client.mk there to only check out those parts of the source you need for the given MOZ_CO_PROJECTS. With Mercurial, this variable doesn’t exist any more due to a fundamental difference: hg (as all other DVCSes I know) operates on a repository-wide level rather than a file-based level, so you always have to pull the whole repository and can’t cherry-pick only the files/directories you want.
   In the case of mozilla-central, that means you always get all the code for XULRunner and Firefox, as well as some tooling and testing code.

   Reply from Wladimir Palant:

   Nope, this doesn’t work: “unknown revision ‘FIREFOX_3_1b1_RELEASE’”

5. Axel Hecht · 2008-10-20 16:36 · #

   I think this is one of those cases where pull -r isn’t update.

   If you take a look at the corresponding pushlog, you can see that the repository up to the revision of the rel tag doesn’t contain the reltags.

   You should succeed with

   hg clone http://hg.mozilla.org/mozilla-central/
   hg -R mozilla-central update -r FIREFOX_3_1b1_RELEASE

   I.e., get a full clone, and then update your repo. If you clone with a revision, you only get a partial repo. You could get the reltag revision by updating to the relbranch, if you insist on a partial clone.

   I wonder if the release bundles get that right, we create those now, don’t we?

   Reply from Wladimir Palant:

   That’s what KaiRo already suggested above, and unfortunately it doesn’t work – “unknown revision ‘FIREFOX_3_1b1_RELEASE’”.

6. Axel Hecht · 2008-10-20 17:58 · #

   That’s not what KaiRo suggested, really. The trick is to clone without a specified revision.

   I tried it locally on my regular mozilla-central clone and it worked.

   workbox:mozilla-central axelhecht$ hg up -r FIREFOX_3_1b1_RELEASE
   873 files updated, 0 files merged, 154 files removed, 0 files unresolved
   workbox:mozilla-central axelhecht$ hg tip
   changeset: 20452:c6fcfc205aca
   tag: tip
   user: Alexander Surkov <surkov.alexander@gmail.com>
   date: Tue Oct 14 16:27:02 2008 +0800
   summary: Bug 459635 – ARIA role should override name computation from subtree flag, r=marcoz, aaronlev

   workbox:mozilla-central axelhecht$ hg ident
   cf9d1780600f (GECKO191b1_20081007_RELBRANCH) FIREFOX_3_1b1_RELEASE/FIREFOX_3_1b1_BUILD1

   Reply from Wladimir Palant:

   Oh, I see now. Yes, that will waste some bandwidth but it might actually work, I’ try it. Thanks!

7. Justin Wood (Callek) · 2008-10-21 00:50 · #

   You might actually be able to succeed here by |hg pull -r <some rev>| && |hg up| && |hg up -C -r …|

   the -C will allow you to cross branches if needed, and this way you can keep from pulling extra changesets you wont need, but I’m not certain (havent tried it)

8. Axel Hecht · 2008-10-21 12:56 · #

   I tested the bundle, too, fyi. I filed bug 460760 on the issues I found there. I.e., it doesn’t work ;-)

9. Neil Rashbrook · 2008-10-22 14:59 · #

   Also consider using hg clone -U to avoid checking out the tip to your working directory.

   Reply from Wladimir Palant:

   Thanks, this works as well – less bandwidth wasting.

Commenting is closed for this article.