Re: Subversion Migration: the importance of maturity.

[Rob Adams <readams gnome org>]

Subversion really is a joy to use and administer.  Now, admittedly my
efforts weren't anything like the scale of the GNOME project, but I
migrated my company's repositories from CVS to SVN not too long ago.
The cvs2svn script worked extremely well; the only problems that we
experienced really were caused by random cruft in our CVS repository
that shouldn't have been in there.  But using dumps and filters I was
able to remove that.

I did run into problems with the import being extraordinarily slow,
which were resolved by using the fsfs backend.  I also created a RAM
drive to temporarily store the repository so I could very quickly do a
dump/filter/restore cycle (these 2 changes got it from a few hours for
such a cycle to a few minutes).  I no longer have access to the
repository so I can't tell you how man kLoCs but I'd estimate perhaps
250,000.

Once I finally got the system migrated though, there were a lot of
benefits we immediately saw from using svn.  The branches are much
easier to use and understand than CVS, and retraining our engineering
department and customer service engineering department required only a
couple of hours before everyone was proficient enough to handle merging
changesets between branches.

We used https/WebDAV rather than ssh.  This allowed me to be able to
easily configure fine-grained access control, such as read-only access
to the repository for live servers, which vastly simplified our code
deployment procedures.

Now, of course everyone realizes that svn is better than cvs, and this
discussion is mostly centered around which of the next generation
systems to switch to.  In my experience, though, svn is powerful,
friendly, and solves most of CVS's problems.  Given that the GNOME
project is used to the "central repository" workflow, I think that svn
is a superb choice.

-Rob

On Fri, 2005-05-13 at 12:07 -0400, Miguel de Icaza wrote:
> 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.
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers