SVN vs GIT

In the world of programming and engineering, it is necessary to keep track of changes during the application development process. This allows developers and programmers revert unwanted changes in applications under the development process. 

Version Control Systems (VCS) are stand-alone web 2.0 applications that have made the job easier by providing systemized management of multiple revisions of the same unit of information, whether it is a simple document or a digital document, such as source codes of applications or blueprints of electronic models. VCS allows developers to work collaboratively on the same application from different locations using repositories.

The two most famous types of version control systems are:
1-     Centralized version control system - subversion (SVN)
2-     Distributed or decentralized version control system - Git

In the case of centralized version control systems, there is a single central repository and all of the changes that are made to the documents are saved in that repository. There is a client server approach in the case of CVCS, where a single repository is stored on the server that clients can also sync up to.

In case of distributed or decentralized VCS, there is a peer-to-peer approach that clients can synchronize with by exchanging patches from peer to peer. Clients can make changes in the repositories and those changes will be local to them unless they synchronize with someone else. Depending on the requirements, Git also offers a centralized repository. In other terms, each peer has a bona-fide repository which is the working copy of codebase. DVCS provides independent as well as canonical repository.

SVN vs. Git
Both VCS and DVCS are highly appreciated by their users, but I have found that DVCS has some advantages over VCS. Let’s look at the concept of VCS and DVCS in detail by comparing the available systems of both types – SVN and Git.

• With Git, clients can commit changes to their localized repositories as new revisions while being offline. However, SVN does not provide this facility as user must be online in order to push to the repository from the working copy.
• SVN help is more organized and to the point while Git provides more than what is actually required. There is some time wasted since it is difficult to get a quick reference from Git’s search.
• Git’s complete copy of the data is stored locally in the client’s system so it is extremely fast when compared to SVN. With Git there is no time wasted when waiting for network response time, but with SVN it takes longer because all of the data is stored in a centralized repository.
• There is a smaller chance of data being lost in Git because data copies are stored locally in clients systems. The number of backups available is the same as the number of users on any repository. With SVN, if there is a data loss in the central repository, it will be gone forever.
• The Git repository has an efficient memory because the data’s file format is compressed, which is not the case with SVN. Also, there are always two copies of a file in the working directory of SVN. One copy is used for storing the actual work while the other copy contains the information used to aid operations (status and commit). Git has a small index file to store the info related to a particular file. When there are a lot of documents, there is a huge impact on disk space in the SVN compared with Git.
• Git DVCS is based on the concept of branching. The working directory of a developer is itself a branch. In Git, we can easily view the working directories of developers while they are modifying two or more unrelated files at the same time as different branches stemming from the same common base revision of the project. With SVN, there is almost no concept of branching
• In Git a large number of users can commit or push data to the same repository. If someone wants to push work in a Git repository, then there is no need to worry about data lost or immediate merging of others changes because commits are not sequential in Git like SVN.
• Git allows its users to have control over the merging of data in synchronized repositories. Merges are always pulled by someone and nobody can push to commit merges in someone else’s repository. The facility to merge data is also there in SVN, but it is somewhat incomplete. SVN merge records seem to miss some of the important details that Git keeps track of.
• Git keeps track of contents while SVN keeps record of files. Because Git keeps track of contents, whenever there is even a small change in content it tracks it as a separate change. Because of this, the history of a single file in Git is split.
• Git will not allow you to checkout a subdirectory. Instead, the user will have to checkout the whole repository.  In SVN, checkouts at subdirectory level are possible.

By looking at an overview of the features of Git and SVN, we can see that Git is preferable in most circumstances. Developers, researchers, engineers and other users of VCS have more inclination towards Git, so I predict that Git will be the future of revision control.

References:
“Git's Major Features over Subversion” retrieved Dec 15, 2008 from “http://git.or.cz/gitwiki/GitSvnComparsion”