Popular Version control systems
Concurrent Versions System (CVS)
http://savannah.nongnu.org/projects/cvs
Sometimes referred to as the “grandfather” of version control applications, CVS (Concurrent Versions System) is an open source, cross-platform centralized version control system that began as a series of shell scripts written by Dick Grune in the mid-80′s. Though none of the original code from those scripts can be found in CVS as it is today, much of CVS’s conflict resolution algorithms came from them. What came to be CVS as we know it was a project by Brian Berliner in 1989 (with later collaboration with Jeff Polk and others). It was modified and improved upon for use by developers working on the SunOS kernel. In 1990, CVS 1.0 was released under GPL to the open source community. This was a big deal as, before CVS, a developer didn’t really have a true version control application. There were backups, of course, but CVS streamlined the process, with VCS standards such as the repository, trunk, and branching, and allowed for greater collaboration among developers.
The best thing about CVS is that it is tried and tested. I could easily compare it to a car made around the same time CVS was created. It’s solid, reliable (most of the time), and it gets the job done. On the other side of that analogy, however, CVS can also be incredibly clunky and, at times, difficult to work with. For example, it works with the notion that most of the work will be done within the trunk, with limited branching. Because of this, branching with CVS can be difficult compared to other version control applications, and slow development. CVS also doesn’t support any type of distributed version control. But perhaps the biggest complaint is that CVS does not support atomic commits, a common standard with newer version control applications. Though widely used for years, many developers have abandoned CVS for its more feature-rich, user-friendly cousin Subversion.
Subversion (SVN)
Designed as a successor to CVS, Subversion is an open-source, cross-platform centralized version control application originally created in 2000 by CollabNet with a desire for a stable version control system like CVS without many of the accompanying issues and a more robust set of features. Initially referred to as yet another CVS clone (YACC), Subversion began to break away as its own powerful version control application, becoming a top-level Apache project in 2010, with the current stable version 1.6.17 released June 2011 under the Apache License.
Developers familiar with CVS, will find many similarities with Subversion, making the transition relatively painless. The setup is easy and the commands are quite similar to CVS, in fact the same in many cases. The biggest difference between the two is atomic commits. This means that when a developer commits a changed version, either all changes succeed, or none. Branching and tagging within Subversion is notably more elegant and efficient than with CVS. Integration with Apache 2 is a handy feature, allowing WebDAV support (Web-based Distributed Authoring and Versioning), wherein a Subversion repository can be viewed within any web browser, and using WebDAV clients (such as Windows web folders), repositories can be mounted as a directory. Folder structure management is quite simple. Changing your file/folder hirerarchy in CVS can be frustrating. With SVN (aside from the prefix in the SVN command) it is like working with your local file system.
Of course, there are still some issues with Subversion. The most obvious is that, dependent upon your project’s specific needs, Subversion may appear bloated, the features and changes from CVS getting in the way of simplicity. Also, it would be nice if Subversion would show the history of a file across branches. It could also be argued that, though SVN is a much needed improvement over CVS, it is still quite firmly rooted within the centralized version control model of CVS. For those looking for a faster decentralized, or distributed version control system, there’s GIT.
GIT
Labeled “the fast version control system,” Git is an open source distributed version control system developed by Linus Torvalds for Linux kernel development when he became frustrated at the slow and inefficient nature of version control systems based around the CVS centralized VCS model. Inspired by BitKeeper and released under the GNU General Public License in 2005 , the most recent stable version, 1.7.64, was released September 23rd, 2011.
Before going further, I should explain the difference between centralized and decentralized/distributed version control systems. With 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 sync up to. With decentralized, or distributed version control systems, there is a peer-to-peer approach that developers can synchronize with by exchanging patches peer-to-peer. Developers can make changes in the repositories and those changes will be local to them (i.e.without being connected to a common network) unless they sync up with someone else. Depending on the project’s specific need, Git also offers a central repository.
Because developers can commit changes to local repositories while being offline, and a complete copy of the data is stored locally in the client’s system, Git is incredibly fast when compared to Subversion as there is no waiting for network response time. Also, as data copies are stored locally, there are fewer instances of data loss, whereas with a centralized model, such as Subversion, if there is data loss within the central repository, it’s gone. Git also supports atomic commits, and rapid branching and merging. The developer’s directory is, itself, a branch. One can see the directories of developers as the modify two or more unrelated files at the same time as different branches stemming from the same common base revision. Branching in Subversion, while better than CVS, is still arguably inefficient by comparison.
Large numbers of developers can commit to the same repository, with no need to worry about data loss or the immediate merging of others changes because commits are not sequential in Git like Subversion. Additionally, developers have control over the merging of data in synchronized repositories. The only real problem I found with Git is that it’s not quite as easy to get started with as CVS and Subversion, and can be a bit confounding to the first time user, but once you get the hang of it, Git is quite intuitive.
Conclusion
Code evolves. As a project advances, it goes through multiple cycles and this evolution doesn’t stop with the first stable release. Version control systems are an organizational necessity for any software development project. CVS, the “grandfather” of version control systems, was the first and has been in use for nearly three decades. Some developers swear by it, but others, familiar with CVS but needing something more, have turned to Subversion. Designed with the stability of CVS without many of its flaws, and with a more robust feature set, Subversion is an incredibly popular version control system. Yet for those looking for something different, there is Git. Gaining in popularity since its release because of its speed, efficiency, and flexibility, Git is rapidly becoming the standard for version control systems.
