Version Control Systems Comparison

By David Poarch Subversion (SVN) http://subversion.tigris.org/ SVN is a free/open-source and popular source control system with perhaps the widest adoption. Though it is cross-platform compatible, with native Windows server and clients available (TortoiseSVN being the popular SVN client choice for Windows), SVN does not work with SQL server as a backend and it does not integrate with Visual Studio out of the box. Though SVN cannot be readily integrated with Visual Studio, integration is possible via certain plug-ins—a popular solution being VisualSVN, which integrates TortoiseSVN into Visual Studio. SVN only offers two types of repository storage – FSFS (Fast Secure File System) and Berkeley DB. Of the two, FSFS works faster on directories with a large number of files and takes less disk space, due to less logging, while SVN has some limitations with Berkeley DB usage leading to repository corruption and data loss when a program accessing the database crashes or was terminated forcibly. The SVN file system is often referred to being three-dimensional, with a standard file directory tree and file revision making up the third dimension. Since files are stored as links to the most recent change, an SVN repository is quite compact, with the storage space used being proportional to the number of changes made. Moreover, the SVN file system utilizes “transactions” to keep changes atomic. Thus, a transaction is either committed and becomes the latest revision, or it is aborted. In an atomic database transaction, a series of database operations either all occur or nothing occurs, thereby preventing partial alterations to the database. In SVN, transactions can be exited and re-opened/continued, and multiple clients can access the same transaction and work together on an atomic change. An important feature of the SVN file system is properties, or simple name=value pairs of text, which can be added to file system entries and revisions in order to include additional information and unlock specific capabilities/features. SVN uses an efficient interfile branchingmodel and differencing algorithm derived from Perforce in which old and new copied versions are linked together internally and the history is preserved for both. This way, the copied versions take up minimal space in the repository since only the differences from the original versions are saved. Currently, SVN only allows directory access control. Thus, this can pose as a problem in instances where directories are not structured to address functional encapsulation. A known problem in SVN is the implementation of the file and directory renameoperation. Similar to UNIX-style operations, SVN implements the renaming of files and directories as a “copy” to the new name followed by a “delete” of the old name. However, since only the names are changed and all edit history remains unchanged, the old name is still used in older revisions of the tree, resulting in mis-modification. Though SVN is relatively easy to use, it does lack some repository administration and management features. Though workarounds do exist, they are often not simple. Also, SVN does store additional copies of data on the local machine, which can be an issue for very large projects or files, or if developers are working on multiple branches simultaneously. These client-side .svn directories can become corrupted by ill-advised user activity.

SVN is extensively documented in the free online book, Version Control with Subversion (http://svnbook.red-bean.com/ ).

Microsoft Visual SourceSafe (VSS) VSS is a source control system oriented towards small software development projects. For multiuser environments, it lacks many important features found in other source code management products, such as support for atomic commits of multiple files. According to Microsoft, VSS is geared towards individual developers or small teams with lightweight source code management needs, as for small or medium scale development, where multiple versions are not simultaneously supported. VSS is relatively easy to use and is readily synthesizable with Microsoft Visual Studio. Ironically though, VSS integration with Visual Studio can result in Visual Studio crashing when VSS hangs from a loss in system connection. It has the capability of handling any file type in its database, though prior versions have been shown to be unstable when handling large amounts of nontextual data, such as images, binary executables, etc. VSS relies on a file-based storage mechanism, meaning that code and records of changes and check-outs are not stored in a database. Also, VSS lacks sophisticated branching and merging support, which hinders code encapsulation and makes it easy to check non-functioning code into the revision control system. Moreover, managing third party modules can be cumbersome using VSS. The optimal environment for VSS is that in which a small team of developers is accessing repository content via a LAN, since, by design, it utilizes a file-based access mechanism allowing any client to modify a file in the repository after locking it, which sometimes can leave the file in a corrupted state. Microsoft assures that these performance and stability issues are resolved in VSS 2005 and newer releases; however, the company recommends its new flagship source control and project lifecycle management product Team Foundation Server, which promises greater stability and control over activities.

Microsoft Team Foundation Server (TFS) http://msdn.microsoft.com/en-us/teamsystem/default.aspx Perhaps in a partial attempt to address the shortcomings of VSS, Microsoft produced Team Foundation Server (TFS), which is actually a software package that offers source control, data collection, reporting, and project tracking capabilities, and is intended for collaborative software development projects. TFS has a solid level of integration with all its included components, and though powerful, some of the sophistication can be initially confusing. As part of the TFS package, reporting forms a major component, with which a variety of reports can be created, such as rate of code change over time, lists of bugs that do not have test cases, regressions on previously passing tests, etc. TFS’ logging infrastructure monitors and logs information regarding access and use of the work items and source code, which can then be used by the analysis services to find trends.

TFS also creates a SharePoint site for each project, which can be used to track the progress of the project as well as to explore the work items and source controlled documents in the project. This portal is complete with a document library, reports viewing feature, and user communication medium. TFS also includes a build server that can be installed on almost any machine that can support Visual Studio. Machines configured with Team Build can be used by developers to do a complete build of the most recent versions of the software contained in source control. Records of every build, whether it succeeds or fails, are kept so that developers and build administrators can keep track of the progress of the project. TFS’ source control system is known as Team Foundation Version Control (TFVC). Unlike Microsoft's previous source control offering, Visual SourceSafe (VSS), which relied on a file-based storage mechanism, Team Foundation source control stores all code, as well as a record of all changes and current check-outs in an SQL Server database. It supports features such as multiple simultaneous check-outs, conflict resolution, shelving and unshelving (shelving is a way to save a set of pending changes without committing them to source control, while still making them available to other users), branching and merging, multiple file type handling, and the ability to set security levels on any level of a source tree, alongside the most visible features of document versioning, locking, rollback, and atomic commits. With TFVC, branching is relatively easy to perform and is not too dissimilar to the process taken by Subversion where a copy of one part of the tree is placed in another path. Though merging is a bit more difficult, TFVC comes with a merge wizard that assists with the process, though with some limitation. TFVC supports branching at entire source code level as well as individual files and directory levels as well, with each branch being maintained individually. Multiple branches can be merged together, with the built in conflict resolution algorithm merging the changes between two branches of the same file where it can automatically reconcile the differences or flagging them for manual inspection if it cannot. Merge can be performed at "changeset" level as well, instead of the branch level. A successful merge is automatically checked out in the source control repository.

Mercurial http://www.selenic.com/mercurial/wiki/ Mercurial is one of a new type of repository system known as a distributed version control system (DVCS) that has recently taken the web development community by storm. With a distributed version control system, there isn’t one centralized code base to pull the code from. Different branches hold different parts of the code. Other version control systems, such as SVN and CVS, use centralized version control, meaning that only one master copy of the software is used. However, though a DVCS, Mercurial and other DVCS’s can be adapted to operate utilizing a centralized workflow. A DVCS, or Distributed Version Control System, is a way to manage versions of files that doesn't require a centralized server, but can also make use of a centralized server. Changes can be merged to any other user of the DVCS, and as such it allows for a very flexible workflow. The two main advantages of DVCS are that it is more flexible than centralized version control, as it allows a traditional (centralized) workflow in addition to more esoteric workflows, and it very fast. It is so much quicker than centralized servers because most operations take place locally on the client, instead of requiring a network operation.

There are three core differences between DVCS over centralized version control systems. The first is offline work with local commits, which is integral to how DVCS operates. This is fundamentally different than centralized version control, which requires that all operations occur through a connection to a centralized server. This flexibility allows developers to work on an airplane, and make commit after commit, just as easily as if they were working in the office. The second difference is that DVCS are more flexible than centralized systems, as they allow many different types of workflows, from a classic centralized workflow, to a purely ad hoc, to a mixture of ad hoc and centralized. This flexibility allows development to take place through email, peer-to-peer, and any manner that a development team could think up. The third difference is that DVCS are much quicker than centralized version control systems because most operations occur on the client and are fairly instantaneous. In addition, when a push (communication to another node) is required, it is also quicker because both clients have the full metadata on their machines. This speed difference is quite substantial, and can differ, roughly, between 3-10 times quicker for a DVCS than Subversion, depending on whether the repository is a local repository or a network repository. Because DVCS's are so flexible, there are a vast number of potential workflows, but for the sake of space, this article only talks about two. First, one of the most common workflows is a Partner workflow. With a Partner workflow, a developer starts a project, then makes a branch. They then merge changes back and forth between branches that another developer is working on, and merge those changes in each time. A second common workflow is to use a centralized server with local commits. In the workflow, a developer works much like they would with a centralized subversion repository, except they commit locally, and then push a final change to the centralized server. There are many variations to this, including intermixing the Partner workflow with this workflow. The main thing to take away is that there are many ways to work, and with DVCS, you have the flexibility to choose which way works best for you. Mercurial has a large user base and a comprehensive guide book: http://www.selenic.com/mercurial/wiki/MercurialBook

Perforce http://www.perforce.com/ Perforce is another popular source control management system, with (as of December 2007) it being licensed to more than 250,000 users at 4,500 organizations, including Microsoft (interestingly). Like TFS, Perforce is not free. Perforce has virtually all the capabilities of a modern source control management system and more. In fact, for being a centralized version control system, it has the unique ability to achieve distributed version control. Perforce also supports sparse branching and indirect integration. Sparse branching is a popular branching practice wherein only subsets of files are branched, instead of branching all files from one branch to another (and subsequently merging them back). This approach can be beneficial when working with branches that consist of hundreds or thousands of files, but that require only a few files to be edited at a time. Indirect integration comes into play when you want to merge changes between two branches that are not directly related. Perforce integrates with a large variety of application lifecycle management tools, including Visual Studio. File access is controlled by one or more superusers. A range of file access permission levels can be granted. Permissions can be set for repository file paths, users, groups, and IP address

subnets. The server can maintain an audit log of file access events for SOX and other compliance requirements. Security is controlled by the Perforce system administrator. Password strength is configurable; ticket-based authentication can be configured as well. Triggers (custom scripts or programs that run at predefined events) can be set on many but not all Perforce user commands and used to extend user authentication (with LDAP or SSO, for example), to block or allow user commands, and to constrain or normalize file modifications. Triggers are run by the Perforce server and do not have access to client machines or workspaces. In terms of performance versus Team Foundation Server, see the chart below (values are in seconds unless otherwise specified):

Perforce vs. TFS

On the following page is a comparison of basic features of all five version control systems:

Basic Features Comparison

Atomic commits: refers to a guarantee that all changes made are merged, or that no change at all will be made. File renames: describes whether a system allows files to be renamed while retaining their version history. Merge file renames: describes whether a system can merge changes made to a file on one branch into the same file that has been renamed on another branch (or vice versa). If the same file has been renamed on both branches then there is a rename conflict that the user must resolve. Symbolic links: describes whether a system allows revision control of symbolic links as with regular files. Versioning symbolic links is considered by some people a feature and some people a security breach (e.g., a symbolic link to /etc/passwd). Symbolic links are only supported on select platforms, depending on the software. Pre/post event hooks: indicates the capability to trigger commands before or after an action, such as a commit, takes place. Signed revisions: refers to integrated digital signing of revisions, in a format such as OpenPGP. Merge tracking: describes whether a system remembers what changes have been merged between which branches and only merges the changes that are missing when merging one branch into another. End of line conversions: describes whether a system can adapt the end of line characters for text files such that they match the end of line style for the operating system under which it is used. The granularity of control varies. Subversion, for example, can be configured to handle EOLs differently according to the file type, whereas Perforce converts all text files according a single, per-client setting. Tags: indicates if meaningful names can be given to specific revisions. International Support: Indicates if the software has support for multiple language environments and operating system