[Python-Dev] SVN <-> HG workflow to split Python Library by Module (original) (raw)

Steve Holden steve at holdenweb.com
Sat Jul 3 05:26:43 CEST 2010

David Cournapeau wrote:

On Sat, Jul 3, 2010 at 9:34 AM, Brett Cannon <brett at python.org> wrote:

On Fri, Jul 2, 2010 at 17:17, David Cournapeau <cournape at gmail.com> wrote:

On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon <brett at python.org> wrote:

On Fri, Jul 2, 2010 at 12:25, anatoly techtonik <techtonik at gmail.com> wrote:

I planned to publish this proposal when it is finally ready and tested with an assumption that Subversion repository will be online and up-to-date after Mercurial migration. But recent threads showed that currently there is no tested mechanism to sync Subversion repository back with Mercurial, so it will probably quickly outdate, and the proposal won't have a chance to be evaluated. So now is better than never.

So, this is a way to split modules from monolithic Subversion repository into several Mercurial mirrors - one mirror for each module (or whatever directory structure you like). This will allow to concentrate your work on only one module at a time ("distutils", "CGIHTTPServer" etc.) without caring much about anything else. Exceptionally useful for occasional external "contributors" like me, and folks on Windows, who don't possess Visual Studio to compile Python and are forced to use whatever version they have installed to create and test patches. But modules do not live in an isolated world; they are dependent on changes made to other modules. Isolating them from other modules whose semantics change during development will lead to skew and improper patches. I cannot comment on the original proposal, but this issue has known solutions in git, in the form of submodules. I believe hg has something similar with the forest extension http://mercurial.selenic.com/wiki/ForestExtension Mercurial has subrepo support, but that doesn't justify the need to have every module in its own repository so they can be checked out individually. It does not justify it, but it makes it possible to keep several repositories in sync, and that you get a consistent state when cloning the top repo. If there is a need to often move code from one repo to the other, or if a change in one repo often cause a change in another one, then certainly that's a sign that they should be in the same repo. But for the windows issue, using subrepo so that when you clone python repo, you get the exact same versions of C libraries as used for the official msi (tk, tcl, openssl, bzip2, etc...), that would be very useful. At least I would have prefered this to the current situation when I need to build python myself on windows. It does sound like it would be helpful, though I guess we would have to check each project to ensure we had a license to redistribute under some terms or other ...

regards Steve

Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/

More information about the Python-Dev mailing list