On Version Control Systems

Using a Version Control System is a must for any software development right from the start (even if your boss denies it). Here are some of my reviews:

• Microsoft Visual SourceSafe is a so bad product that anybody will tell you to use at least the basic CVS.
  
• Serena Dimensions PVCS is outdated and dysfunctional. I have used it in some projects but it causes more problems than it tries to solve. The horrors of PVCS Version Manager is a good thread to get a fell of the problems. Among the problems I found when using it were excessive bureaucracy that slowed development too much (PVCS needs a full time administrator even for the most simple projects). PVCS needs training to use it as it is quite different from other VCS. PVCS being lock based slows down development a lot. And finally no good merge functionality. Most PVCS users are migrating to either Perforce, Subversion or Git.
• IBM Rational ClearCase has no atomic commits, is no distributed, the license is quite expensive and requires a qualified administrator.
  
• Perforce. I have not used perforce ever but the only one open source project I knew, Perl, was still using Perforce switched to Git.
• SourceGear Vault just does not get any better than subversion.
  
• CVS is not appropriate these days because it does not save changesets of all the changed files in the server (CVS saves changes on each file separately making it hard to know all the changes made on other files at the same time) and predates defaults that are not useful today (like not using unified diffs by default)
• Subversion is an improved CVS with current defaults and true changesets of a set of files, but make branching and merging quite hard and is not well suited for disconnected or distributed development.
• Git is steadily becoming the de facto standard VCS (used in projects like the Linux kernel, X.org, Samba and GNOME) that makes distributed and disconnected development much easier than subversion and is steadily taking subversion users. Git allows you doing things that other VCS just dream of, like git rebase --interactive. Why Git is Better Than X. Anyway, Git still has a difficult to use command line interface.
  
• Monotone is a DVCS inferior to git: MonotoneLimitations
• Mercurial is Git big contender. It is also used in many important projects. Mercurial was suggested for Linux kernel development but Git instead was created. Google has chosen Mercurial for Google Code instead of Git because Mercurial command set is more similar to Subversion, it is written in Python that is supported in Google infrastructure and has efficient HTTP based transport, but they recognize Git has more features.
  
• Quilt is a great simple tool to maintain a set of patches that can make your life much easier when you have a set of patches applied to upstream software that you want to keep updated for any new upstream version.

My favorites are Git and Quilt and I consider CVS totally obsolete and Subversion is becoming obsolete for most development use cases but maybe to keep upstream versioning.

This is a list of features I need in a VCS (I got most from Version Control System Comparison):

• See what is going to be commited (aka the full changeset) instead of just the modified, added, deleted files. With most VCSs I have to command diff and then command commit. This of course needs to allow aborting the commit operation. This feature is most useful to newbies that do not know that they always have to diff prior to commit to see if they see the changes they really want to commit or not.
  
• Atomic commits (aka Changesets) are a must. CVS and the crappy Visual Sourcesafe do not have atomic commits. Most modern VCSs have atomic commits.
• Files and Directories Moves or Renames. CVS does not have moves or renames but subversion and git do. Handling renames: svn vs. git vs. mercurial.
• Remote repository replication. To be able to browse the history while offline. CVS and Subversion have some external programs to be able to do that. But you need a modern VCS like git to be able to get the history and work with it natively.
• Propagating Changes to Parent Repositories and Disconnected operation. Be able to commit many changes without being online and be able to submit these changes upstream when I become online. CVS and subversion only support on-line operation so they are discarded.
• Tracking Line-wise File History. I want to know who and when changed some line. cvs annotate, svn blame, git blame, ...
• Networking support with HTTP and HTTPS to be able to access the repository behind a HTTP proxy. subversion and git can support it while CVS does not.
• Easy branching, merging and rebasing: When I need to code a new feature or fix a new bug I want to base my new code in the latest stable code, not in the work-in-progress feature that it is not finished yet, and be able to work on many features in paralell without any interference between them. Whenever these features are ready and tested I want to easily merge them to mainline. This means being able to change branches quickly is a must. Since mainline could have been changing I want to be able to rebase my changes to the latest mainline. CVS, Subversion and perforce make merging painful so they are discarded. git is great for this kind of operation.
• Easily revert a merged feature. I do not mind losing the history of the coding of the feature but it must be easy to revert them.
  
• I want to easily make changes to upstream projects that are constantly changing and rebase my changes easily whenever I want.
• Partial Pull: Be able to get just the last revision instead of the whole history of a project, just like CVS and subversion do. Monotone is not able to work just with the last revision and you have to get the huge whole history of the project.
• I want to see merge requests from my developers and with a click accept the merge request or reject it with a comment. So developers should be able to submit merge requests. I do not want to lose any merge request and multiple merge requests of the same branch should be merged (so email will not work here).
• Be able to completely remove a commit or file, committed by error or that may contain confidential information that should never be in the history. Subversion has problems with this use case (How to remove an accidentally put large file (4GB) from Subversion repository) but git lets you rebase the project history quite easily (Collapsing a git repository's history)
  

Martin Fowler has a good article on Version Control Tools