LWN.net Logo

GNOME considers DVCS choices

January 14, 2009

This article was contributed by Bruce Byfield

THE GNOME project has completed a survey of active contributors about which distributed version control system (DVCS) they would prefer to switch to in 2009. The project is now in the process of interpreting the results and deciding on the next steps. As the process unfolds, it provides a vivid snapshot of how free and open source software (FOSS) contributors regard DVCS applications.

DVCSes are an idea that have taken hold strongly in the FOSS community in the last few years, and that is starting to edge out older version control systems such as CVS and Subversion. Unlike such older, centralized version control systems, DVCSes do not require a single repository. Instead, on a DVCS, all contributors have their own repositories, and decision-makers decide which ones to merge for a release. In general, DVCSes are seen as more flexible, although critics argue that they can be too decentralized, and that they cause more conflicts than traditional version control systems during merges. All the same, they continue to be popular, partly because of the high-profile of Git, the DVCS originally written by Linus Torvalds for Linux kernel development after the switch from BitKeeper.

The GNOME survey was privately distributed by Behdad Esfahbod, one of the directors of the GNOME Foundation, in December 2008 to gather background information for a possible move away from Subversion, the version control system used by most of GNOME. The survey was distributed to GNOME contributors with Subversion accounts and SSH keys — a total of 1083 people in all, of which 579 replied.

The survey asked those who replied about their current use of Subversion, as well as their role within GNOME, what DVCSes they used or with which they were familiar, and how they felt about switching from Subversion. They were then asked to rank their preferences for Git, Mercurial (often abbreviated to Hg, after the abbreviation for the element Mercury), Bazaar (Bzr), and Subversion.

Analyzing the results

On 3 January, 2009, Esfahbod published the raw results of the survey. Over the next few days, the results were analyzed by a number of people, including Shaun McCance, Andy Wingo and Elijah Newren, all of whom charted the results. Newren's analysis in particular has become a center for discussion about the survey, undoubtedly because it was the most exhaustive analysis.

Looking at Newren's charts, viewers can quickly see approximate but definite results (those who want more exactness can refer to the raw data). The result is a thorough picture of GNOME contributor's views on DVCS.

Newren cross-correlates survey results in every possible way, but here are some highlights:

  • About 60% of respondents claimed familiarity with Git, and 25% with Bzr and 20% with Hg.
  • 37% of respondents preferred to switch from Subversion, 34% were indifferent either way, and the rest either support Subversion or did not want to switch.
  • 48% chose Git as their first choice, and 25% preferred Subversion. Bzr was favored by about 12%, and Hg by 7%, while 5% expressed no preference. Among second choices, Subversion, GIT and Bzr were all between 20-25%, and possibly within any margin of error. However, in the third through fifth choices, Bzr and Hg were favored as much or more than Subversion or Git.
  • Preferences for different roles in the project were clearly defined: Package maintainers and coders steadily preferred Git and Subversion. Translators and testers held the same preferences, but less strongly. Surprisingly, documenters preferred Bzr, but, since only four documenters replied, the validity of that result is questionable.
  • Those who wanted to switch, or were indifferent both strongly favored Git.
Newren's conclusion was that "there's a strong preference in the community toward switching, and that git has a strong lead in preference among the community."

As might be expected in an online discussion of FOSS, replies to both Esfahbod's publication of results and Newren's results were not long in coming. Still other comments were posted below LWN's brief mention of Newren's analysis.

Replies to the survey and analyses

Probably the most common criticism was that the survey was as much a popularity contest as anything else. Several commenters also wondered why other DVCS software such as Monotone and Darcs were not included in the survey (a question that, so far, no one has answered). In addition, some commenters were quick to talk about Git's shortcomings, while others — obviously unfamiliar with Git — asked questions about its features.

On the GNOME desktop-devel list, Esfahbod's announcement produced dozens of replies. One of the most articulate was by Andrew Cowie, who maintained that "The way the whole survey exercise was conducted it was impossible for Git to lose", and that the desired results were plain beforehand from discussion on the #gnome-hackers channel. Cowie also complained about the fact that GNOME contributors to projects that do not use Subversion were not invited to participate, and that the survey required listing preferences for all choices when he would have preferred not to vote for Git, Mercurial, or Subversion at all.

Much of the discussion below Esfahbod's announcement of the results, did quickly come to center on the assumption that a move from Subversion was now inevitable. Some questioned whether GNOME had the resources to devote to such a move, while others volunteered to be part of a task force to plan and implement the move. Another possibility raised was hiring someone to coordinate the change. Still others attempted to rough out the steps needed to move away from Subversion.

However, while most assumed — however reluctantly — that a change to Git would happen, others tried to raise alternatives. Some suggested that each separate GNOME module should be allowed to use its own DVCS, which others argued would discourage new contributors.

Others championed a suggestion raised on John Carr's blog that GNOME use its bzr-playground server and create plug-ins so that developers could use the DVCS software they personally preferred. However, this idea was dismissed by Esfahbod, who in a reply to the discussion about his announcement condemned such "hacks [developed] in house" because of the potentially high-maintenance they might require in the future.

In the end, however, the usefulness of these criticisms and alternate suggestions is limited. As Esfahbod states: "[...] This thread is not about making decisions. This thread is about giving those making the decision input they need to consider. Who makes the decision? Those who actually have to implement, oversee, and maintain any change" — in other words, the GNOME Foundation directors, and the project's release team and system administrators, the ones who commissioned the survey in the first place. The unspoken assumption in the survey appears to be that the move from Subversion is inevitable, and only the details are up for discussion. So far, though, those details have not been finalized, either by consensus or an announcement.

Meanwhile, for those unaffected by the decision, the survey and the resulting commentary provides a seldom-seen insight into the mindset of active members of the GNOME project — and, very likely, of active FOSS contributors in general.


(Log in to post comments)

GNOME considers DVCS choices

Posted Jan 15, 2009 4:35 UTC (Thu) by me@jasonclinton.com (guest, #52701) [Link]

I wish the author would have asked around a little on IRC or checked the Gnome Live wiki <http://live.gnome.org/GitMigration>. The decision to go forward with git has been solidified in the past few days due to a team of people with sufficient levels of access whom are Just Doing It. The test, read-write repo is already online and internally developers have already been asked to provide feedback on the conversion:

http://git.gnome.org/cgit/

This repo will be blown away and should not be used to pull *any* trustable code from during this testing phase.

So, no argument. Nothing to see here. Move along.

GNOME considers DVCS choices

Posted Jan 15, 2009 7:19 UTC (Thu) by DeletedUser32991 ((unknown), #32991) [Link]

If you permit an editorial suggestion: At least the first two paragraphs seem entirely untypical for the general style of LWN. Maybe LWN could encourage its authors more to take a closer look at how the "house style" differs from that of other publications covering free software.

GNOME considers DVCS choices

Posted Jan 17, 2009 8:33 UTC (Sat) by dirtyepic (subscriber, #30178) [Link]

People have their own styles. I don't think imitating the staff should be a prerequisite for writing an article.

GNOME considers DVCS choices

Posted Jan 17, 2009 15:35 UTC (Sat) by nix (subscriber, #2304) [Link]

One of the things that always impressed me about LWN was the consistency
of the house style. If you want to publish something in a different style,
very well, but why use LWN as your platform?

GNOME considers DVCS choices

Posted Jan 15, 2009 8:30 UTC (Thu) by rrdharan (guest, #41452) [Link]

Does anyone else find it depressing that Subversion seems to have had a real shelf life of only about
three years?

CVS sucked, but lasted like two decades. Now Subversion has come and is rapidly going away again.

I have no point here and I'm not trying to blame anybody for it (well arguably the SVN developers
simply aimed too low, but whatever). I just find it a little sad to think of all the work that must have
been put into the various projects that switched from CVS to Subversion, and I find myself
wondering if they could've avoided the intermediate step and just stuck with CVS for another few
years until Git/Bzr/Hg showed up.

Of course even if that were true there's no way anyone could've really foreseen how things
unfolded, but still. Just seems like a big waste of time.

Subversions Relevance

Posted Jan 15, 2009 8:58 UTC (Thu) by alex (subscriber, #1355) [Link]

It had been noted at the time when subversion came out that it was
just a stop gap measure. Essentially Subversion is CVS with some of
it's more glaring rough edges polished. As recently as last year I'd
been arguing that considering SVN as a migration from CVS was a
pointless exercise. In the end I just gave up, mirrored the CVS
repository with a few scripts to import into git and did my
development in git and exported when I needed to.

One thing SVN does have going for it though is the git import tools
for it are more stable than the CVS ones. If a project I'm interested
in hacking is still on SVN and doesn't already have a git repo
associated (most projects usually have at least one git fan already)
then I git-svn import it myself. I'd rather leave it to the core
developer/release teams to decide by themselves what they want to do
than adding my own 2p with a "Please considering migrating to..."
message.

Distributed VCS are the future. Personally I'm a fan of git but there is
scope for many different tools out there. Pretty much all of the open
source options have a good selection of import/export facilities that
allow non-core developers to use whatever their pet favourite DVCS is
to marshal their upstream patches. I'm hopeful that because of this
VC migration will be less of the barrier that it has been between the CVCS
and DVCS generations.

Obviously anyone considering a proprietary non-DVCS system to store
their open or closed source code in these days needs their heads
examining ;-)

Subversions Relevance

Posted Jan 19, 2009 21:22 UTC (Mon) by henning (subscriber, #13406) [Link]

I don't think that SVN was only a stop gap measure. Its way more better then CVS, its just works and its easy to use. Git its much more powerful, but it makes also easier to shot yourself in the foot. If you want to work with peoples that only develop in their spare time then svn helps to lower the barrier to participate. And If you need to motivate other developers to use a RCS effectivly in their daily routine, then you also don't want to make their life harder then necessary.

And as already noted in the comments, most projects (e.g. inhouse, only a few developers) don't need a DVCS. I don't consider the projects i work ATM as backwards, only because "we still use SVN". IMHO the quality of a project has nothing really to do with the flavour of RCS they use.

SVN 1.0 (released in febr. 2004) was more or less a better CVS. But the svn developers don't stopped there, 1.5.x has e.g. now a much more advanced merge tracking, they improved the repository disk layout, added changeset tagging and much more things.

Shooting in the foot

Posted Jan 20, 2009 8:31 UTC (Tue) by alex (subscriber, #1355) [Link]

GIT is actually fairly safe to use. You have to work quite hard to
exorcise history from the repository although granted most users don't
seem to be aware of the power of the reflog.

My point about ease of access for non core developers basically covers
anyone who wants to do a non trivial patch and not keep a whole diff
hanging around in uncomitted changes in their local copy of an SVN reo.

It's not dead yet

Posted Jan 15, 2009 9:41 UTC (Thu) by niner (subscriber, #26151) [Link]

Tough DVCS are very much on the rise in the FOSS community, there are places where
a centralized VCS is still the preferred way to go, which will likely stay that way. For
example for the in-house development stuff of the company I work for and for sure many
others. We do want to have everything centrally on our backed-up server and it's very
nice to have subversion available for that.

It's not dead yet

Posted Jan 15, 2009 9:49 UTC (Thu) by johill (subscriber, #25196) [Link]

It's not that a DVCS doesn't allow you to have that kind of workflow, if you look at the kernel you'll notice that it almost does have that workflow with many many maintainer trees being hosted on git.kernel.org. But I do agree that it's easier to enforce with svn, since it simply doesn't allow locally committing.

It's not dead yet

Posted Jan 15, 2009 13:50 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

Actually. plenty of developers on Subversion-hosted projects use svk locally to do their work, and then 'push' the results upstream. This is harder to setup and use than if the project used git. In addition, developers are now starting to use git-svn to do the same thing, so the days of the 'master Subversion repo' being the place where everything lives because the tool doesn't allow for any other mode of operation are already gone.

In the future, if the project needs a central 'blessed' repository and wants all work to be done in the open, those needs will have to be met through policy statements and enforcement, because the VCS isn't going to do it.

We have shared git repositories

Posted Jan 15, 2009 15:41 UTC (Thu) by emk (subscriber, #1128) [Link]

At work, we use shared git repositories on a central server. Everybody working on a given project has "push privileges", and they're strongly encouraged to push to master at least once per day.

This has a number of advantages:

1) Git is much easier to back up than Subversion. Correctly backing up Subversion requires an expensive hotcopy step (at least for our ~30GB repository). Git repositories can be backed up either by mirroring, or by straightforward disk backups, thanks to the reflog. (There's a way to recover a Subversion repository backed up in the middle of an operation, but it's messy.)

2) Git+SSH places a lower load on the server than SVN+SSH. At least for big repositories, Git's data structures take far less disk IO to initialize on first launch than Subversion's. This matters to people logging in via SSH.

From a sysadmin's perspective, git is well-behaved. And it supports a very wide variety of workflows, so not every project needs to work like the Linux kernel.

We have shared git repositories

Posted Jan 15, 2009 18:47 UTC (Thu) by drag (subscriber, #31333) [Link]

Ya.. Were I work we have a central Git server that is 'official' then each user hacks on their own little world.

Then when you want to submit your work you clean it up, make sure all the important revisions you've worked on are represented and push it back up to the central git server. That way you get the benefits of showing all the major stages you've gone through, and get it represented in the history on the main git server, in your own work while avoiding forcing users through the dozens of commits a hour you do while hacking away.

It's very nice to do a commit every time you close out a file or make a risky edit to something. The more you use it the more useful it gets.

GNOME considers DVCS choices

Posted Jan 15, 2009 14:50 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think that a large portion of the effort of converting from CVS to SVN was in figuring out what the projects actual history was (figuring out when files were moved within the repository and turning that into a history where the file was in the original location until it moved; figuring out which modifications were in the same commit, etc). SVN is able to represent project history in a clear way, and people are less likely to do strange things, so moving to another system is not so difficult, and the work of getting there from CVS would have had to get done anyway.

The tools for importing to git from SVN, for example, are pretty straightforward. The tools for importing to git from CVS are complex and do a lot of guessing about things that git needs to know that CVS doesn't preserve.

GNOME considers DVCS choices

Posted Jan 16, 2009 0:57 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Bear in mind that when SVN came out, there were already more technologically advanced options available. And SVN was still sorely needed. SVN's one great advantage over all of them (and Git): it's easy to migrate to it from CVS. The biggest cost of migration, remember, is the effort of users and administrators to learn the new thing. I have personally persuaded many reluctant people to move from CVS to SVN, using assurances like, "you'll use all the same commands: svn checkout, svn commit, svn diff, ..." I could never persuade these people to migrate to Git.

I spent an hour trying to understand Git recently, and ultimately had to put it off for some other time, because it's too unlike something I know and the documentation is too poor.

So while Git is going to do what Subversion's original competitors couldn't because Linus forced huge numbers of people to get familiar with it, I expect Subversion has a long life ahead of it.

GNOME considers DVCS choices

Posted Jan 16, 2009 15:35 UTC (Fri) by kevinbsmith (guest, #4778) [Link]

I'm not sure how long svn's life will be, but I agree that it was a useful transition. Moving our projects from cvs to svn was trivial, and we waited long enough for the end-user tools to have the features we needed. Basically, there was no reason to stick with cvs, at a time when it was not yet clear which dvcs we should choose. For many projects, it's still not clear which dvcs would be the best for that project.

On a personal project, I am now using bzr as the front end to an svn repository. Very cool. Yet another incremental step. I have been a strong dvcs advocate for a few years now, but a sudden complete switch is not always possible or smart.

GNOME considers DVCS choices

Posted Jan 20, 2009 13:30 UTC (Tue) by whacker (guest, #55546) [Link]

I have helped companies migrate from VSS to Svn.

Of all the features that I needed to demonstrate, the one thing the users (read: managers) wanted most was: restriction of commit access to specific folders in the same project! There was this strange fear that people would 'accidentally' commit to parts of the code they were not supposed to!

No amount of me convincing them that neither locking nor permissions were really meaningful in a version controlled system made any headway.

GNOME considers DVCS choices

Posted Jan 20, 2009 21:27 UTC (Tue) by jlokier (guest, #52227) [Link]

How are permissions not meaningful?

Sure, everyone's work is in the version history *somewhere*.

But it's easy to slip in a change which persists without anyone noticing, if there are hundreds or thousands of commits a week.

Changes to some code should be reviewed by people closely affiliated with that code, and permissions are helpful for ensuring that review does happen.

Permissions aren't the only way to ensure a particular workflow. Maybe triggers could flag when changes are made be people who aren't in a pre-approved list for a particular subsystem. Allowing changes and sorting out the conflicts afterwards are more in keeping with modern VCS methodology.

GNOME considers DVCS choices

Posted Jan 15, 2009 14:59 UTC (Thu) by clugstj (subscriber, #4020) [Link]

37% prefered to switch
48% chose Git

This is a "strong preference"? 48% of 37% is 18%. The only way to reach that conclusion is to have decided on it before the survey was done.

GNOME considers DVCS choices

Posted Jan 15, 2009 15:49 UTC (Thu) by appie (subscriber, #34002) [Link]

I might have missed something by not reading everything thoroughly through, but did a majority of developers express their discontent with e.g. svn and have many people pointed out missing features and such ?
Not saying there's no upside in choosing a dvcs especially for a group of geographically seperated developers, but I always wonder if a choice is made based on the 'ohhh shiny' techy factor or actually because something definitely is wrong with the existing product.

GNOME considers DVCS choices

Posted Jan 15, 2009 18:58 UTC (Thu) by bronson (subscriber, #4806) [Link]

If you actually read the survey results, you'll see that the conclusions are more rigorous than you imply.

GNOME considers DVCS choices

Posted Jan 16, 2009 19:51 UTC (Fri) by anton (guest, #25547) [Link]

I looked at Newrens analysis and my impression was that the results might be biased by the differing popularity of the systems, so in order to avoid that I took a look at people who are familiar with or regularly use at least two systems, and see what they prefer (ranking 1). Here's my analysis:
       familiar with
bzr&git    bzr&hg     git&hg  
54  git    16  bzr    33  git 
27  bzr    14  git    18  hg  
 7  hg      9  hg     10  bzr 
 5  svn     2  svn     7  svn 
 3  any                1  any 

       use regularly
git&bzr    bzr&hg   git&hg
10  git    3  bzr   7  hg  
 6  bzr    2  hg    5  git 
 2  any    1  svn   2  svn 
 1  svn             1  bzr 
 1  hg 

how to learn git?

Posted Jan 23, 2009 16:18 UTC (Fri) by astrophoenix (guest, #13528) [Link]

I've asked this before, and I'm going to ask it again I'm sure.

How in the world does anyone learn to use git?

I know how to use lots of VCS systems inside and out: CVS, svn, arch,
mercurial, darcs, even (shudder) perforce. I consider myself an expert in
all those systems.

I've tried to learn git at least 4 times, and I've failed every time to
get past the commit and push phase.

Frankly, I keep hoping that someday, someone will put a usuable interface
on it.

everyone always seems to rush to start using git, but I just don't
understand how they can get there. why is git so hard to use? why is it
so popular when something like mercurial is available, which is so simple
to learn?

any pointers? insight? please!

how to learn git?

Posted Jan 23, 2009 18:47 UTC (Fri) by obi (guest, #5784) [Link]

I'm not sure if this is helpful to you, but I can tell you what worked for me.

1) Understand the core concepts of blobs trees and commits (easy)
2) Start small. A small project that you start from scratch, with only one or two people involved. Up until this point it's pretty much like svn (linear).
3) Keep working locally in the beginning.
4) Get familiar with branching and merging, and with what branches, tags, remotes, etc represent. I tried avoiding conflicting merges at first (I used --no-commit a lot so I could see what was happening), and eventually I understood how merges work well.
5) Make mistakes, and understand how to rewrite history - undoing, rebasing, etc.
6) Start working with remotes, submodules, etc etc.

My point is that I started using git on real stuff, even with the little knowledge I had - and improved my understanding bit by bit. I felt it came quite naturally - everytime I felt I needed something, I just looked up if there was a feature for what I needed to do. There usually are; I discovered some really neat features this way (f.e. git stash).

Looking back I don't think learning git was hard: it was pretty logical and consistent, and the learning curve wasn't steep because you could start out with a small subset of the features/commands, and use more and more as you go.

Good info that helped me:
- Federico Mena-Quintero's "Pushing and pulling with Git" at http://www.gnome.org/~federico/index.html#git
- git help
- http://book.git-scm.com/
- http://git.or.cz/ and its wiki

Hope this helps at all.

how to learn git?

Posted Jan 23, 2009 20:36 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

I think the key is to avoid the temptation to try and sit down and learn all of git at once (especially all the different ways that git can be used)

there are a few core concepts that are really good to understand, but after that you should use it (looking things up or asking as you try to do new things)

the amount of git that you need to know to use it like CVS/svn/perforce etc is very small.

there are several 'how to use git for XXX users' documents out there, and many 'cheat sheets' that give approximatly equivalent commands for the different DVCS systems.

but trying to learn all of git before you start using it is like trying to learn all of perl from the man pages before you write 'hello world'

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds