GIT vs. SVN

1. Introduction

Version control systems track changes made on files. Thus, they provide ease of restoring the project’s files and its different versions. Moreover, they often allow multiple users to cooperate while working on the same files. Nowadays, it’s a must-have tool for every software development process, either commercial or personal ones.

In this tutorial, we’ll analyze and compare two of the most popular version control systems, namely GIT and SVN.

2. GIT

To begin with, let’s introduce the features of a common version control system:

• Stores project’s files and controls access to them
• Holds a history of file’s changes
• Provides possibility to create and retrieve the different versions of a project
• Represents documentation of changes
• Allows the team’s members to simultaneously work on the same files and synchronize changes
• Integrates with CI/CD pipelines

One of the widely used version control systems is GIT. It’s estimated that 72% of all repositories in the 2019 year used git. A repository refers to a storage container of a project’s files. GIT is a distributed version control system. It was originally created by Linus Torvalds to support the development process of the Linux kernel.

GIT is licensed under GNU GPL. Therefore, it’s free to use both for personal and commercial purposes. Furthermore, there are a lot of free GIT based repository hostings. It results in such great popularity of this version control system.

2.1. Characteristics

First of all, GIT supports branching. The branch is a separate instance of the project. They allow developers to work simultaneously on the same code base without disturbing each other. GIT provides a few algorithms to merge (synchronize) different branches. Further, it also allows adding custom algorithms on demand.

Secondly, GIT allows for working off-line. Every team member has a local repository on their own computer. Thus, they can save changes there without a network connection. While offline, changes can be stashed, branched, or committed. Then, while connected to an internet network, they can be pushed to a repository on the server.

Thirdly, GIT assures efficient handling of large size projects. Performance tests done by Mozilla proved that GIT is much faster than many competitors. Moreover, Linus Torvald described GIT as a very fast and scalable solution.

Further, GIT is compatible with many important protocols and systems, e.g., HTTP, HTTPS, FTP, SSH.

To summarize, GIT is a distributed version control system that provides efficient techniques for working with projects, especially large ones. Furthermore, it supports distributed workflows and guarantees comfortable ways of collaboration work.

2.2. Basic Commands

In general, GIT is a command-line based tool. It means that every feature can be accessed by executing the specific command in the console. Although there are a lot of graphical tools for working with GIT, the knowledge of the basic commands is crucial. In this section, we’ll define the most important ones:

2.2. Creating the Repository

To get a feel of working with GIT, let’s see how to create a new repository. The below instructions can be applied for any GIT-based hosting, like Github, GitLab, or BitBucket. The most popular of them is Github. It’s a powerful version control system and collaboration tool. It’s robust and the majority of features are free to use. So, it can be a way to go.

Firstly, we need to initialize our local project as a GIT repository using the below command while in the project’s directory:

git init

That command creates a .git subdirectory in the given location. It contains necessary metadata for GIT to handle the repository. Secondly, we need to add all the project files for GIT tracking. In order to achieve this, we can use a command mentioned in the previous section:

git add .

After that, all files are staged. So, we need to commit them to the local repository:

git commit -m "Initial commit"

Then, it’s required to connect to the remote repository. It needs to be done only once:

git remote add origin [repository-url]

Finally, let’s send everything to the server, to the default master branch:

git push -u origin master

3. SVN

The second well-known version control system is SVN. As we can see in the previously mentioned statistics, it’s used by 23% of repositories. So, it’s much less popular than GIT. Although, it’s still the second most used version control system on the market. It was created as a successor of an older system called CVS. SVN was designed to eliminate errors and limitations of its ancestor. Though, its goal is to be compatible with CVS as much as possible.

SVN is licensed under Apache License. Thus, it’s free to use for personal and commercial purposes. Although, there aren’t as many free hostings and tools for SVN as for GIT.

In the next sections, we’ll define the core concepts of SVN.

3.1. Characteristics

First of all, SVN requires a centralized server. In contrast to GIT, which is able to act as both client and server. Thus, SVN is called a centralized version control system. 

Secondly, SVN doesn’t provide advanced tools for branching. Branches are just so-called cheap copies of a directory. In simple words, a copy isn’t a literal copy of a file. Instead, it’s just a pointer to a specific revision. The advantage of this technique is that branches are lightweight. They require very little extra space to create.

Further, SVN is designed to work efficiently with binary files. That means it can be used for versioning documents, for example, ones created with Microsoft Office. Consequently, there are even tools dedicated for that purpose, such as MSOfficeSVN.

Due to the centralized nature of the SVN, everything is stored in a single repository on the server. Therefore, access control properties can be easily managed. Moreover, backups are simple, as there is only one location that needs to be handled.

Finally, SVN is considered easy to learn. Certainly, the learning curve is lower comparing to GIT. SVN uses mostly simple and straight-forward mechanisms, at least from the user’s perspective. However, it’s double-edged, as in some cases, some advanced features may be required for the versioning control.

3.2. Basic Commands

Let’s jump quickly into some basic commands of SVN:

3.3. Creating the Repository

Creating a repository depends on a few things, like the server’s operating system, the client’s operating system, or used protocol. Below are instructions that will create a repository from a local project, assuming that an empty repository is already set up on the server.

Firstly, we need to connect to a remote server by downloading an empty repository directory:

svn co [repository-url]

Then, we need to copy specific project files to the downloaded directory:

cp [local-project-directory] [local-repository-directory]

After that, all copied files need to be added for SVN tracking:

svn add [local-repository-directory]

Finally, we can send all files to the server:

svn commit

4. GIT vs. SVN

We already know the fundamentals of GIT and SVN version control systems. Let’s compare the differences between their core features:

So, which one to choose? Basically, as we can see in the comparison, GIT and SVN have some pros and cons. Firstly, we should always think about the demanded requirements and preferences, then choose one that fits them the most. Both of the version control systems are a powerful tool that supports the development process well. Although GIT is most popular due to its advanced branching and collaboration features, as well as a variety of free tools and hostings availability.

5. Conclusion

In this article, we described the two most popular version control systems, namely GIT and SVN. Firstly, we defined the core concepts of GIT. We explained its basic command and presented an example describing how to create a simple repository. Secondly, we characterized SVN in the same way. Finally, we compared the crucial features of both version control systems.