dirkjan at ochtman.nl
Sun Apr 5 16:53:23 CEST 2009
On 05/04/2009 16:39, Antoine Pitrou wrote:
> 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.
We can still make it accessible/searchable on the web if we don't put it
in the commit message.
> 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).
I don't agree. It's quite annoying for things like annotate/blame, for
example, where you may have to switch to another branch while chasing
down a defective change. I also think 100MB+ is a cheap price to pay,
given you only pay it in disk space (cheap) and initial clone time (not
very often, and usually still quite fast). Also, at some point you
presumably want to deprecate the whole 2.x line, right? So at that
point, it'd be nice to have a full 3.x line with all the history in it,
so that you can just throw away the 2.x stuff and still have full history.
I do agree that 2.x and 3.x should probably be in separate clones.
> 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)?
I think things are these are planned for hgsubversion, yes. I'd probably
want to look at implementing some support for it myself if that makes
the conversion of the Python repositories better.
> I'm not sure what the problem is. Developer SVN access already goes through
Okay, sounds like that will be easy. Would be good to enable compression
on the SSH, though, if that's not already done.
More information about the Python-Dev