Version control systems record changes made to documents or files. These systems save versions that have sub­se­quent­ly 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­or­di­nate shared user accesses to multiple files and enable the si­mul­ta­ne­ous de­vel­op­ment of multiple branches. Typically, version control systems are used for software de­vel­op­ment, office ap­pli­ca­tions, and content man­age­ment systems (CMS). The Apache Sub­ver­sion (SVN) and Git are among the most popular programs 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­tial­ly became the le­git­i­mate successor of CVS (Con­cur­rent Versions Systems). In 2009, the project moved to the Apache Software Foun­da­tion, changing its name in the process.

SVN relies on a cen­tral­ized system for version man­age­ment. Simply put, this means there’s a valid directory (repos­i­to­ry) which all users can access. Given that changes to files and documents aren’t linked with one another, this system prevents two users from si­mul­ta­ne­ous­ly 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­pen­dent­ly from the rest of its cor­re­spond­ing directory tree. This flex­i­bil­i­ty 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 di­rec­to­ries that are empty, unnamed, or have been moved can also be reg­is­tered 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­vel­op­ers lost their free accesses 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­cien­cy 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 repos­i­to­ry into which all changes flow, all users are still able to download their own working copies. This gives users access to the entire repos­i­to­ry, 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 repos­i­to­ry. In ac­cor­dance with this setup, Git doesn’t offer a lock system; instead, each user generates its own branches that are then uploaded into the main repos­i­to­ry.

As per default, each user also is allowed read and write per­mis­sions for the entire directory (different access rights require different main di­rec­to­ries to be set up). Every working copy is a distinct backup of the main directory, which is par­tic­u­lar­ly ad­van­ta­geous should it mal­func­tion or incur any damage. Git only records the directory’s content, which is why empty di­rec­to­ries are au­to­mat­i­cal­ly deleted.

SVN vs Git: a system com­par­i­son

Is SVN or Git the better choice? Un­for­tu­nate­ly, 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
Repos­i­to­ry A central repos­i­to­ry in which working copies are generated Locally available repos­i­to­ry copies in which files and documents can be worked on
Access au­tho­riza­tion Path-based For the entire directory
Tracking changes Registers files Registers content
Change history Only complete in the repos­i­to­ry. Working copies only contain the newest version Repos­i­to­ry and working copies contain the complete history
Network con­nec­tion Needed for access Only necessary for syn­chro­niza­tion

Here are the ad­van­tages of each 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 repos­i­to­ry
  • you don’t need read or write per­mis­sions for special di­rec­to­ries
  • you‘re in­ter­est­ed 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 di­rec­to­ries (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