svk vs. git for xulrunner maintenance

I’ve been using svk for xulrunner maintenance since the first test packages. And I’ve been thinking about switching to git for a while now. I did some testing in march, which led to my post about diffing. I went a bit further today by actually trying to convert my svk repository. And I got both interesting and surprising results.

The repository is (only) about 250 revisions in svk, and includes 15 upstream releases (or CVS pulls). I had to reorganize the svk repository so that git-svnimport could do its work properly.

[ Note: these tests have been done on a 5 years old laptop ]

The first surprise is the time it took for the conversion : almost half an hour. Dumping (svnadmin dump) and reloading (svnadmin load) the svk repository takes a bit more than 3 minutes, in comparison… I guess git-svnimport is very ineffective.

The second surprise is that the svk repository is actually almost twice as small as the git equivalent: 116MB for svk vs. 224MB for git.

On the other hand, git is amazingly fast. One of the most common things I do on this repository is a diff between the upstream branch and the trunk. I create the .diff.gz file I give pbuilder this way. It’s much quicker than doing a real dpkg-source, especially considering pbuilder does one itself.

After dropping caches (echo 3 > /proc/vm/sys/drop_caches), such a diff takes about 50 seconds with svk and… a little more 2 seconds with git. Without dropping caches, it gets down to 38 seconds with svk and… 0.05s with git. That is pretty damn fast !

Update: after a git repack -d, the git repository is down to 61MB.

2007-07-02 22:12:18+0900


Both comments and pings are currently closed.

7 Responses to “svk vs. git for xulrunner maintenance”

  1. Pistahh Says:


    1. instead of git-svnimport please take a look at git-svn (it is also part of the git suite).

    2. after doing the import do a git-gc. (part of git 1.5.*). That should reduce the git repository size.
  2. Anonymous Says:

    “git svn” does work better in general, and likely wouldn’t have required reorganizing the repository; however, it requires a few options to tell it not to set up for continuing to work from SVN. It does, however, have some interesting options for working with svk.

    “git repack” does help hugely, as you observed. “git gc” runs repack and various other repo maintenance tools, and it will make some other git operations fast as well; in particular, it will pack the myriad references (tags) in the repository. Ideally the various import tools should always run “git gc” after they finish.

  3. Emanuele Aina Says:

    The mozilla people have expressed their preferences toward Mercurial and they already have a repository that mirrors their CVS at

    Mercurial is very similar to GIT in behavior and performances, and it has a command-line which is a little simpler and cleaner than the GIT one.

  4. glandium Says:

    Emanuele: I know, but it doesn’t prevent using git ;) Anonymous, Pistahh: unfortunately, I started my repository with a bad layout and changed it afterwards. It makes branch handling of either git-svn or git-svnimport fail at detecting what happened. I’m writing a script that should be able to cope with my bad behaviour (and additionally, allow me to import in either git or mercurial).

    [ Note subversion, not having strongly enforced tagging, encourages users to do hackish things, such as committing changes under tags… ]

  5. Peter Says:

    @Glandium: In newer git versions, there is a “git-filter-branch”, which will allow you to apply a filter to the git history (e.g. remove files, reencode commit logs to utf8, rearange directory layout etc) so this could be used to “fix” your history after the import.

    I think if you already got a perfect git import, there exists bidrectional converters which allow you to create an aquivalent mercurial repo, or vice versa.

  6. regeya Says:

    heh, I just converted my local svn repos to git, and even after a git-gc my git repos are about 20% larger than the svn repo.

    I guess I’m going to keep using svn for now; sad, because I was looking forward to these huge space savings I keep hearing about.

  7. glandium Says:

    regeya: I guess your .git directory is cluttered by the .git/svn directory, which is a big disk space hog for no good reason. There is surely space for improvement in git-svn.