[Python-Dev] On distributed vs centralised SCM for Python

["Martin v. Löwis"]

Bryan O'Sullivan wrote:
> However, it's worth pointing out that with a distributed SCM - it
> doesn't really matter which one you use - it is simple to put together a
> workflow that operates in the same way as a centralised SCM.  You lose
> nothing in the translation.  What you gain is several-fold:

That may be off-topic for python-dev, but can you please explain how
this works?

>       * Outsiders get to work according to the same terms, and with the
>         same tools, as core developers.

I'm using git on the kernel level. In what way am I at the same level
as the core developers? They can write to the kernel.org repository,
I cannot. They use commit, I send diffs.

>       * Everyone can perform whatever work they want (branch, commit,
>         diff, undo, etc) without being connected to the main repository
>         in any way.

So what? If I want to branch, I create a new sandbox. I have to do that
anyway, since independent projects should not influence each other. I
can also easily diff, whether I have write access or not (in svn, even
simpler so than in CVS).
There is no easy way to undo parts of the changes, that's true.

>       * Peer-level sharing of changes, for testing or evaluation, is
>         easy and doesn't clutter up the central server with short-lived
>         branches.

So how does that work? If I commit the changes to my local version of
the repository, how do they get peer-level-shared? I turn off my machine
when I leave the house, and I don't have a permanent IP, anyway, to
host a web server or some such.

>       * Speculative branching: it is cheap to create a local private
>         branch that contains some half-baked changes.  If they work out,
>         fold them back and commit them to the main repository.  If not,
>         blow the branch away and forget about it.

I do that with separate sandboxes right now.

cp -a py2.5 py-64bit

gives me a new sandbox, in which I can do my speculative project.

> Regardless of what you may think of the Linux development model, it is
> teling that there have been about 80 people able to commit changes to
> Python since 1990 (I just checked the cvsroot tarball), whereas my
> estimate is that about ten times as many used BitKeeper to contribute
> changes to the Linux kernel just since the 2.5 tree began in 2002.  (The
> total number of users who contributed changes was about 1600, 1300 of
> whom used BK, while the remainder emailed plain old patches that someone
> applied.)

Hmm. The changes of these 800 people had to be approved by some core
developers, or perhaps even all approved by Linus Torvalds, right? This
is really the same for Python: A partial list of contributors is in
Misc/ACKS (663 lines at the moment), and this doesn't list all the
people who contributed trivial changes. So I guess Python has the
same number of contributors per line as the Linux kernel.

> It is, of course, not possible for me to tell which CVS commits were
> really patches that originated with someone else, but my intent is to
> show how the choice of tools affects the ability of people to contribute
> in "natural" ways.

I hear that, but I have a hard time believing it. People find the
"cvs diff -u, send diff file for discussion to patches tracker"
cycle quite natural.

Regards,
Martin