labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Lab for distributed SCM?
Date Wed, 20 Feb 2008 19:26:19 GMT
On Feb 20, 2008, at 4:13 AM, Jukka Zitting wrote:
> With all the heated discussion in various places about distributed
> versus centralized SCM, I was thinking that we should perhaps start
> collecting some experience on what SCM patterns work and what don't
> for Apache-style collaborative development. Also, people seem to be
> using git-svn, svk, and other similar tools with our Subversion
> repository, and it would be good to gather and share such experience.
> I think Apache Labs would be a perfect place for such work.

Umm, why?  The one thing that Labs doesn't do is "Apache-style
collaborative development."

> Are there
> people who'd be interested in collaborating on such a lab? The lab
> wouldn't really be producing much software, just documentation, helper
> scripts, and other such stuff. Most importantly it would provide a
> neutral ground for discussing the merits of different systems and
> practices.

I don't understand what the big deal is about.  dSCM systems are
specifically designed to solve the problems of Linux-style development,
where each developer has their own working tree and they are only
vaguely working on a common problem.  The "limitations" of the
centralized model are that people are forced onto common branches,
getting early agreement on large changes, and making decisions as
a group when there is disagreement.  But those are Apache's strengths.
Even if we were using dSCM tools, we can't work like Linus and remain
a community -- at best, we'd just be using those tools in a way
that required a centralized gate maintainer, which Subversion is
far better at than any of the dSCM tools.

I've been through this discussion already with OpenSolaris.  They
decided that they *needed* to stay with dSCM (TeamWare originally,
and now Hg) and the result has been three years without a single
commit by a community member.  First, the code wasn't available,
then the tools had to be "improved", then the tools couldn't handle
the scale, then the process had to be reinvented, and then ...
it is just a total waste of time.  Even now, none of the real
software development is exposed to the public gates until long
after it is set in stone.

dSCM is great for personal projects and independent development trees,
not for Apache-style collaborative projects.  Don't be fooled by all
the "next-generation" marketing crap -- dSCM and Subversion are two
different ways to solve *different* problems -- neither one is the
natural descendent of the other, and neither works well for the
other's domain.

In other words, I don't think experimentation (or documentation)
in Labs will do any good -- contributing to the documentation within
one or more dSCM projects is a far more useful activity.  I'd rather
encourage folks to contribute to those projects (for example, by
taking our public svn history as a test case for scalability and
reliability) and help their tools get to the point where they are
usable for large-scale project farms and communal processes.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message