Git vs. SVN – Version control Systems in Comparsion

Version control systems record changes made to documents or files. These systems save versions that have subsequently 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 coordinate shared user accesses to multiple files and enable the simultaneous development of multiple branches. Typically, version control systems are used for software development, office applications, and content management systems (CMS). The Apache Subversion (SVN) and Git are among the most popular programmes 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. Subversion hosting is offered by solutions such as RiouxSVN. Services like SourceForge host both systems.

SVN: the CVS successor of CollabNet

CollabNet began developing SVN in 2000 and launched its first version around four years later. With its release, SVN essentially became the legitimate successor of CVS (Concurrent Versions Systems). In 2009, the project moved to the Apache Software Foundation, changing its name in the process.

SVN relies on a centralised system for version management. Simply put, this means there’s a valid directory (repository) which all users can access. Given that changes to files and documents aren’t linked with one another, this system prevents two users from simultaneously editing the same file. Following this set-up, the first user who accesses a file also presides over its editing rights, rendering it unavailable to other users to work on. Apache Subversion is also capable of allowing any subpath to be downloaded and edited independently from the rest of its corresponding directory tree. This flexibility allows different users to be allocated varying read and write permissions for all paths. An additional feature of Subversions is that directories that are empty, unnamed, or have been moved can also be registered 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, developing a new software for version management. The reason: due to a licensing change with BitKeeper, Linux Kernel developers lost their free access to the software system. What came in its place was a new system that features similar working structures as those found within BitKeeper. Safeguarding against involuntary changes and high efficiency are additional tenants of this new system. After just a few days of work, Thorvalds presented his first version of Git.

Git is supported by a distributed version control system. And while there’s a central repository into which all changes flow, all users are still able to download their own working copies. This gives users access to the entire repository, including the history, and frees them from having to maintain a constant connection to the network. What’s more, changes are quickly transferred into the main repository. In accordance with this setup, Git doesn’t offer a lock system; instead, each user generates its own branches that are then uploaded into the main repository.

As per default, each user also is allowed read and write permissions for the entire directory (different access rights require different main directories to be set up). Every working copy is a distinct backup of the main directory, which is particularly advantageous should it malfunction or incur any damage. Git only records the directory’s content, which is why empty directories are automatically deleted.

SVN vs Git: a system comparison

Is SVN or Git the better choice? Unfortunately, there’s no simple answer to this question. It depends on the needs of your project. Both systems differ in their structures and the operating processes that result from these structures. The following table is a summary of their most important differences:

  SVN Git
Version management Central Distributed
Repository A central repository in which working copies are generated Locally available repository copies in which files and documents can be worked on
Access authorisation Path-based For the entire directory
Tracking changes Registers files Registers content
Change history Only complete in the repository. Working copies only contain the newest version Repository and working copies contain the complete history
Network connection Needed for access Only necessary for synchronisation

Here are the advantages of both systems:

Git should be used if …

  • you don’t want to be dependent on a constant network connection in order to work on all parts of your project
  • you want to protect yourself from a loss or malfunction of the main repository
  • you don’t need read or write permissions for special directories
  • you‘re interested in quickly transferring the changes made to documents or files

Subversion 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 structures of empty directories (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 professional support options.

Was this article helpful?