Comparison of revision control software
From Wikipedia, the free encyclopedia
The following tables compare general and technical information for notable revision control and software configuration management (SCM) software. This article is not all-inclusive and may become out of date quickly.
Contents |
[edit] General information
Software | Maintainer | Development status | Repository model | Concurrency model | License | Platforms supported | Cost |
---|---|---|---|---|---|---|---|
AccuRev | AccuRev, Inc.[5] | actively developed | Client-server | Merge or lock | Proprietary | Unix-like, Windows, Mac OS X | Unspecified |
Aldon | Aldon [6] | actively developed | Client-server | Merge or lock | Proprietary | Linux, Windows, iSeries | Unspecified |
Bazaar | Canonical Ltd [7] | actively developed | Distributed[1] | Merge | GPL | Unix-like, Windows, Mac OS X | Free |
ClearCase | IBM Rational [8] | actively developed | Client-server | Merge or lock[2] | Proprietary | Unix-like, Windows | $4250 per seat plus tax (includes 12 months support) [9] |
Code Co-op | Reliable Software | actively developed | Distributed | Merge | Proprietary | Windows | $250 per seat |
Codeville | Ross Cohen | actively developed | Distributed | Merge | BSD | Unix-like, Windows, Mac OS X | Free |
CVS | The CVS Team [10] | maintained but new features not added | Client-server | Merge | GPL | Unix-like, Windows, Mac OS X | Free |
CVSNT | March Hare Software [11] and community members. | maintained and new features under development | Client-server | Merge | GPL or proprietary | Unix-like, Windows, Mac OS X, OS/400 | Free or commercial |
darcs | David Roundy | actively developed | Distributed | Merge | GPL | Unix-like, Windows, Mac OS X | Free |
Git | Junio C Hamano | actively developed | Distributed | Merge | GPL | POSIX | Free |
GNU arch | Andy Tai | maintained but new features not added | Distributed | Merge | GPL | Unix-like, Windows, Mac OS X | Free |
Mercurial | Matt Mackall | actively developed | Distributed | Merge | GPL | Unix-like, Windows, Mac OS X | Free |
Monotone | Nathaniel Smith, Graydon Hoare | actively developed | Distributed | Merge | GPL | Unix-like, Windows, Mac OS X | Free |
Perforce | Perforce Software Inc. | actively supported | Client-server | Merge[3] | Proprietary | Unix-like, Windows, Mac OS X | Free for up to 2 users, and for OSS development; else $800 per seat, with volume discounts [12] |
SourceHaven | Veterisoft, Inc. [13] | actively supported | Client-server | ? | Proprietary | Unix-like, Windows, Mac OS X | $295 per seat with volume discounts |
StarTeam | Borland [14] | actively developed | Client-server | Merge or lock | Proprietary | Windows and Crossplattform via Java based client | Included with BDS2006 Enterprise and up, otherwise Contact Borland |
Subversion | CollabNet, Inc. [15] | actively developed | Client-server[4] | Merge[5] | Apache/BSD style | Unix-like, Windows, Mac OS X | Free |
SVK | Best Practical [16] | actively developed | Distributed | Merge | Artistic/GPL | Unix-like, Windows, Mac OS X | Free |
Team Coherence | QSC | ? | ? | ? | ? | ? | ? |
Telelogic_SYNERGY | Telelogic AB [17] | actively supported | Client-server | Merge or Lock | Proprietary | Linux, Windows | ? |
Vault | SourceGear LLC [18] | actively supported | Client-server | ? | Proprietary | Linux, Windows | $289 per login |
Visual Source Safe | Microsoft [19] | actively developed | Client-server | Lock or merge | Proprietary | Windows | Bundled with Visual Studio |
Team Foundation Server | Microsoft [20] | actively supported | Client-server | Lock or merge | Proprietary | Windows | Licenced through MSDN subscription or through direct buy [21] |
LibreSource Synchronizer | Artenum [22] | maintained and new features under development | Client-server | Merge | QPL | Unix-like, Windows, Mac OS X | Free |
PlasticSCM | Codice Software[23] | actively developed | Client-server | ? | Proprietary | Unix-like, Windows, Mac OS X | $621 per seat, with volume discounts [24] |
- ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
- ^ In ClearCase, a trigger may be set to allow for the lock model, and this is done at many sites. However, ClearCase development usually takes place on private branches where each developer is given their own branch, so the lock vs. merge concurrency model doesn't matter as much. Code is merged back to the main branch once the developer is ready to deliver their code to the project.
- ^ In Perforce, file attributes may be set to allow for the lock model. However, this is discouraged by the Perforce. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- ^ SVK allows Subversion to have distributed branches.
- ^ In Subversion, file attributes may be set to allow for the lock model. However, this is discouraged by the Subversion development team. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- Repository model describes the relationship between various copies of the source code repository. In a client-server model, users access a master repository via a client; typically, their local machines hold only a working copy of a project tree. Changes in one working copy must be committed to the master repository before they are propagated to other users. In a distributed model, repositories act as peers, and users typically have a local repository with version history available, in addition to their working copies.
- Concurrency model describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository. In a lock model, changes are disallowed until the user requests and receives an exclusive lock on the file from the master repository. In a merge model, users may freely edit files, but are informed of possible conflicts upon checking their changes into the repository, whereupon the version control system may merge changes on both sides, or let the user decide when conflicts arise. Note that distributed version control almost always implies a merge concurrency model.
[edit] Technical information
Software | Programming language | History model | Revision IDs | Repo. size | Network protocols |
---|---|---|---|---|---|
AccuRev | Java | Changeset | Namespace | O(revisions) | custom |
Aldon | C++, Java | Snapshot | Namespace | O(revisions) | custom |
Bazaar | Python | Snapshot | Pseudorandom | O(patch) | HTTP, SFTP, FTP, ssh, custom, email bundles[6] |
ClearCase | ? | Snapshot | Namespace | O(patch) | custom (uses custom MVFS filesystem driver) |
Code Co-op | C++ | Changeset | User ID-Ordinal | O(patch) | email (MAPI), copies over LAN |
CVS | C | Snapshot | Namespace | O(patch) | pserver[25], ssh |
CVSNT | C++ | Changeset | Namespace | O(patch) | sspi, sserver, gserver, pserver, ssh |
darcs | Haskell | Patch | Namespace | O(patch) | HTTP, ssh, email |
Git | C, shell scripts | Snapshot | SHA-1 hashes | O(changed files) | custom, ssh, rsync, HTTP, FTP |
GNU arch | C, shell scripts | Changeset | Namespace | O(patch) | WebDAV, HTTP |
Mercurial | Python | Changeset | SHA-1 hashes | O(patch)[7] | HTTP, ssh, email (with plugin) |
Monotone | C++ | Hybrid[8] | SHA-1 hashes | O(patch) ? | custom (netsync)[9] |
Perforce | ? | Changeset | Namespace | O(patch) | custom |
SourceHaven | C, Java | Snapshot | Namespace | O(patch) | WebDAV, custom |
StarTeam | ? | Snapshot | MD5 hashes | O(revision) | custom |
Subversion | C | Snapshot | Namespace | O(patch) | WebDAV, custom (svnserve)[9] |
SVK | Perl | Changeset | ? | ? | ? |
Team Coherence | ? | ? | ? | ? | ? |
Vault | ? | Snapshot | ? | ? | ? |
Visual Source Safe | C | Snapshot | Namespace? | O(changes)? | None, but can access repository files through a "share" |
Team Foundation Server | C++ | ? | ? | ? | ? |
LibreSource Synchronizer | Java | Changeset | Timestamp of the repository | O(patch) | HTTP, File-System |
Plastic SCM | .NET | Changeset | Namespace | O(revision) | custom |
- ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
- ^ In ClearCase, a trigger may be set to allow for the lock model, and this is done at many sites. However, ClearCase development usually takes place on private branches where each developer is given their own branch, so the lock vs. merge concurrency model doesn't matter as much. Code is merged back to the main branch once the developer is ready to deliver their code to the project.
- ^ In Perforce, file attributes may be set to allow for the lock model. However, this is discouraged by the Perforce. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- ^ SVK allows Subversion to have distributed branches.
- ^ In Subversion, file attributes may be set to allow for the lock model. However, this is discouraged by the Subversion development team. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- ^ A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
- ^ Mercurial 0.5b vs git. overview of performance/scalability. Retrieved on December 5, 2006.
- ^ A Monotone's revisions represent changesets and its manifests represent snapshots, each revision is linked to some manifest. But manifests are legacy constructs, they aren't kept in the database anymore and reconstructed on the fly if needed. The real work now happen in rosters which are hybrid snapshot/changeset structures.
- ^ a b ssh tunneling is optional
- History model describes the form in which changes are stored in the repository. For example, when a change is committed, a system could store a copy of the tree before and after the change (snapshot), or it might instead store a copy of the tree before the change and a changeset representing the changes.
- Revision IDs are used internally to identify specific versions of files in the repository. Systems may use pseudorandom identifiers, content hashes of revisions, or filenames with sequential version numbers (namespace).
- Repo. size describes how the repository grows as changes are committed. O(patch) means that it grows as the size of the patches between revisions, while O(revisions) means that it grows as the size of each revision checked in.
- Network protocols lists the protocols used for synchronization of changes.
[edit] Features
Software | Atomic commits | File renames | Merge file renames | Symbolic links | Pre/post-event hooks | Signed revisions | Merge tracking | End of line conversions | Tags |
---|---|---|---|---|---|---|---|---|---|
AccuRev | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Aldon | Yes | Yes | ? | Yes | Yes | Yes | Yes | ? | ? |
Bazaar | Yes | Yes | Yes | Yes | Yes | Partial[10] | Yes | No | Yes[11] |
ClearCase | No | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Code Co-op | Yes | Yes | ? | No | limited support | No | ? | ? | ? |
CVS | No | No | No | No | limited support | No | No | Yes | Yes |
CVSNT | Yes | Yes | ? | No | Yes | No | Yes | Yes | Yes |
darcs | Yes | Yes | Yes | No | Yes | Yes | N/A[12] | ? | Yes |
Git | Yes | Yes (implicit) | Yes | Yes | Yes [26] | Yes [27] | Yes | No | Yes |
GNU arch | Yes | Yes | ? | Yes | Yes [28] | Yes | ? | ? | Yes |
Mercurial | Yes | Yes | Yes | No | Yes (written in Python) | Yes | Yes | Yes | Yes |
Monotone | Yes | Yes | Yes | No[13] | Yes [29] | Yes, mandatory | Yes | No | Yes |
Perforce | Yes | Partial | ? | Yes | Yes | Yes | Yes [30] | Yes | Yes |
SourceHaven | Yes | Yes | ? | Yes | Yes | No | ? | ? | ? |
StarTeam | Yes[14] | Yes | ? | Yes | No | No | Yes | ? | Yes |
Subversion | Yes | Yes[15] | No | Yes | Yes | No | No | Yes | limited support[16] |
SVK | Yes | Yes | No | Yes | Yes[17] | ? | Yes | Yes | limited support |
Vault | Yes | Yes | ? | ? | Yes | ? | ? | ? | ? |
Visual Source Safe | No | Yes | ? | No | Yes | No | No | ? | ? |
Team Foundation Server | Yes | Yes | ? | ? | Yes | ? | ? | ? | ? |
LibreSource Synchronizer | Yes | Yes | Yes | No | limited support [18] | No | Yes [19] | No | Yes |
Plastic SCM | Yes | Yes | Yes | Yes | Yes | Yes | Yes | ? | Yes |
- ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
- ^ In ClearCase, a trigger may be set to allow for the lock model, and this is done at many sites. However, ClearCase development usually takes place on private branches where each developer is given their own branch, so the lock vs. merge concurrency model doesn't matter as much. Code is merged back to the main branch once the developer is ready to deliver their code to the project.
- ^ In Perforce, file attributes may be set to allow for the lock model. However, this is discouraged by the Perforce. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- ^ SVK allows Subversion to have distributed branches.
- ^ In Subversion, file attributes may be set to allow for the lock model. However, this is discouraged by the Subversion development team. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- ^ A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
- ^ Mercurial 0.5b vs git. overview of performance/scalability. Retrieved on December 5, 2006.
- ^ A Monotone's revisions represent changesets and its manifests represent snapshots, each revision is linked to some manifest. But manifests are legacy constructs, they aren't kept in the database anymore and reconstructed on the fly if needed. The real work now happen in rosters which are hybrid snapshot/changeset structures.
- ^ a b ssh tunneling is optional
- ^ They can be automatically generated[1] and manually verified, but verification is not automatic
- ^ Tags were introduced into Bazaar in version 0.15. Previous versions needed to use a plug in.
- ^ darcs' patches each bear a unique identifier, it's pretty much impossible to merge twice the same patch in a repository
- ^ It could be done via user level hooks
- ^ StarTeam supports atomic commits as of version 2006
- ^ Subversion can move a file and conserve its history, if and only if the target of the move is in the same Subversion repository as the source. Cross-repository moves require third-party tools such as svk. Also, a rename operation is actually a copy-delete sequence.
- ^ In subversion, a tag can be emulated by copying a directory into another directory (by convention called "tags") in the repository and never committing changes to that directory. By this standard, any VCS that supports multiple branches in one repository supports tags. See [2] for more information.
- ^ Uses subversion server
- ^ Its possible to embed the action in a shell or Ant script.
- ^ A merged is tracked by its workspace origin.
- Atomic commits refers to a guarantee that all commits are merged fully, or not at all.
- 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 (eg 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.
- Tags indicates if meaningful names can be given to specific revisions.
[edit] User interfaces
Software | Web interfaces | GUIs |
---|---|---|
AccuRev | Yes | Windows, Linux, Unix, Mac OS X, BeOS available |
Aldon | Yes | Windows |
Bazaar | can use a plain webserver, webserve, or loggerhead | bzr-gtk (GTK+), qbzr (Qt) |
ClearCase | included, Clearcase Web Interface | Windows, interface for Unix-like systems is mixed command-line and GUI |
Code Co-op | Not necessary since entire project is replicated locally | Windows |
CVS | cvsweb [31], ViewVC, others | Windows, Mac OS X, GTK, Qt available |
CVSNT | cvsweb [32], ViewVC, others | Windows, Mac OS X, OS/400, GTK, Qt available |
darcs | darcs.cgi included; darcsweb [33] | under development; Windows, Mac OS X (alpha) available |
Git | gitweb, wit | gitk, git-gui (Tcl/Tk). GTK, (h)gct (Qt) available |
GNU arch | ArchZoom [34] | ArchWay (GTK2) [35], TlaLog [36] |
Mercurial | included | Hgk (Tcl/Tk), (h)gct (Qt) |
Monotone | ViewMTN [37] | GTK+, Qt available |
Perforce | included, P4Web, P4FTP | Windows, Linux, Unix, Mac OS X, BeOS available |
SourceHaven | included | Windows, Linux, Unix, Mac OS X, BeOS available |
StarTeam | included | Windows, Java, BDS2006 integration |
Subversion | Apache 2 module included, WebSVN [38], ViewSVN [39], ViewVC, Trac | Qt, Windows, Java, Mac OS X [40] available |
SVK | ? | ? |
Vault | ? | Windows, Linux |
Visual Source Safe | None | Windows |
Team Foundation Server | ? | ? |
LibreSource Synchronizer | Yes LibreSource | Windows, Linux, Unix, Mac OS X available [20] |
Plastic SCM | Not necessary since entire project is replicated locally | Windows, Linux, Unix, Mac OS X available |
[edit] History and adoption
Software | History | Notable users |
---|---|---|
AccuRev | First publicly released on May 18th, 1999 | Clients include: SanDisk, Sony, Orbitz, MCI, and Polycom |
Aldon | Founded in 1979 to provide software configuration and change management solutions to IT | Clients include: Nintendo, AIG, Kraft Foods, Banner Health, EON Bank, and Masterbrand Cabinets |
Bazaar | Loosely related to baz | Launchpad, Drupal (but for main repository CVS still used), KatchTV [41] |
ClearCase | Developed beginning in 1990 by Atria Software, following concepts developed by Apollo Computer in DSEE during the 1980s | IBM, Motorola, Siemens, Ericsson, Nokia and other large organizations worldwide |
Code Co-op | The first distributed VCS, demoed in 1997 [42], released soon after. | Clients include: Logitech, HP, Ericsson |
CVS | First publicly released July 3, 1986; based on RCS | thousands of organizations worldwide |
CVSNT | First publicly released 1998; based on CVS. Started by CVS developers with the goal adding support for a wider range of development methods and processes. | too many to list. |
darcs | First announced on April 9, 2003 | DokuWiki, Mnet, Psi [43] |
Git | Started by Linus Torvalds in April 2005, following the BitKeeper controversy | Linux kernel, Cairo, ELinks, Wine, X.Org, XCB, XMMS2 [44] |
GNU arch | Started by Tom Lord, it later became part of the GNU project. Lord resigned as maintainer in August 2005. | available for GNU Savannah and Gna.org projects |
Mercurial | Started April 6, 2005 by Matt Mackall, following the BitKeeper controversy.[21] First released on April 19, 2005 | e2fsprogs, Xen, OpenSolaris, wmii, MoinMoin [45] |
Monotone | First released in April 2003 | coLinux, CTWM, OpenEmbedded, Xaraya [46] |
Perforce | Developed by Perforce Software, Inc which was founded in 1995 by Christopher Seiwald. | many organisations worldwide [47], Perl 5[48] Trolltech |
StarTeam | Developed by StarBase software, acquired by Borland. | Borland, BT Group, Cintax corporation |
Subversion | Started by CVS developers with goal of replacing CVS | ASF, SourceForge, KDE, GNOME, GCC, Ruby, Ruby on Rails, Python, Samba, Mono, PuTTY, Zope, Xiph, GnuPG, CUPS, Wireshark, TWiki, and many organisations worldwide [49] |
SVK | ? | ? |
Vault | ? | ? |
Visual Source Safe | ? | ? |
Team Foundation Server | ? | Available on CodePlex |
LibreSource Synchronizer | First publicly released on June 13th, 2005 | Most of the LibreSource Community |
Plastic SCM | Developed by Codice Software, Inc which was founded in 2005 by Pablo Santos and David Suarez | many organisations |
- Notable users is a list of well known projects using the software as their primary revision control system, excluding the software itself, followed by a link to a full list if available.
- History briefly describes the software's origins and development.
- ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
- ^ In ClearCase, a trigger may be set to allow for the lock model, and this is done at many sites. However, ClearCase development usually takes place on private branches where each developer is given their own branch, so the lock vs. merge concurrency model doesn't matter as much. Code is merged back to the main branch once the developer is ready to deliver their code to the project.
- ^ In Perforce, file attributes may be set to allow for the lock model. However, this is discouraged by the Perforce. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- ^ SVK allows Subversion to have distributed branches.
- ^ In Subversion, file attributes may be set to allow for the lock model. However, this is discouraged by the Subversion development team. File locking should only be used on non-text based files (such as icons) that cannot be merged on check in.
- ^ A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
- ^ Mercurial 0.5b vs git. overview of performance/scalability. Retrieved on December 5, 2006.
- ^ A Monotone's revisions represent changesets and its manifests represent snapshots, each revision is linked to some manifest. But manifests are legacy constructs, they aren't kept in the database anymore and reconstructed on the fly if needed. The real work now happen in rosters which are hybrid snapshot/changeset structures.
- ^ a b ssh tunneling is optional
- ^ They can be automatically generated[3] and manually verified, but verification is not automatic
- ^ Tags were introduced into Bazaar in version 0.15. Previous versions needed to use a plug in.
- ^ darcs' patches each bear a unique identifier, it's pretty much impossible to merge twice the same patch in a repository
- ^ It could be done via user level hooks
- ^ StarTeam supports atomic commits as of version 2006
- ^ Subversion can move a file and conserve its history, if and only if the target of the move is in the same Subversion repository as the source. Cross-repository moves require third-party tools such as svk. Also, a rename operation is actually a copy-delete sequence.
- ^ In subversion, a tag can be emulated by copying a directory into another directory (by convention called "tags") in the repository and never committing changes to that directory. By this standard, any VCS that supports multiple branches in one repository supports tags. See [4] for more information.
- ^ Uses subversion server
- ^ Its possible to embed the action in a shell or Ant script.
- ^ A merged is tracked by its workspace origin.
- ^ Any OS that support a Java Virtual Machine 1.5
- ^ Towards A Better SCM: Revlogs and Mercurial, presented by Matt Mackall to the Ottawa Linux Symposium, July 2006
[edit] See also
[edit] External links
- Comments on Open Source Software / Free Software SCM systems by David A. Wheeler
- Quick Reference Guide to Free Software Decentralized Revision Control Systems by Zooko
- Comparison of commercial Version Control Systems, from the creators of Code Co-op
- Version Control System Comparison from better-scm.berlios.de
- Evaluation of distributed source code management solutions for OpenSolaris by Sun
- Analysis of alternatives to CVS for Freedesktop.org by Keith Packard