601895 - Firefox 3.5.14 Build 3 incorrectly tagged

Status: RESOLVED INVALID

(Release Engineering :: General, defect)

Description

[Mark Banner (:standard8)]

I was just checking on revisions and found this in hg.

From http://hg.mozilla.org/releases/mozilla-1.9.1/tags :

FIREFOX_3_5_14_BUILD3 is a tag on revision dc338f6c00de
FIREFOX_3_5_14_RELEASE is a tag on revision 9cabb92310de

This is further confirmed in my manual tests:

# hg update -r FIREFOX_3_5_14_RELEASE
360 files updated, 0 files merged, 14 files removed, 0 files unresolved
# hg identify
9cabb92310de (GECKO19112_20100824_RELBRANCH) SEAMONKEY_2_0_9_BUILD1/FIREFOX_3_5_14_RELEASE/FIREFOX_3_5_14_BUILD1/SEAMONKEY_2_0_8_RELEASE/SEAMONKEY_2_0_8_BUILD1
# hg update -r FIREFOX_3_5_14_BUILD3 
346 files updated, 0 files merged, 27 files removed, 0 files unresolved
# hg identify
dc338f6c00de (GECKO19114_20100930_RELBRANCH) SEAMONKEY_2_0_9_RELEASE/FIREFOX_3_5_14_BUILD3

I'm not sure what has gone on here or if it will affect the source tarball/builds/l10n repacks etc (I guess it depends if they pull the BUILD<n> tag or the RELEASE tag).

Comment 1

[[e-mail] (:bhearsum)]

They pull _RELEASE. Looks like this is caused by the build2 tags happening on default, and hg being choosing tags on default over tags on a branch when in question. I think the fix is going to be removing the _RELEASE tag from both branches, and doing a build4.

Comment 2

[[e-mail] (:bhearsum)]

Oh, and for whatever reason, l10n repos seem unaffected:
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/zh-CN

Comment 3

[[e-mail] (:bhearsum)]

Looks to have worked in my user repo:
http://hg.mozilla.org/users/bhearsum_mozilla.com/mozilla-1.9.1/

(I pushed 3 commits; one removing FIREFOX_3_5_14_RELEASE from default, on removing it from the relbranch, and one that retagged dc338f6c00de as the _RELEASE tag -- on the relbranch).

Will push the first two to the real repo and start the automation again.

Comment 4

[[e-mail] (:bhearsum)]

Fixed in build4.

Comment 5

[[e-mail] (:bhearsum)]

So, after further investigation we discovered that despite the craziness you noticed with the tags, that build3 *did* in fact get built correctly as dc338f6c00de; this can be verified by downloading build3 and checking application.ini. I'm not 100% sure why you get the results you do in comment #0, but maybe it has something to do with full clone vs. incremental pull? hg's behaviour with tags is murky.