David Cournapeau wrote:
> 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.
>
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/
_______________________________________________
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
