But is there a need to have any changesets in the "trunk" named branch? Couldn't the historical changesets just be in an unnamed branch, being ancestor of so many named branches?
There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?
hg branches doesn't list unnamed branches. "hg heads" omits any branch name for unnamed branches. See the cpythonextras repository for examples:
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).
I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all.
Well, the push you request in the todo should do the trick.
Yes, that would also work. However, when then somebody proposed that we may not need the trunk branch at all in the conversion result (which I still think is the case - we don't need it), I noticed that this would solve the problem in a more clean manner.
But you *need* the changesets from the trunk branch. You are just arguing for giving them another label (including "" or "default"), hence:
We can also call it "legacy-trunk", too :)
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".
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).