[Python-Dev] On distributed vs centralised SCM for Python
"Martin v. Löwis"
martin at v.loewis.de
Mon Aug 15 23:29:23 CEST 2005
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
> * 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
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
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.
More information about the Python-Dev