Version control systems record changes made to documents or files. These systems save versions that have sub­sequently been changed during editing (with the inclusion of a time stamp and a user ID) so that earlier versions of these same documents or files can be accessed or restored at any time. This makes it possible to keep track of which users made changes to the items and precisely when they occurred. The main goal of such a system is to co­ordin­ate shared user accesses to multiple files and enable the sim­ul­tan­eous de­vel­op­ment of multiple branches. Typically, version control systems are used for software de­vel­op­ment, office ap­plic­a­tions, and content man­age­ment systems (CMS). The Apache Sub­ver­sion (SVN) and Git are among the most popular pro­grammes for version control, and these can either be installed on your own server or rented through a web hosting service. The most popular web-based hosting service for Git projects is GitHub. Sub­ver­sion hosting is offered by solutions such as RiouxSVN. Services like Source­Forge host both systems.

SVN: the CVS successor of CollabNet

CollabNet began de­vel­op­ing SVN in 2000 and launched its first version around four years later. With its release, SVN es­sen­tially became the le­git­im­ate successor of CVS (Con­cur­rent Versions Systems). In 2009, the project moved to the Apache Software Found­a­tion, changing its name in the process.

SVN relies on a cent­ral­ised system for version man­age­ment. Simply put, this means there’s a valid directory (re­pos­it­ory) which all users can access. Given that changes to files and documents aren’t linked with one another, this system prevents two users from sim­ul­tan­eously editing the same file. Following this set-up, the first user who accesses a file also presides over its editing rights, rendering it un­avail­able to other users to work on. Apache Sub­ver­sion is also capable of allowing any subpath to be down­loaded and edited in­de­pend­ently from the rest of its cor­res­pond­ing directory tree. This flex­ib­il­ity allows different users to be allocated varying read and write per­mis­sions for all paths. An ad­di­tion­al feature of Sub­ver­sions is that dir­ect­or­ies that are empty, unnamed, or have been moved can also be re­gistered without any concern over losses from their history occurring.

Git: the Linux kernel developer’s makeshift solution

In 2005, Linus Thorvalds, creator of Linux, began, more or less against his own will, de­vel­op­ing a new software for version man­age­ment. The reason: due to a licensing change with BitKeeper, Linux Kernel de­velopers lost their free access to the software system. What came in its place was a new system that features similar working struc­tures as those found within BitKeeper. Safe­guard­ing against in­vol­un­tary changes and high ef­fi­ciency are ad­di­tion­al tenants of this new system. After just a few days of work, Thorvalds presented his first version of Git.

Git is supported by a dis­trib­uted version control system. And while there’s a central re­pos­it­ory into which all changes flow, all users are still able to download their own working copies. This gives users access to the entire re­pos­it­ory, including the history, and frees them from having to maintain a constant con­nec­tion to the network. What’s more, changes are quickly trans­ferred into the main re­pos­it­ory. In ac­cord­ance with this setup, Git doesn’t offer a lock system; instead, each user generates its own branches that are then uploaded into the main re­pos­it­ory.

As per default, each user also is allowed read and write per­mis­sions for the entire directory (different access rights require different main dir­ect­or­ies to be set up). Every working copy is a distinct backup of the main directory, which is par­tic­u­larly ad­vant­age­ous should it mal­func­tion or incur any damage. Git only records the directory’s content, which is why empty dir­ect­or­ies are auto­mat­ic­ally deleted.

SVN vs Git: a system com­par­is­on

Is SVN or Git the better choice? Un­for­tu­nately, there’s no simple answer to this question. It depends on the needs of your project. Both systems differ in their struc­tures and the operating processes that result from these struc­tures. The following table is a summary of their most important dif­fer­ences:

  SVN Git
Version man­age­ment Central Dis­trib­uted
Re­pos­it­ory A central re­pos­it­ory in which working copies are generated Locally available re­pos­it­ory copies in which files and documents can be worked on
Access au­thor­isa­tion Path-based For the entire directory
Tracking changes Registers files Registers content
Change history Only complete in the re­pos­it­ory. Working copies only contain the newest version Re­pos­it­ory and working copies contain the complete history
Network con­nec­tion Needed for access Only necessary for syn­chron­isa­tion

Here are the ad­vant­ages of both systems:

Git should be used if …

  • you don’t want to be dependent on a constant network con­nec­tion in order to work on all parts of your project
  • you want to protect yourself from a loss or mal­func­tion of the main re­pos­it­ory
  • you don’t need read or write per­mis­sions for special dir­ect­or­ies
  • you‘re in­ter­ested in quickly trans­fer­ring the changes made to documents or files

Sub­ver­sion should be used if…

  • you need path-based access rights for different areas of your project
  • you wish to bundle all of your work to one centrally located place
  • you’re working with many large binary files
  • you wish to fully register the struc­tures of empty dir­ect­or­ies (Git disposes of these, as they contain no content)

If the listed features don’t appear to be of any clear relevance for you, then it might be worth trialing each version control system, to see which is right for you. Both systems offer help in the form of a large community, excellent hosting providers like GitHub, and pro­fes­sion­al support options.

Go to Main Menu