On Sat, Jul 3, 2010 at 9:34 AM, Brett Cannon <br...@python.org> wrote:
> On Fri, Jul 2, 2010 at 17:17, David Cournapeau <courn...@gmail.com> wrote:
>> On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon <br...@python.org> wrote:
>>> On Fri, Jul 2, 2010 at 12:25, anatoly techtonik <techto...@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. David _______________________________________________ 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
