Subversion to GIT; a change in direction?

This is a guest post to the Computer Weekly Developer Network by Chris Lucca, technical evangelist for software configuration management (SCM) and Agile ALM company AccuRev.

Git is undoubtedly attracting more and more fans because it is fast, flexible, simple to learn and rich in developer-friendly features. As an increasing number of developers are applying pressure to make the move to Git, this article provides high level guidance to the management team on the implications of such a move on an enterprise and why the leadership team should care.

If software configuration and change management (SCCM) tools had never existed, then we may arguably have gone on interminably without the speed and efficiency benefits that version control systems bring to bear upon modern programming environments.

But software application development shops of all sizes have always known that they need to create, maintain and uphold performance and control over the code base at all times if they are to meet deployment targets and user requirements — so we might argue that a certain inevitability has always been at work in this space.

So SCCM (or revision control if you prefer) was always destined to organically evolve out of the collective need to provide technical source code management functionality. As the use of collaborative tools from Post-It Note reminders and then to emails and onward to wikis and instant messages have developed, the globally distributed nature of software teams has also expanded — and this has made these tools more important every day.

So version control grew and leant to walk up straight and eventually many developers grew tired of proprietary tools in the space, impressed by their enterprise-class power but held back by either their lack of speed or inflexibility – or indeed both. Now as Apache Subversion and Linus Torvald’s Git exist today, we know that we have a choice when it comes to open code commit and control software — so which way should we turn when we need to make this trade-off?

The trade-off

Actually it’s not so much a trade-off between Git and Subversion; each has their relative virtues and distinguishing characteristics, but it is the overall functionality which will now dictate both project’s longevity as programmers chose one system over another.

As with almost all strains of open technology, at a deeper enterprise grade deployment level we find the extended ground of commercially supported iterations. The ability to offer the power and flexibility of a tool like Git but augmented, enhanced and enriched with the necessary levels of security, auditability and development process visualisation are what drives the current bleeding edge of SCCM technology today.

The facts are that there are (yes, commercially supported and therefore coming at a cost) routes to improved functionality with Git in this space. But this is a cost that many customers will be able to identify that they need to invest in (alright, I mean “paying for”) because they can also see a route to leveraging (alright, I mean “using”) more powerful process management.

Organic “extensions” to open source

These are the kind of natural extensions which will always naturally and organically come about out of an initially open source project once it moves into the commercially supported realm purely because of factors which I can only put down to the laws of economics and natural selection, i.e. they simply work better so financially accountable firms see these options as route to increased return on investment and ultimate profits.

I could go on here. The benefits are multifarious, manifold and (in my not so humble opinion) quite marvelous. Substantial tangible real world benefits exist in extended iterations of the Git universe such as the option for developers to interact using collaborative tools before code commits are made – it’s always good to talk right? There are also options for workflow management and deeply integrated issue-tracking, software development process visualisation – the list goes on.

In the dying days of the Sun Microsystems empire before Oracle came to town company CEO Jonathan Shwartz was often known to say that Solaris and the tools were all there and were all free – but when people needed service and maintenance, Sun would be there to support them. Extended, enhanced, supported versions of Git follow something of the same ethos i.e. a higher path is attainable for businesses that need it.