[Python-Dev] Mercurial conversion repositories

"Martin v. Löwis" martin at v.loewis.de
Sat Feb 26 19:18:41 CET 2011


>> 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 <solipsis at pitrou.net>
date:        Mon Feb 21 21:30:55 2011 +0000
summary:     Try s/UINT_MAX/INT_MAX/

This is listed as a head, but not of a named branch.

>> 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.

> 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).

So I would propose this attribution to branches:
- everything that is ancestor of the default branch is attributed
  to the default branch, back to the very beginning of the repository.
- Everything currently on trunk that wouldn't be on default is then
  attributed to the oldest branch that it is an ancestor of, in the
  order 2.0, 2.1, 2.2, ... 2.7.

So e.g. the 2.7 branch would go back to where it branched from the 2.6
branch (after the actual creation of the 2.6 branch in svn), which
would go back to where it branched from 2.5, and so on.

Regards,
Martin


More information about the Python-Dev mailing list