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:
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

No comments: