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: 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.
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') '46495245464f585f335f3761355f4255494c4431' I'm not sure if timeless has filed a hg bug yet, so CC'ing him.