Version Control Software, a comparison

When we talk about Version control, subversion control and revision control, we are referring to different terms for a single solution that assists large projects from falling out of control by enabling individual programmers, a team of designers, or project managers to execute their projects from different perspectives. They do so without getting in each other’s way or causing any permanent damage.

Currently, there are a handful of solutions that exist in the market. We’ve formulated an elaborate feature comparison for you to choose the best one that works well for you.

Version control software, including the recognized SVN and GIT, was developed from the ground up for enabling teams of programmers to function on a project together. It ensured that no wastage of man-hours on paperwork was carried out. As an alternative of physically scanning branches of code and relevant notes, version control enabled for a central repository that is planned, rational, and helps out the file update process as well as merging.

Various opinions about the best version control framework exist in the market, which can lead programmers and project management teams into heated debates. While selecting the most accurate version control for your project, it must be taken into account that a few of the benefits of one package can be subjective. This implies that the judgment of the programmer, in addition to other factors including speed and IDE plug-in capabilities, overshadow the raw figures.

The major difference between version control systems is whether they are peer-to-peer or server based. Do they have a central repository where the code is checked out and back in with modifications, or a system where the code is habitually reorganized from peer sources, a more decentralized network, to keep the code up to date.

Apart from that, speed, functionality, and the learning curve of the system are also to be taken into account. To choose which solution is the best for your project and team, we will analyze at a few well known systems which are easily accessible.

Let’s see why some programmers prefer one system over the other.

Concurrent Versions System (CVS)

Since the 1980’s CVS has been around and doing well with both commercial and open source developers. Released under the GNU license, it employs a system to enable users for testing the code that is about to be worked on while also evaluating the check-in changes.

Initially, CVS managed conflicts between two programmers by only permitting for the most updated version of the code to be worked on. It was more like a first come, first serve system where the users had to quickly publish any changes for ensuring that no other user could beat them.

At present, CVS can manage branching projects so the developed software can be divided into various products with distinctive features to be reconciled later.

The CVS server functions on Unix-like systems with client software that functions on numerous operating systems. Famously reputed as the most mature version control system, as it seems to be available for a long time, it has presently not received that many requests for its features to be updated

Developed to run CVS on Windows servers, a fork project of CVS, CVSNT was created. At present, it is being aggressively developed to boost its functionality.

Good Things	Bad things
Has continuously been used for many years and has attained the status of mature technology.	Renaming file does not include a version update. Same goes for moving a file. Security dangers from symbolic links to files. No atomic operation support. This can cause source corruption. Branch operations are pricey as it is not developed for continuing branching.

Apache Subversion (SVN)

SVN was developed as a substitute to CVS that would fix a few bugs in the CVS system at the same maintains high compatibility with it. Similar to CVS, SVN is open source meaning it is free. The only difference is that it is distributed under the Apache license, contrary to GNU.

To thwart corruption in the database, SVN utilizes a concept known as atomic operations. That means that all changes are applied which are made to the source or none. This means that no partial changes will smash the original source. Several developers have shifted their focus to SVN as it is an updated technology that has made use of the best features of CVS and has enhanced them with the latest technology.

Although CVS’s branch operations are costly and do not actually provide to long-term forks in the project, SVN is developed to enable that. Meaning it lends itself better to large-scaled forked projects with various directions.

Disapproval of SVN may be owing to its comparatively slower speed and the absence of distributed revision control that uses a peer-to-peer approach rather than using a centralized server to stock up updated codes. Despite the fact that a peer-to-peer model would function superiorly for global, open source projects, it has not been declared as the most ideal one in other situations. The disadvantage of a dedicated server approach is that, if the server is down, the code is not accessible by any client.

Good Things	Bad things
Improved system derived from CVS. Incorporates atomic operations. Affordable branch operations. A broad range of plug-ins for IDEs. Peer-to-peer model is not used.	Is known for still containing bugs connecting to renaming files and directories. Inadequate repository management commands. Comparatively low speed.

GIT

GIT was initially developed by Linus Torvalds of Linux fame and adopts a non-conventional approach that diverges from CVS and SVN. The basic concepts for GIT were to create a quicker, distributed revision control system that would explicitly confront conventions and norms that are employed in CVS. Chiefly developed for Linux, it has the maximum speeds on there.

As there is no centralized server, GIT does not lend itself to single developer projects or small teams as the code may not necessarily be available when using a non-repository computer. To fix this issue, workarounds exist, and some view GIT’s enhanced speed as an honest exchange for the hassle.

Equipped with a broad range of tools to aid users in navigating the history system, GIT is very useful. Each case of the source comprises of the entire history tree, which can be helpful when developing in the absence of an internet connection.

Good Things	Bad Things
Good for people who are not fond of CVS/SVN. Drastic increase in operation speed. Inexpensive branch operations. Complete history tree accessible offline.	Not favorable for single developers. Inadequate Windows support as compared to Linux.

Mercurial

Mercurial was initiated roughly at the same time as GIT and is also a distributed revision control tool.

Originally developed to for rivaling with GIT for Linux kernel development, it has met with less success as GIT was selected. Nevertheless, it is being used by many major developments, including OpenOffice.org.

It diverges from other revision control systems as Mercurial is chiefly implemented in Python contrary to C. However, there are some instances where C is used.

Owing to its distributed environment and its creation in Python, several Python language developers are thinking of switching to Mercurial as it promises to permit non-core developers to have more convenient access to developing new trees and reverting any changes.

Users have observed that Mercurial shares a number of features with SVN apart from being a distributed system, and due to the similarities, for those who are already familiar with SVN, the learning curve will be less steep. Mercurial has full and complete documentation that will assist learning the differences much quicker.

A few important drawbacks to Mercurial entail its inability to allow for two parents to be combined and not like GIT, it employs an extension system instead of being scriptable. Although, this may be an ideal situation for some programmers, others discover the power of GIT to be an attribute they don’t want to exchange.

Pros	Cons
Convenient to learn as compared to Git. Comprehensive documentation. Distributed model.	No two parents can be merged. Not scriptable but extension-based Reduced out of the box capability.

Which System Should We Use?

Most generally, people employ CVS as they are already accustomed to it. Although, while a few of the quirks and restrictions are troublesome, they’ve already analyzed how to make a work around the specified limitations and have those workarounds applied. Particularly, if the project team is currently working on a specific project, the vision of shifting everything to another revision control is irritating, and if they were to shift, it would have to be SVN.

As it has now moved into the “mature technology” part of its life cycle, it is unlikely that CVS will come out with any groundbreaking features, and as momentum is lost in the project as people move to SVN, it appears most likely it is on its way out.

At present, SVN is crowned as the king of server-based version control. Owing to its superior features of CVS and enhancements, in terms of corporate interaction, we are more probable to come across CVS or SVN than with GIT or Mercurial. Therefore, an acquaintance with single server technology, although not a requirement, is sure smoothen workplace transitions.

Thanks its broad range of usage and its software maturity level, SVN enjoys a large knowledge base, and users will be able to access help easily offered from other users.

Evidently, GIT possesses improved speed as compared to its rivals, and is an obvious improvement for projects that lend themselves to distributed systems.

The major disadvantage noted for GIT is the fact that sometimes, it is very difficult to be explained to others, and there is possibly a deceleration in development as programmers adjust to it. However, when it is learned, the speed elevates and improved branch management will regain that time and more.

Many people are absolutely revolted by GIT which has its share of enemies in the programming industry. Mercurial bridges a gap between SVN and GIT that is comprehensively documented and employed in several reputed projects.

The version of GIT which is Windows-friendly has also made some advancement which brings the speed comparatively similar to that of the Linux versions. Therefore, it could still be available if you are not developing in Linux.

If you wish for have a single master source tree on which a small core development group is working on, SVN most definitely can serve to be the first system you choose as it’s dependable and is designed for that especially.

If you are initiating an open source project with several programmers working at different times or submitting numerous updates to the code, GIT serves as a superior choice for your project owing to its impressive speed and enhanced tree management as compared to SVN.

Stuck at somewhere in the middle? There’s always the good old Mercurial for you in case you are not fond of either SVN or GIT. However, SVN has proven to be the only modern system for handling any binary data in your project.

Each of the systems mentioned above are completely functional. Moreover, they’re also free. In the past, they have all been employed to develop software, websites, as well as operating systems that most of us have already used or have heard of.

My Personal Recommendation

After consulting some of the best software developers (friends, seniors, and colleagues in past organizations I have worked in) now working in different reputable organizations, conducting detailed study about version control software on internet, and keeping in mind the current work flow and working standards of our organization (Genetech Solutions) I have come to following analysis.

The two top most software version control tools currently being used all around us are GIT and SVN. So we should definitely implement any one of them because of their wide community support, flexibility, and popularity. No other such tool has been recommended by any source known to me. The main features of both systems are described in detail above.

GIT is far too complex to learn and grip over because of its LINUX based architecture and complex features which would take a lot of time to adopt and grasp for our developers and indeed our developers sooner or later will have to switch over to LINUX operating systems to have smooth compatibility with GIT’s features. As far as price and license is concerned, it’s totally free because of its GNU license like all other LINUX based products and open source nature. In GIT every team member has to create his own branch to commit his code to a remote server (many to one relationship). So every team member can work anytime and commit his/her code anytime from anywhere. Members can also work offline and merge their code to online server repository whenever he gets internet connection.

On the other hand we have SVN which is based upon the most popular and feature enriched versioning tools CVS (discontinued and not used by people anymore) and the most modern and latest available versioning tool. Unlike GIT it is not so difficult to learn and adopt and get going with it because of its compatibility with Windows operating systems. It is also GNU licensed and will be available free of cost. In SVN we’ll have to place whole source code (of our projects) on the central repository server which can also be setup in our LAN environment very easily. Once a project is setup and placed on central repository server, all the team members have to update their code from that repository and commit the code back to that central repository. SVN is best suited to organizations like us and most of my colleagues have also recommended it highly.

I have personally worked on many projects simple as well as complex with SVN versioning tool and have found it really very good for maintaining and versioning source code. We can retrieve, view and compare our source code right from the beginning of time at any time without any difficulty and eventually reduce the chances of our source code to be lost.

SVN also has a huge community of people all around the globe to help and assist whenever needed.

TortoiseSVN is an Apache Subversion (SVN) client, executed as a Windows shell extension. As it doesn’t demand the Subversion command line client to run, not only it is intuitive but very convenient to use. What’s more? It is absolutely free to use, even commercially. Undeniably the best Interface to (Sub)Version Control.

For using TortoiseSVN, a place for where your repositories can be situated is required. For this reason, you can either stock up your repositories locally for accessing them by means of the file:// protocol. Other than that, you can store them on a server to access them using http:// or svn:// protocols. Both of the server protocols can be encrypted as well. Use https:// or svn+ssh://, or even svn:// with SASL.

After considering all above situations and analysis, I would recommend to get started with SVN, it is by far most suitable versioning tool for our work environment.