Git vs SVN is an ongoing debate in the developer community. Both of the version control systems are different so the answer depends on your and your team’s needs. This page aims at highlighting the differences between Git and Subversion (SVN) without taking any sides and thus aiding you in the decision making.
The main point in Git vs SVN debate boils down to this: Git is a distributed version control system (DVCS), whereas SVN is a centralized version control system. The difference between these two is that in distributed version control system, every developer has their own local copy of the full version history, whereas in centralised version control systems the version history is stored in a server-side repository.
In order to make changes, each peer checks out the files they want to modify and commits changes to the central location. The main advantages in distributed version control system (Git in this case) are the speed of local operations and enhanced collaboration. Since the majority of the operations are done locally, you do not need a constant connection to the server where a central repository is located. As a result, operating a distributed version control system is a lot faster.
Since every peer in the same project has the full version history, they can share their changes between each other before pushing them to the central repository. This helps to collaborate more effectively, and ensure the quality of the code.
Centralized version control systems, such as SVN, performs better in situations, where you need to operate with large binary files or with very large code bases. This is explained in more detail in the next paragraph.
Storing large binary files in Git is problematic because every developer checks out the full change history of the repository on their computer. Thus, changes in large binary files cause Git repositories to grow by the size of the file in question every time the file is changed and the changes are committed. However, there are workarounds for storing large binary files in Git, even though the system in itself does not play well with them.
In SVN, only the working tree, which means the latest changes, is checked out on individual client machines so the change history of large binary files does not bloat the repository on the client machine as easily as in Git. Checkout times are thus faster for SVN when there are a lot of changes in binary files.
Due to better handling of binary files, SVN is more suitable for those developers, who need to manage graphical assets. Therefore, a lot of game developers and web designers have chosen SVN.
SVN is also often considered to be easier to learn, even for non-technical people, than Git. Of course, storing large binary files in any version control system is not considered to be sustainable. In Deveo, you can store and share these files in WebDAV repositories and avoid flooding your version control system. Keep in mind, though, that WebDAV doesn’t store the version history of the files.
Read more: Storing large binary files in Git.
In version control, branching means making a copy of the objects, such as source code files, that you want to modify. With branches, you can work on multiple different versions of your code at the same time, and finally merge the changes back together when you’ve made the changes. As a result, multiple contributors can work together at the same time without destabilizing the code base.
The concept of branching is a huge topic in the Git vs SVN discussion. It is generally considered to be easier and lighter in Git than in SVN. This is because a branch in Git is basically just a reference to a commit in the local repository. As a result, branches in Git are easy to create and can be published to your discretion.
In SVN, branching is based on directories inside the repository. Merging branches in SVN can cause problems if directories are renamed inside a branch.
The thing called 'tree conflict' can be avoided, however by limiting renames and doing refactoring only in the main branch (typically 'trunk'). SVN uses the Copy-on-Write strategy, which means that there is no need to make a physical copy of the whole branch, which reduces the repository size and the time of branching itself.
One of the main points in the Git vs SVN debate is the two system’s approach to access control. By default, Git assumes that all of the contributors have the same permissions. SVN, on the other hand, allows you to specify read and write access controls per file level and per directory level.
With Deveo, you can manage the access permissions for SVN and Git repositories on a project and even on a repository level. For Git, Deveo offers branch based security and access restriction.
With SVN, the change history of your repository stays the same except in very rare corner cases. When using SVN, it would require someone to have access to the centralized server to change the history of the repository. As Git is distributed by nature, it allows anyone to change any part of the history in their local repository. Pushing a changed history of the repository can cause problems if others’ work rely on particular changes.
Thus, the practice of changing the history of shared branches, such as 'master' is generally discouraged. Deveo has the ability to protect individual branches from being tampered. To encourage good practices, the master branch in Deveo Git repositories, is protected by default. Taking regular backups is highly encouraged in both Git and SVN. For example, if the disk on the central SVN server crashes beyond repair, you’ll be in trouble without backups!
In Git, the complete history of the repository is “backed” each time a developer clones the repository to their computer. Even though Git has a natural backup mechanism due to its distributed nature, it's not wise to neglect the importance of regular backups on your shared Git server.
If you are using Deveo’s cloud service, you can be sure that SVN and Git repositories will be safe and sound. Deveo takes daily backups and maintains two separate copies of the backups in two separate locations.
When using Git, you don’t need to have a network connection for most of the operations, as most of the operations are done locally. The only time you need a network connection to the shared Git repository is when you want to publish the changes you’ve made. Furthermore, since you always clone the whole version history of the project, you do not need to be connected to any server, if you want to check something in the version history.
As Subversion is centralized version control system and thus works in client-server manner, it requires you to have a network connection whenever you make a commit.
The difference in storage requirements are often argued in the Git vs SVN debate. However, there is no significant difference in the disk space usage between equivalent Git and SVN repositories, even though SVN tracks changes on a file level, whereas Git tracks changes in the repository level
Then again, If you are storing large binary files in version control (which you shouldn’t do), SVN repositories could be notably smaller than Git repositories.
This results from SVN’s xdelta delta algorithm that works both for binary and text files.
Host Git and SVN repositories for free
A general notion is that SVN is easier to learn, and also non-technical people get a hold of it quite fast. Both of Git’s and SVN’s primary user interface is through the command line but the command line syntax in Git is quite fuzzy for a beginner. Thus, SVN is more used by non-programmers, who want to version something else than code.
We have made Deveo a highly intuitive platform to use even for non-developers. Accessing the version history is by far easier through the Deveo UI than through command line or any other UI for SVN.
With this comparison, we wanted to give you tools to solve your inner Git vs SVN debate. The aim was not to argue that one is better than the other.
If you have come to the conclusion that Git suits your needs, that is awesome! The next step is to get your Git repositories up and running. Read more on how to host Git free in the cloud or behind your own firewall.
These systems are different from each other, and their workflows are different. This doesn’t mean that one is better or worse.
If you decided that SVN works better for you, then it is time to take things forward. Read more on how to host SVN repositories in the cloud for free or on your own premises.
You could also benefit from our Subversion tutorial.