changeset: 72694:e65daae6cf44 user: Antoine Pitrou firstname.lastname@example.org date: Mon Feb 21 21:30:55 2011 +0000 summary: Try s/UINT_MAX/INT_MAX/
It's not on an unnamed branch, it's on the "default" branch (which is omitted for concision by "hg log" and other commands with a similar output).
It's probably a terminology issue, but: the changeset can't be "on" the default "branch", because the head of the default branch (called "tip", IIUC) isn't a descendant of that changeset. It's parent is
changeset: 72693:d9769c8a828b user: Antoine Pitrou email@example.com date: Mon Feb 21 21:25:39 2011 +0000 summary: temp branch to debug crashes on snow leopard buildbot
so you have called it "temporary branch" in subversion. I got go with that term also, if "unnamed branch" is confusing.
I think we can do better. I also dislike "hg log --only-branch default" to only go back to 2006 (to aeefba456e4d), when this revision actually does have a parent (namely, on the trunk branch, 4b41806a0326).
I'm not convinced that small quirks of using "hg log" are important at this point. Also, you could try other options of "hg log" such as "--follow".
IIUC, --follow doesn't help. It traces history across renames and copies, which is not what I want to overcome when trying to produce the full history of the py3k branch.
As for "small quirks ... important at this point": this point is the *only* chance to get it right. If you get it wrong now, we will have to deal with it forever (or rather until we switch to the next version control system).
If you chose to convert in the way it currently does: fine with me, as long as the choice was deliberate (rather than coincidental).
If we called ex-trunk the same name as ex-py3k ("default"), things would probably be quite more confusing, since inspecting a changeset wouldn't tell you immediately where it comes from (2.x or 3.x development).
I would it call default only up to the point where the py3k branch was branched off trunk. All changes up to this point actually *do* belong to both branches. Python 3's history goes all the way back to 0.9, and I'm sure you can still find code in 3.2 which was written 20 years ago.
Change sets created after 3.x was forked off should certainly live on a separate mercurial branch - it would be reasonable to call this branch then 2.x.