Is this project needed?

Welcome SubGit – out with Subversion, in with Git

Chris Mayer

Arriving at the perfect time, a new project that aims to ease the transition from the repository of old to the sleek new one. But is it worth it?

It can’t have escaped your attention that the Subversion is old
hat. Granted, it still has its uses, especially for older systems
reliant upon that repository, but this is the year of Git.

The new(er) kid on the block is capturing much more attention
for its rethinking of software version control. The most high
profile, or at least most talked about across Java in any case, is
Eclipse’s December deadline for all projects within the community
to move across to the distributed control system. This shift of
power has been talked about for some time (just by checking when
the first ‘Svn to Git’ blogpost appeared, you can see how long),
but only in the last 12 months have we seen a large number of
enterprises make the switch, according to numerous surveys.

Many larger enterprises face being left out in the cold if they
don’t follow suit, but with so much effort required to move hefty
repositories, is it really worth the effort them? Or more
importantly the outlay that comes with transferring.

Fortunately, a new project has shored up offering the best of
both worlds. SubGit is,
as you would expect, a bridge between the two repositories. The
software installs on the server side, holding two synchronised
repositories for both Git and Subversion. So, when a user makes a
change in one repository, this is automatically replicated in the

And again, this idea isn’t new either, SubGit was created as an
alternative to Git-Svn but this time round, SubGit aims to become a
guiding path for migration to Git in the longrun, by teaching the
user the merits of Git. It also holds advantages over its
competitor: rather than having every developer in your team learn
the intracicies of migrating, SubGit gives power to the system
adminstrator, who installs and configures. The rest learn Git at
their own pace. Some might take to it like a duck to water, others
might rely on Subversion as support – the learning curve is
entirely set by the user.

The convoluted process with Git-Svn is gone, with Git commits
being pushed the Git repository, which are then translated to
Subversion asynchronously when needed. Another benefit is the
freedom of tools on offer, as you can use any tool you like, either
integrate into the IDE or as standalone.

Having just unleashed a first release candidate for v1.0, it’ll
be interesting to see where this project goes from here. Alongside
the open source offering is a commercial pricing plan. You
can support up to three repository users and up to three different
repositories for free, but above that will set you back some
serious cash. A license for 10 committers and 10 repositoris sets
you back 850 euros a year, whilst it is 1600 euros for up to 25
developers and 25 repositories. That’s without factoring in a
year’s worth of support if you need it. Anything higher requires

This begs the question – is this project really worth it? Is
that outlay worth it to avoiding the pain of moving across to Git?
Tell us below – do you see worth in SubGit?

comments powered by Disqus