GIT vs SVN

GIT vs SVN

In the DevOps world, selection of right SCM tool is a significant decision. Since these tools are kind of driving force behind the process, a wrong SCM selection may lead to inefficiencies throughout your delivery pipeline. I personally have used CVS and SVN in most part of my career. Those projects were not really Agile projects. While we had some kind of CI and CD, there were no end to end DevOps process in place. So we were able live with it.

Recently I started using GIT - both private GIT as well as public GITHUB and BIT BUCKET.  Also in the recent assignments, we don't just go with what is provided by customer. We demanded the right SCM. We study the customer needs and recommend centralized or distributed SCM. 

In this blog, I will  compare the capabilities of GIT and SVN at very basic level. This blog does not cover the detailed scenarios like when GIT performs better over SVN and vice versa or how GIT's way of working on the content instead of file helps in some large assignments.

S. No	GIT	SVN
1	Distributed Source Control - Developers can work offline on their local repository and keep committing so that they can do back to the earlier version if something goes wrong. Once they are online, they can push the changes to the master repository. So consistent code in Master repository. If any repository is lost due to system failure only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other this tends to be a small amount of loss, if any. GIT supports single repository too.	Centralized Repository - You cannot have offline repository in your laptop. So the developers has to be connected to SVN to commit and working offline is not easy. Loss of central repository needs recovery from backup and changes since that last backup are likely to be lost (Many man days of effort) Advantage of Single repository is that  there is little doubt about where something is stored.
2	Performance - Extremely fast  since all operations (except for push and fetch) are local there is no network latency involved	Performance - Slow Compared to GIT as all the file history and version info is present centrally
3	Storage/Space Requirements - Git repositories are much smaller in file size than Subversion repositories	Storage/Space Requirements - May need more space than GIT
3	Branching and merging support is a lot better. Git provides better auditing of branch and merge events	Branching and merging is good for small projects
4	Usability - Bit complex than SVN For newbies, need some additional learning as it is different from SVN. Also more concepts and more commands. The developers need to understand when to use checkout vs clone; commit vs push	Usability - Simple to use because Very limited concepts and commands Every revision is numbered sequentially and it is easy to walk through Better client GUI tools
5	Access Control - Due to being distributed, you inherently do not have to give commit access to other people in order for them to use the versioning features. Instead, you decide when to merge what from whom.	Access Control - Because the repository is centralized and every developers needs commit access, it is really difficult to have repository owner.