Stand aside SVNSVN’s time at the forefront of source control may be coming to an end.  There’s a newer, quicker, lighter and more flexible solution : GIT

From the worlds most famous open source developer, Linus Torvalds, it’s the latest and greatest way of working with collaborative projects alongside developer from all corners of the globe.  Linus is the developer who started work on the Linux kernel way back in 1991. He inspired the world with his ‘hobby operating system’ and changed the way software of this type can be developed. Collaboration between disparate developers flourished and, as the project gained steam, more and more developers from around the world were chipping in and sharing code with each other via SVN.

SVN (short for Subversion) holds a distinct image of code files at certain intervals called revisions.  Every time a change is made, a new revision is created and the old image is archived.  Archiving is required so that any changes which are made that are found to be incomplete or flawed cam be rolled back and started again.

This does happen quite frequently in open source projects.  While the amount of code generated in open source projects can be voluminous, the quality of it is assessed be public committee which may or may not agree with the developers logic and/or coding style.  So, changes are frequently rejected or submitted for further revision before being appied to the main development files which would then be compiled into the next release

However, consider the facts.  The Linux kernel currently consists of 13,320,934 lines of code split out over many thousands of files.  In order for these to be compiled, a version for each one of those files is held in many hundreds of thousands of states. A developer might only changes one word in one line of a file, but the whole file is taken as a revision and stored in the archive, ready to be rolled back at a moments notice. SVN was becoming cumbersome by design

So, Linus himself developed a new way of mapping just the changes to a file, rather then the entire file.  This makes for much smaller databases which can be updated in a much smaller timeframe than is possible with SVN.  GIT still has the concept of a central location for the main files, called a repository.  Developers can be given access to the files over the web and the files can be downloaded in their entirety.  This is where the similarity to SVN ends though.  The act of downloading the files creates another mini-repository local to the developer.  Changes made to any of the files are made and can be compared to his or her local repository, which allows for local rollbacks and updates before being uploaded back to the central repository. 

The uploading is magical. The files are tracked by the developer’s local repository and small sets of “deltas” are created, mapping out the lines of code which have been added/edited/deleted so these deltas can be applied to the central repository, without the need to upload the whole file, which can be many thousands of lines long.  The beauty of GIT is in it’s delta and merging capabilities.  It’s internal merger is of such great quality that manual merging of files (comparing them side-by-side and manually selecting the lines from each file that should be kept) are, almost, a thing of the past. 

The repository itself has some great features for developers to peer review between themselves before submitting them for a central review.  Paired programming can be of great benefit in stopping those nasty bugs getting in and ruining a good commit. 

The learning curve for GIT can be a bit overwhelming when coming from an SVN background, but you wouldn’t expect anything else from the world leader in geekonomics.  The commands are all written in the shell rather than using any form of drag & drop based system utilised in windows, makes perfect sense though since 99.999% of Linux programming is done in the terminal with no icons or windows in sight!!