573675 - IndexedDB ate the FIREFOX_3_7a5_RELEASE tag, and the GECKO193a5_20100610_RELBRANCH relbranch

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Sorry folks, massive fail.

Apparently the indexedDB repo merged the GECKO193a5_20100610_RELBRANCH (specifically the FIREFOX_3_7a5_RELEASE tag) recently. Without realizing this we continued to merge mozilla-central changesets into the indexedDB repo. Then tonight we merged the whole indexedDB repo back to mozilla-central. We had a test failure so we backed the merge out, and in the process it looks like we somehow deleted the a5 tag and the relbranch too.

In retrospect it was clearly a mistake to merge the relbranch, but I am not sure how to fix this exactly. I think Gavin can fix it though.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I believe I fixed this with:
hg tag -r b2f7bc2aa0bc -m "Re-add tag FIREFOX_3_7a5_BUILD1 for changeset b2f7bc2aa0bc (reviving GECKO193a5_20100610_RELBRANCH in the process). CLOSED TREE" FIREFOX_3_7a5_BUILD1

which I pushed as:
http://hg.mozilla.org/mozilla-central/rev/b2f99ae0f07f
branch	GECKO193a5_20100610_RELBRANCH
changeset 44125	b2f99ae0f07f
parent 43470	c79cf76c1905

This re-added a GECKO193a5_20100610_RELBRANCH head, which also had the effect of reviving FIREFOX_3_7a5_RELEASE.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Prior to doing all that, though, I noticed something weird:

[gavin@sic mozilla-central]$ hg log -r FIREFOX_3_7a5_BUILD1
abort: unknown revision '46495245464f585f335f3761355f4255494c4431'!
[gavin@sic mozilla-central]$ hg log -r FIREFOX_3_7a5_RELEASE 
abort: unknown revision 'FIREFOX_3_7a5_RELEASE'!

At this point I thought that there was something busted about FIREFOX_3_7a5_BUILD1 specifically. But then, by chance, I accidentally ran a similar command with a typo:

[gavin@sic mozilla-central]$ hg log -r FIREFOX_2_75_RELEASE
abort: unknown revision '46495245464f585f325f37355f52454c45415345'!

The tag name there is typoed and obviously non-existent. My conclusion is that certain non-existent tag names (but not all) result in odd output when passed to hg log -r. Known issue? Should I file a mercurial bug? I can still reproduce with my m-c clone and that last command, using hg 1.5.4.

Comment 3

[Dirkjan Ochtman (:djc)]

Actually, timeless discovered a similar issue last week, and it's kind of a WTF. Mercurial's internal revision spec resolver has a fast path for 20-char strings (because that's the length a binary version of the cset ID uses). FIREFOX_3_7a5_BUILD1 and FIREFOX_2_75_RELEASE happen to hit exactly that sweet spot, and get converted to the non-existing changeset ID:

Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import binascii
>>> binascii.hexlify('FIREFOX_3_7a5_BUILD1')
'46495245464f585f335f3761355f4255494c4431'

I'm not sure if timeless has filed a hg bug yet, so CC'ing him.