solipsis at pitrou.net
Sun Apr 5 16:39:20 CEST 2009
> hgsubversion in many cases will preserve the rev order from svn so
> that the local revision numbers that hg shows will be the same as in SVN
Er... I guess it's only the case in simplistic cases where you convert all
branches in the SVN repo to a single hg repo (which is not workable for the
CPython repo, which is too big), and there are no cases of SVN revisions being
either ignored or split between several hg changesets (for example because they
span multiple branches).
The other nice thing with having "[svn rXXX]" in the patch subject line is that
it makes the info easily viewable and searchable in the Web front-end.
> For another, I'd like to use an author map to bring the revision authors
> more in line with what Mercurial repositories usually display; this
> helps with tool support and is also just a nicer solution IMO.
[in-repo multiple branches]
> No, the Mercurial project currently doesn't use them. Mozilla does use
> them at the moment, because they found they did have some advantages
> (especially lower disk usage because no separate clones were needed). I
> think named branches are fine for long-lived branches.
> At the very least we should have a proper discussion over this.
I think at least 3.x and 2.x should live in separate repos. It is pointless for
a clone of py3k to end up pulling all 40000+ changesets from the trunk. It would
add 100MB+ to every py3k clone (that is, quadrupling the size of the repository).
> The current Mercurial mirror for py3k also doesn't include any history
> from before it was branched, which is bad, IMO.
Given how much separate work has taken place in both, I'm not sure having that
history would be very useful. We have to take into account practical needs.
Someone needing to search history before py3k was created can just do a clone of
> In order to get the most
> of the DVCS structure, it would be helpful if py3k shared history with
> the normal (trunk) branches.
Is any SVN-to-hg conversion tool able to parse the commits produced by
svnmerge? And, even then, turn that information into useful hg information (say,
transplant metadata of which changes were ported)?
> > Not really. Currently, core developers can only push stuff using the
> > Bazaar setup. Personally, I think SSH access would be a lot nicer, but
> > this will depend how confident python.org's admins are with this idea.
> We could still enable pushing through http(s) for hgweb(dir).
I'm not sure what the problem is. Developer SVN access already goes through
More information about the Python-Dev