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

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > 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).

That's false.  Especially with bzr, they would see improved log
formats by default, and with git they'd have access to some very
advanced and powerful history querying, even if the update-hack-
commit side of the workflow doesn't change.  Not having used these
tools in most cases, the fact that they don't currently *perceive* a
benefit from switching doesn't mean there won't be one.

There's also the very high likelihood that if Python does switch to a
DVCS, many such committers will start to use the distributed VCS
features actively.  That doesn't mean that it will fully offset the
costs of the switch for them; it does mean that the net cost of the
switch for them is probably a lot lower than it would appear from your
description.

 > It would also put a burden on contributors who are uncomfortable
 > with using a DVCS.

"Discomfort" is not something I take lightly, but I have to wonder how
long that discomfort would persist.  All of the DVCSes support exactly
the same workflow as CVS/Subversion, with some change in naming, and
possibly a need to have a trivial commit+push script to give a single
command with the semantics of "svn commit".  This is crystal clear if
you look at the draft PEP 374, which deliberately emulates the
Subversion workflow in a variety of scenarios.  It's true that the svn
workflow looks more efficient and/or natural in many places, but
please remember that the current workflow has evolved to deal with the
specific features of Subversion compared to the DVCSes, and has had
years to evolve best practices, where the PEP authors have only had a
few days.  I suspect that (if a DVCS is adopted) both the workflow and
the best practices will evolve naturally and without much additional
cost of learning to users, and arrive at a similarly efficient, but
more powerful, workflow, well within a year after adoption.

So there might be some rough places around the edges, especially in
coming up with a way to get the functionality of "svnmerge.py block",
but as far as I can see, unless the project decides that it wants to
adopt a decentralized workflow, the full cost of DVCS is simply
learning a new VCS; the "D" has nothing to do with it.  It won't be
much harder than switching from CVS to Subversion.

Again, I don't take the cost of learning a new tool lightly, but
please let's call that cost by its name, and not bring "distributed"
into it.

 > (*) I'm probably missing something, but ISTM that committers can already
 > use the DVCS - they only need to create a patch just before committing.

That's true.  It's also true that to have the benefit of distributed
version control with Subversion, "they only need to run a Subversion
server locally".  In both cases, it amounts to a fair amount of extra
effort, and misses out on all the benefits of improved merging,
automatic propagation of history from a merged local branch to the
master repo, etc., 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.

That's false.  Again, those people who want to use a DVCS as a DVCS
will benefit from having the master repository(s) coordinate history
for them.  This doesn't work very well across VCS systems, essentially
forcing all committers who want to use the distributed features to
coordinate with each other directly, and only with those who use the
same DVCS.  The mental models used by git users, hg users, and bzr
users differ significantly, though they probably differ more from the
model that's appropriate for Subversion.  Nevertheless, there is a lot
of potential benefit to be gained from having a common DVCS for all
developers.

Whether the benefits available *today* and in the near future outweigh
the costs of an early transition, I make no claims.  But those
benefits *are* fairly large, and much of the cost is subjective (based
on the bad reputation of the DVCSes for UI awkwardness, especially
that of git) and *may* (at this stage, I don't say "will") dissipate
quickly with a rather small amount of experience.