Welcome SubGit – out with Subversion, in with Git
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 other.
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 negotiation.
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?