Apr 072008

There have been several requests about hosting Gtk+ (and GLib) as a Git repository recently and since that topic has come up more and more often, I meant to write about this for quite some time.

Let’s first take a look at the actual motivation for such a move. There are a good number of advantages we would get out of using Git as a source code repository for Gtk+ and GLib:

  • We can work offline with the Gtk+ history and source code.
  • We can work much faster on Gtk+ even when online with tools such as git-log and git-blame.
  • It will be much easier for people to branch off and do development on their own local branches for a while, exchange their code easily with pulling branches between private repositories, etc. I.e. get all the advantages of a truly distributed versioning system.
  • With Git it’s much easier to carry along big Gtk+ changes including history by using cherry picking and (interactive) rebasing.
  • We can make proper public backups of the source code repositories. This ought to be possible already via svnsync, but isn’t for svn.gnome.org because we run an svn 1.3.x server instead of an svn 1.4.x server that is required by svnsync. (Yes, this issue has been raised with the sysadmins already.)

A quick poll on IRC has shown that all affected core maintainers are pretty much favoring Git over SVN as a source code repository for GLib/Gtk+.

However, here are the points to be considered for not moving the repositories to Git (just yet):

  • Complexity; Git is often perceived to be harder to use than SVN, there are several attempts to mitigate this problem though: Easy Git Giggle yyhelp.
    With some of the above, Git is as easy to use as SVN is, so Git complexity doesn’t need to be holding anyone off at this point.
  • Git may be stable and mature these days, but git-svn is not there yet. It is generally good enough to create local Git mirrors of SVN repositories and work from those to have most of the Git convenience on top of an SVN project.
    But git-svn has seen structural changes recently, quite some rewriting and bug fixing that indicate it’s still too much in flux for the one-and-only SVN->Git migration for projects at the scale of Gtk+. This is not meant as criticism on git-svn, fairly the opposite actually. It’s good to see such an important component be alive and vivid. All issues I’ve raised with the maintainer so far have been addressed, but it seems advisable to wait for some stabilization before trusting all the Gtk+ history to it.
  • Gitweb interfaces already exist for GLib/Gtk+ mirrors, for example on testbit: Testbit Git Browser.
    These can be used for cloning which is much faster than a full git-svn import. Alternatively, shallow git-svn imports can be created like this:

      git-svn clone -T trunk -b branches -t tags -r 19001 svn://svn.gnome.org/svn/gtk+

    This will create a repository with a mere ~1000 revisions, including all changes since we branched for 2.12. We’re using such a shallow repository for faster cloning of our GSEAL() development at Imendio: view gtk+.git.

  • In summer 2006, we’ve had the first test migration of all of GNOME CVS to SVN, in December 2006 we’ve had the final migration. During that period, the Beast project stayed migrated to SVN to work out the quirks from the CVS->SVN migration before we migrate all other GNOME modules and have to fix up everyones converted modules. There were quite some issues that needed fixing after the initial test migration and in the end we had to rebuild the Beast development history from pieces. Preventing the other GNOME modules from such hassle was the entire point in migrating Beast early on, so I’m not complaining.
    However, given the size and importance of GLib/Gtk+, the development history of those projects shouldn’t be put at a similar risk. That is, GLib/Gtk+ shouldn’t be pioneering our next source repository migration, let some other small project do this and work out the quirks first.
  • git-svn already provides a good part of the Git advantages to developers while Gtk+ stays hosted in SVN. Albeit due to mismatching hashes, syncing branches between distinct git-svn checkouts of different people is tedious. Setting up an “official” git-svn mirror on git.gtk.org could probably help here. Also, to ease integration, jhbuild could be extended to use git-svn instead of svn commandos to update SVN modules, if the current module has a .git/ subdirectory instead of a .svn/ subdirectory.

The bottom line is, there’s a good number of advantages that Git already can (or could) provide for our development even without migrating the repositories to Git right away. When exactly will be a good point for migrating GLib/Gtk+ and possibly other GNOME modules might not be an easy call, but right now is definitely too early.

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookFlattr the authorBuffer this pageShare on RedditDigg thisShare on VKShare on YummlyPin on PinterestShare on StumbleUponShare on TumblrPrint this pageEmail this to someone

  8 Responses to “07.04.2008 On Moving Gtk+ to Git”

  1. There are a lot more things to consider. A replacement for svn:externals (submodules is not good enough)? I’m fortunately working with Elijah as still don’t understand Git, despite lots of effort. Further, use of DVCS seems to imply private repositories (in the homedir) — things I wouldn’t have considered.

    Btw: SVN sync will be available in max ~2 months, I could’ve provided nightly dumps if needed. Plus I agree that anything like ‘$RCS-svn’ is a big hack. Oh, I’m still not sold on Git (too damn complicated — and IMO to sysadmin it, I should at least understand it).

  2. Complexity; Git is often perceived to be harder to use than SVN, there are several attempts to mitigate this problem though: Easy Git Giggle yyhelp.

    It seems there is a proliferation of these “helpers” recently. Have you seen Thomas Zander’s[1]? It would be nice if people could collaborate with git upstream to solve the UI problem for once instead of everyone having their own “home made” interfaces.

    [1] http://labs.trolltech.com/blogs/2008/03/30/sourcecode-collaboration/

  3. Believe it or not, git is hard to use! I download cairo tarballs because “git pull origin” (or whatever that is, I never can remember it) sometimes fails for reasons unknown to me, and checking out a fresh copy is too slow. SVN sucks, yet it is good as a system which is to be used by lot of people, unless you are Linus or Havoc and you know that git is better for everyone else.

  4. SVN is the worst versioning system that I know, equality with CVS. I personally like GIT, but I’m sure there is other good systems like bzr…

    As maintainer of Empathy I more and more think about moving to git, the only problems I have with git is when it interacts with SVN using git-svn. If we drop completely svn and move to git.gnome.org it will be *far* easier to me and other developers.

    I can’t understand the argument “svn is easier than git”, there is a small set of commands to know, like for every tools. I wrote a little howto [1] that explains how I use git for empathy coding, there is nothing hard in that.

    So definitely +1 from me to move away from SVN to anything else… and git is a good candidate.

    [1] http://live.gnome.org/Empathy/Git

  5. Sooner or later people will figure out that git is not harder to use than cvs or svn, and see the benifits. But it requires that you rethink how version control works, and if necessary that you, the proud developer and expert in svn, actually ask someone else if you do not understand it.

  6. Note that ignoring the complexity of Git by saying that you only use a subset of the commands is not at all useful.

    The Git tutorials have severe drawbacks. The man pages are too complex, etc. Even just copying commands from someone else doesn’t work — you get error messages that do not make sense (e.g. that some file already exists while it doesn’t).

    I do not appreciate saying Git is easy, or that the complexity can be ignored — it just isn’t the case. A more constructive approach would be to check if it will be made easier in a year or so.. or that the benefits together with a frontend outweigh the complexity.

    I’m not an SVN expert, I don’t want to be a Git/Bzr/Hg expert. That is for others.

  7. Any reason to not consider bzr? I find it rather easy to use, and it’s a GNU project now. While I cannot offer detailed comparisons with git (I found it too hard to use at first, and have to get back to looking at it), it’s got the advantages of being distributed, reasonably fast, able to work with SVN (I do so with an application I maintain for a company on a regular basis), and lets you customize/extend it locally by defining command aliases for things you often do.

    Just my 2ยข. ๐Ÿ™‚

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>