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 ssh.
Okay, sounds like that will be easy. Would be good to enable compression on the SSH, though, if that's not already done.
Cheers, Dirkjan _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
