[Python-Dev] PEP 374 (DVCS) now in reST

[Brett Cannon]

On Sun, Jan 25, 2009 at 13:03, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Brett Cannon wrote:
>>
>> On Sun, Jan 25, 2009 at 10:37, "Martin v. Löwis" <martin at v.loewis.de>
>> wrote:
>>
>>>>
>>>> There's a possible third way.  I've heard (though haven't investigated)
>>>> that some people are working on supporting the svn wire protocol in the
>>>> bzr server.  This would mean that anybody who's still comfortable with
>>>> svn and feels no need to change their current habits can continue to
>>>> work the way they always have.  Those that want the extra benefits of a
>>>> DVCS, or who do not have commit access to the code.python.org branches
>>>> would have viable alternatives.
>>>>
>>>
>>> Of course, those without commit access *already* have viable
>>> alternatives, IIUC, by means of the automatic ongoing conversion of
>>> the svn repository to bzr and hg (and, IIUC, git - or perhaps you
>>> can use git-svn without the need for server-side conversion).
>>>
>>> So a conversion to a DVCS would only benefit those committers who
>>> see a benefit in using a DVCS (*) (and would put a burden on those
>>> committers who see a DVCS as a burden). It would also put a burden
>>> on contributors who are uncomfortable with using a DVCS.
>>>
>>> Regards,
>>> Martin
>>>
>>> (*) I'm probably missing something, but ISTM that committers can already
>>> use the DVCS - they only need to create a patch just before committing.
>>> This, of course, is somewhat more complicated than directly pushing the
>>> changes to the server, but it still gives them most of what is often
>>> reported as the advantage of a DVCS (local commits, ability to have many
>>> branches simultaneously, ability to share work-in-progress, etc). In
>>> essence, committers wanting to use a DVCS can do so today, by acting
>>> as if they were non-committers, and only using svn for actual changes
>>> to the master repository.
>>>
>>>
>>
>> If I can't choose a clear winner I am going to look into what it take
>> to run directly on top of svn to avoid the extra step for committers.
>> Otherwise I will get standardized instructions for the three DVCSs and
>> maybe write a script or three to make it dead-simple to work with the
>> DVCSs but have our official repository be svn so we can all use the
>> DVCSs as we see fit until a clear winner springs up.
>>
>
> Well, that sounds like an ideal situation to end up in. Is there a downside
> other than the work it creates for you?

What, isn't creating even more work from me enough of a downside?  =)

There is also the issue of support. If we as a development team start
using four different VCSs then that will severely cut down on who can
help whom. The only reason I have been able to keep the dev FAQ full
of such key svn commands is because inevitably someone on this list
knew how to do something if I didn't. Spread that across three more
DVCSs and the chances of someone knowing the best solution for
something dwindles.

It also means three more VCSs to keep up and running on
code.python.org. While it has worked so far, that's just because we
have been going with what Debian stable has. If you want some
new-fangled thing, e.g. bzr's 1.9 tree support which apparently makes
a huge performance difference (Barry is on vacation but I am prodding
him to put the details in the PEP when he gets back) someone will then
need to step up that we trust to stay on top of security patches, etc.

So yes, it's a nice solution if a winner cannot be chosen, but I don't
think that should necessarily be the end of this quite yet.

-Brett