There are many challenges and problems during collaboration on software development projects, such as keeping track of the latest version and previous changes, code integration, multiple people working on the same file at the same time, etc. Many of these problems can be minimized or solved using version control software. Two of the most popular version control solutions are Git and Apache Subversion (SVN). Each has its own advantages and characteristics, which will be discussed in this article.
Distributed or Centralized
This is the main difference between Git and SVN. Git is a decentralized, while SVN is a centralized version control system. What does that mean? In a centralized system like SVN, there is only one central repository and all changes are submitted to it. In decentralized version control systems, each developer has his own repository on his local machine, in addition to the central repository. In other words, Git allows developers to use version control features in local environment and without an internet connection.
Also, decentralized systems are more resistant to failures and crashes. Every user has a complete backup of the repository on his local machine. For example, if you have 20 users, it means that you would have 10 repository backups located on 10 different machines. In case of a failure, only a small amount of changes would be lost. SVN stores complete history of changes only in the central repository. If a disaster strikes, all changes since the last backup would be lost, which could take a couple of days of work to restore.
Git performs most of the operations locally. Since only push and fetch operations require an internet connection, there is no network latency when merging branches, switching branches, viewing file history, etc. This approach makes Git much faster than the SVN, which retrieves all the data from the central repository.
Git also takes up less space on the hard drive. Using a good compression algorithm, a Git repository can take up to 10 times less space than the SVN repository. For example, Mozilla repository has taken up around 12GB of disk space using SVN, while the exact same Git repository would take up only 420MB.
On the other hand, when checking out, Git version control system always downloads the entire repository. It is not possible to download only a single directory — a feature that is available in SVN and that makes SVN use less bandwidth than Git.
SVN provides centralized access control — you can specify read and write access in a single place and apply the rules to the entire project. Also, all code is stored in one location, which is useful if you have a critical piece of code that you don't want anyone to access. Furthermore, SVN allows you to control access to specific directories or subdirectories, which is not possible with Git.
SVN assigns revision numbers sequentially, starting with number one. Git uses SHA1 hash function to uniquely identify a revision. As a result, a revision number in Git is a 40-character hexadecimal string that identifies a revision and the branch it belongs to.
Many people find SVN's solution more convenient, since it is very easy to look at differences between multiple revisions or revert to an old version if needed.
Line Ending Conversion
Line ending conversion is a very useful feature that automatically converts line endings to CRLF or LF, depending on the user's operating systems. This makes the process of collaboration between Windows and Linux users easier. Both version control systems can be configured to convert line endings. However, Git does that automatically — you don't have to specify which files the conversion should be applied to.
To summarize — use Git if:
- You need version control features without internet access
- You want a system that is easier to restore in case of a failure
- Speed of operation is important
- Your developers use different operating systems
On the other hand, choose SVN if:
- You want all code to be stored in one place
- You need centralized access control
- Bandwidth is an issue and you want to use less bandwidth
- Easier revision history lookup is needed