IndexedDB ate the FIREFOX_3_7a5_RELEASE tag, and the GECKO193a5_20100610_RELBRANCH relbranch



Release Engineering
8 years ago
4 years ago


(Reporter: Ben Turner (not reading bugmail, use the needinfo flag!), Assigned: Gavin)


Firefox Tracking Flags

(Not tracked)


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.
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:
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.
Assignee: nobody →
Last Resolved: 8 years ago
Resolution: --- → FIXED
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.
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')

I'm not sure if timeless has filed a hg bug yet, so CC'ing him.
Product: → Release Engineering
You need to log in before you can comment on or make changes to this bug.