Subversion Migration: the importance of maturity.

[Miguel de Icaza <miguel ximian com>]

Hello,

> If anyone is interested in the differences between the command line
> interfaces of CVS, Subversion and Bazaar here:
>     http://www.advogato.org/person/jamesh/diary.html?start=196

Having a familiar command line interface is important, and am glad that
they all have a familiar command line interface.

Am sure also that Monotone, Arch and all those other new age platforms
for doing source code control have some wonderful features that would be
great to have, but this is not what worries me the most.

But I think that our source code control system choice should not be
based purely on new features or new development paradigms that we might
want to use, but also on the reliability, community and support that we
can get.

If we do a feature comparison, and we decided that "multiple trees and
changesets" are crucial to Gnome above all else, then clearly Monotone
and Arch might be the tool to use.  But in my opinion there are too many
other dimensions to the problem.

This is what I want in a source code control system, I want a hardened
system:

	* Support.  Not only mailing list support, or to be delivered
	  the open source line: `Well, you should not have done that'.

	* Community: We want to be able to plug into an active
	  community, where we can get support and we can benefit from
	  other third party experiences, tricks and information. 

	* Maturity: Arch and Monotone are at the place where Subversion
	  was two or three years ago, when the early adopters were
	  trying out the technology.  And ever since they said `This is
	  usable' in the pre 1.0 day, and even a year ago when 1.0 was
	  released people still had issues and these problems had to be
	  sorted out.

	  No matter how great Arch and Monotone are (and they are
	  beautiful) they have just not received enough testing nor have
	  they aged enough to be used for something of the scale of
	  GNOME. 

	* User base: only as a function of the previous maturity
	  component: how many large projects have adopted Arch? 
	  Monotone? and Subversion?

	  How many lines of code are maintained by those adopters in
	  each case?

	  Subversion has a fairly impressive list of users in addition
 	  to the recent KDE migration:

		http://subversion.tigris.org/testimonials.html

	* Documentation: again, a function of maturity.  Subversion
	  has a book on its second edition (to cover 1.0 and 1.1) and
	  it is also available online.

	* Plugins: another side effect of maturity and age:

	  Subversion has a fairly complete community of third party
	  components: Web tools, client-libraries, libraries to access
	  the svn file system, GUIs available for Windows, OSX and Gtk
	  users, integration into existing IDEs (Eclipse, SharpDevelop,
	  MonoDevelop, Visual Studio), etc.

	  For a list, see:

		http://subversion.tigris.org/project_links.html

	  This list includes papers, a *large* collection of third
	  party components, and even lists of groups and companies
	  offering subversion hosting services.

I am convinced that Arch and Monotone are *great* technologies, but as a
source code control for a few hundred modules on the Gnome repository, I
think we should be more conservative and let the early adopters sort out
the kinks in these systems for us.

Subversion has:

	* An established company that provides support, has helped
	  migrate a number of open source projects, has case studies
	  and can hold our hands in case we run into problems.

	* Subversion has a full time staff of developers working around
	  the clock to bug fix subversion and maintain regression test
	  cases.

In addition for those who absolutely want a distributed system, they can
still get distributed features by using "SVK" (http://svk.elixus.org/)
a distributed source code control built on top of the Subversion file
system.  SVN extends subversion with a few extra commands like "mirror" 

Finally: I do not want to be on the receiving end of `Well, you should
have not done that' when something wrong goes on the repository.   

That is why I advocate a more conservative approach when picking our
source code control system.