[Python-Dev] PEP 374 (DVCS) now in reST
brett at python.org
Sun Jan 25 01:48:29 CET 2009
On Sat, Jan 24, 2009 at 16:44, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Brett Cannon wrote:
>> On Sat, Jan 24, 2009 at 15:34, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>>>> Second, I think it would be good to explicitly mention the option of
>>>>> deferring this PEP. Based on previous discussion, it sounds like there
>>>>> are a fair number of people who think that there is a DVCS in Python's
>>>>> future, but not now (where "now" means over the next couple of years).
>>>> Sure, I can add a note somewhere that says if a clear winner doesn't
>>>> come about the PEP can be revisited to a later date.
>>> I think the request is slightly different: consider that a potential
>>> outcome should be "svn for the next five years, then reconsider" - not
>>> because none of the DVCS is a clear winner, but because there is too
>>> much resistance to DVCSes in general, at the moment.
>> I already put a note in that no DVCS might be chosen once the PEP is
>> finished. Whether it is because no DVCS is a clear improvement over
>> svn or people just don't like a DVCS seems like a minor thing to worry
>> about to spell out in the PEP.
> I suspect the reactions will be more nuanced than that anyway - e.g. my
> current position is that while I like the idea of a DVCS in principle
> and agree there are definite gains to be had in switching to one, I
> don't think the contenders have had enough time to shake out their
> competing feature sets and relative performance. We don't seem to lose a
> lot by sticking with SVN at least until after 2.7/3.1 are out the door
> and then revisiting the DVCS question (this is particularly so given
> that the current plan is go for a fairly short turnaround on those two
As part of my impressions I plan to also look at usage on top of svn
as a viable alternative if no clear winner comes about. That way if
they work well directly on top of svn we can write up very clear
documentation on how to use any of them directly on top of svn and
still gain the benefits of offline checkins and cheap branching.
Maintenance then becomes simply keeping a read-only mirror going on
> As the zen says, now is better than never, but never is often better
> than *right* now :)
Don't worry, I am not going to push something down anyone's throats if
I don't feel secure that it is the best choice.
More information about the Python-Dev