I noticed that Subversion is starting to get some substantial use in
OSS projects, and did a little research on how that comes about and
how successful it tends to be. For each project listed at
http://subversion.tigris.org/propaganda.html, I tried to determine how
the decision was made to switch to SVN, when they switched, and
what difficulties they've been having. Here are my findings:
* Apache: Apache is, of course, pretty closely tied to the SVN
project. Greg Stein set up an SVN repository for Apache in early
2003 and they have been converting projects over piece by piece.
I know they've had problems with wanting shared working copies, as
well as issues with wanting to have commits which aren't
date-ordered on account of doing CVS conversions of multiple CVS
projects into the same SVN repository.
* Samba: This project very briefly discussed converting to SVN in
February (I have to assume most of the real discussion happened
off-list) and converted to SVN in April. They mentioned one
unspecified BDB issue in June requiring recovery, but otherwise I
haven't seen any indications of difficulties.
* Zope: They discussed an SVN conversion in April, with no
objections, and converted in May--not just to using Subversion to
host their own code, but as part of the Zope system as well. They
were initially mildly disappointed that cvs2svn did not handle
line-endings, and that our auto-props story for automatically
setting svn:eol-style isn't very good. I saw one report of a
"Cannot Allocate Memory" BDB issue in June which required
recovery, but that's it.
* xiph.org: They converted in July, based on a look at their
repository. The xiph.org founder is a friend of mine, so I assume
that was a motivating factor. I couldn't find any mailing list
discussion about it; I think most of their chatter happens on IRC.
* Debian: Debian is a huge community. They offer CVS, SVN, and arch
hosting. SVN hosting appears to be somewhat popular, but it's
hard to tell since many people host their repositories privately
(there's no requirement that you do Debian work under any kind of
central version control, and many people don't use version control
at all). They do have some loud arch advocates, and to some
extent arch fits the Debian-package-maintainer model better on
account of better merging support. One of my Debian developer
friends uses svk for that reason. As early adopters, Debian had
problems with svn 0.x incompatibilities, have also reportedly had
difficulties with hanging svnserve processes (BDB problems, I
would assume), and one project has reportedly had difficulties
with people accidentally checking out the full project tree with
all branches, causing significant server load.
* Conectiva: I couldn't find much information about Conectiva due to
the language barrier, but they do have a glowing testimonial on
our propaganda page, have been using Subversion since August 2002,
and have a ginormous repository.
* Trac: Trac has always used Subversion as far as I can tell (since
project inception, which I think was around August 2003), and like
Zope, they don't just use it to host their own code, but also as
part of their system. I saw no obvious indications of problems on
their mailing list.
* GNUe: GNUe converted their repository in December 2003. They
considered both svn and arch, but lacked a strong arch advocate.
CVS history conversion and partial checkouts appeared important to
them. I found no particular indications of difficulties.
* LFS: LFS initially discussed conversion to SVN in March. A
Bitkeeper advocate piped up, but several people did not like the
Bitmover license. There appeared to be no strong Arch advocate
within the project. In May, they announced a project to evaluate
SCM systems; the mailing list for this project (lfs-scm-testing)
appears to be defunct, so I can't see how it went. Cheap branches
appeared to be a big motivator. In June, they converted the LFS
Book sources (their main project). They initially had BDB
permissions problems, but appear to have solved them. In August,
they've been encountering a lot of "Cannot allocate memory" BDB
issues, and are planning to switch to FSFS after 1.1 comes out.
Of course, there are also the projects which have considered switching
but didn't, or who switched to different version control tools. These
are harder to identify. The ones I know about are:
* gcc: Paralyzed by a mix of advocates of various version control
systems (mostly Arch and Subversion). Past conversations have
generally devolved into a long list of requirements, most not
satisfied by any version control tool.
* Linux kernel: As everyone knows, the Linux kernel is pretty wedded
to Bitkeeper, and that seems unlikely to change. The key
developers have no great qualms about the BK license, and BK was
pretty much designed to closely fit the Linux development model,
whereas Subversion is a rather poor fit for it.
* NetBSD: (Most of the relevant discussion has happened on a closed
mailing list, so I can't comment on it, and I'm not on that list
any more so I'd be out of date anyway. Nothing too exciting here;
they're a big project with lots of inertia.)
As an aside, I'd be interested to hear about mid-sized or larger OSS
projects using Arch, and how successful they are. The only one I
currently know about is Xouvert, which appears never to have gotten
off the ground. (The gnuarch.org user-community page hasn't been
responding today, or I might have more information there.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 14 00:43:14 2004