We weren’t involved with Subversion from the start, our experiences gradually pushed us towards it.


In the days before the rise of GNU software and the popularity of the open source Unix flavours, some of our founding team worked on proprietary AT&T Unix and used SCCS for version management of our source code. This was well integrated with the Unix make whose default rules would check out a source file from SCCS before compiling, if SCCS had a copy.


When moving from AT&T Unix, it was natural for us to move to the more modern RCS on Linux systems. We were informed that RCS improved check-out performance dramatically because it maintained the last snapshot in its files, while SCCS maintained the first snapshot and a series of deltas, thereby forcing the user to wait while it applied each delta on the image each time a user checked out a file. We never felt the performance difference during checkouts, but we moved because there is no SCCS available on open source platforms.

The Wood For The Trees

The problem with both SCCS and RCS was that they worked on individual files while other version control systems were tracking entire trees. We moved from RCS to CVS because we could run one command and check out or commit an entire tree. We were also comforted by the fact that CVS uses the RCS file format for storing revisions internally. This move happened in 2001.

Tree Versions

We moved from CVS to Subversion to take advantage of various added features, including excellent integration into various project tracking and issue tracking systems, built-in HTTP based access, and versioning of an entire tree. CVS has a version number for each file, and does not track files committed together as a single set of changes. SVN on the other hand does this, thus helping the developer track and correlate the exact set of files which changed in a specific commit. SVN also supports good tools for repository snapshots, replication, etc.

Tagged Releases

In one area we are more comfortable with the CVS approach of doing things than the SVN approach. CVS can tag a snapshot of an entire tree. If this tag is not deleted, it can be used by any developer to check out an exact snapshot of the tree at the time of tagging. A tagged CVS version never changes its contents — it is a frozen snapshot. This is ideal for tagging a specific version at the time of releasing a new version of a product or system. SVN does not support tagging as tagging — it implements a tagged version as a branch, and a developer can check in changes into a tagged version. Therefore, an SVN tagged version is not a frozen snapshot. We are working around this philosophical difference.


Today we work with SVN for all new development projects. We have integrated Redmine with SVN and use Redmine for correlating issues/tasks with SVN commits. We have some key developers working from outside office. The Redmine+SVN server is available on the Internet and is accessed by various developers and managers from various locations. This is working out very well.

We also have a legacy installation of CVS for older projects and for corporate files. We keep all invoices, offers of employment, proposals, correspondence with customers, etc. in this CVS repository and we have not found the need to migrate this to SVN. One of the basic reasons to use CVS for such files even if they do not exist in multiple versions is to prevent the user from destroying a file by running an rm on it. Once a file is checked into a versioning system, even a cvs remove does not obliterate the file’s archived copy from the repository.

No Git

We have not adopted Git, the other popular version control system, because we felt that the primary USP of Git was in allowing disconnected commits. Since we are not facing any challenges in committing online to a central SVN repository, we are not facing any compulsion to support disconnected commits. Therefore, we are more comfortable with SVN and intend to use it in the foreseeable future, till circumstances change.