Comparison of revision control software
Web Design & Development Guide
Comparison of revision control software
Home Up
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.
General information
Software |
Maintainer |
Development status |
Repository model |
Concurrency model |
License |
Platforms supported |
Cost |
AccuRev
|
AccuRev, Inc. |
actively developed |
Client-server |
Merge or lock |
Proprietary |
Unix-like, Windows, Mac OS X |
Unspecified/Free 2-user 30 day trial licenses available |
Aldon
|
Aldon
[16] |
actively developed |
Client-server |
Merge or lock |
Proprietary |
Linux, Windows, OS/400 |
Unspecified |
Bazaar
|
Canonical Ltd. |
actively developed |
Distributed[1] |
Merge |
GPL |
Unix-like, Windows, Mac OS X |
Free |
ClearCase
|
IBM Rational
[17] |
actively developed |
Client-server and Distributed |
Merge or lock[2] |
Proprietary |
Unix-like, Windows, i5/OS, z/OS |
$4250 per concurrent user plus tax (includes 12 months support)
[18] |
Code Co-op
|
Reliable Software |
actively developed |
Distributed |
Merge |
Proprietary |
Windows |
$150 per seat |
Codeville
|
Ross Cohen |
actively developed |
Distributed |
Merge |
BSD |
Unix-like, Windows, Mac OS X |
Free |
CVS
|
The CVS Team
[19] |
maintained but new features not added |
Client-server |
Merge |
GPL |
Unix-like, Windows, Mac OS X |
Free |
CVSNT
|
March Hare Software
[20] 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, Windows, Mac OS X |
Free |
GNU
arch
|
Andy Tai |
maintained but new features not added |
Distributed |
Merge |
GPL |
Unix-like, Windows, Mac OS X |
Free |
LibreSource Synchronizer
|
Artenum
[21] |
maintained and new features under development |
Client-server |
Merge |
QPL |
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 or Lock |
Proprietary |
Unix-like, Windows, Mac OS X |
Free for up to 2 users, and for OSS development; else $800 per seat,
with volume discounts
[22] |
PlasticSCM
|
Codice Software[23] |
actively developed |
Client-server |
? |
Proprietary |
Unix-like, Windows, Mac OS X |
$621 per seat, with volume discounts
[24] |
SourceHaven
|
Veterisoft, Inc.
[25] |
actively supported |
Client-server |
? |
Proprietary |
Unix-like, Windows, Mac OS X |
$295 per seat with volume discounts |
StarTeam
|
Borland |
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 (SVN)
|
CollabNet, Inc.
[26] |
actively developed |
Client-server[3] |
Merge or lock[4] |
Apache/BSD
style |
Unix-like, Windows, Mac OS X |
Free (Commercial support/services available) |
Surround SCM
|
Seapine Software
[27] |
actively developed |
Client-server |
Merge or lock |
Proprietary |
Unix-like, Windows, Mac OS X |
Commercial |
SVK
|
Best Practical
[28] |
actively developed |
Distributed |
Merge |
Artistic/GPL |
Unix-like, Windows, Mac OS X |
Free |
Telelogic SYNERGY |
Telelogic AB |
actively supported |
Client-server |
Merge or Lock |
Proprietary |
Linux, Windows |
? |
Vault
|
SourceGear LLC
[29] |
actively supported |
Client-server |
Lock or Merge |
Proprietary |
Unix-like, Linux, Windows |
$249 per user |
Visual Source Safe
|
Microsoft |
serious bug fixes only |
Client-server |
Lock or merge |
Proprietary |
Windows |
Bundled with Visual Studio |
Team Foundation Server
|
Microsoft |
actively developed |
Client-server |
Lock or merge |
Proprietary |
Server:
Windows Server 2003; Clients: Windows and Web included; Java client (for Eclipse IDE, MacOS, Unix)
available |
Licensed through MSDN subscription or through direct buy
[30] |
-
^ 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.
-
^ SVK
allows Subversion to have distributed branches.
-
^ In Subversion, a file attribute enables the lock model on per-file
basis. This file attribute can be set automatically using file name wildcard
expressions.
- 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.
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[5] |
ClearCase |
? |
Snapshot |
Namespace |
O(patch) |
HTTP, custom (CCFS), custom (MVFS filesystem driver) |
Code Co-op |
C++ |
Changeset |
User ID-Ordinal |
O(patch) |
e-mail (MAPI, SMTP/POP3, Gmail), LAN |
CVS |
C |
Snapshot |
Namespace |
O(patch) |
pserver[31],
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(patch) |
custom, ssh, rsync, HTTP, FTP, email, bundles |
GNU
arch |
C, shell scripts |
Changeset |
Namespace |
O(patch) |
WebDAV, HTTP |
Mercurial |
Python, C |
Changeset |
SHA-1 hashes |
O(patch) |
HTTP, ssh, email (with plugin) |
Monotone |
C++ |
Hybrid[7] |
SHA-1 hashes |
O(patch) |
custom (netsync)[8] |
Perforce |
? |
Changeset |
Namespace |
O(patch) |
custom |
SourceHaven |
C, Java |
Snapshot |
Namespace |
O(patch) |
WebDAV,
custom |
StarTeam |
? |
Snapshot |
MD5
hashes |
O(revisions) |
custom |
Subversion |
C |
Snapshot |
Namespace |
O(patch) |
WebDAV,
custom (svnserve)[8] |
SVK |
Perl |
Changeset |
? |
? |
? |
Vault |
C# |
Snapshot |
? |
O(patch) |
HTTP, HTTPS |
Visual Source Safe |
C |
Snapshot |
Namespace? |
O(changes)? |
None, but can access repository files through a "share" |
Team Foundation Server |
C++ and C# |
Changeset |
Namespace |
O(patch) |
SOAP over HTTP or HTTPS |
LibreSource Synchronizer |
Java |
Changeset |
Timestamp of the repository |
O(patch) |
HTTP, File-System |
Plastic SCM |
C# |
Changeset |
Namespace |
O(revisions) |
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.
-
^ SVK
allows Subversion to have distributed branches.
-
^ In Subversion, a file attribute enables the lock model on per-file
basis. This file attribute can be set automatically using file name wildcard
expressions.
-
^ A Bazaar bundle is a summary diff, with sufficient extra
information to preserve history.
-
^
Mercurial 0.5b vs git. overview of performance/scalability.
-
^ 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.
Features
Software |
Atomic commit |
File renames |
Merge file renames |
Symbolic links |
Pre/post-event hooks |
Signed revisions |
Merge tracking |
End of line conversions |
Tags |
International Support |
AccuRev |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
? |
Aldon |
Yes |
Yes |
? |
Yes |
Yes |
Yes |
Yes |
? |
? |
? |
Bazaar |
Yes |
Yes |
Yes |
Yes |
Yes |
Partial[9] |
Yes |
No |
Yes[10] |
? |
ClearCase |
No |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
? |
Code Co-op |
Yes |
Yes |
Yes |
No |
limited support |
No |
No |
No |
Yes |
? |
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[11] |
? |
Yes |
? |
Git |
Yes |
Yes (implicit) |
Yes |
Yes |
Yes
[32] |
Yes
[33] |
Yes |
Yes |
Yes |
? |
GNU
arch |
Yes |
Yes |
? |
Yes |
Yes
[34] |
Yes |
? |
? |
Yes |
? |
Mercurial |
Yes |
Yes |
Yes |
Yes[12] |
Yes |
Yes |
Yes |
Yes |
Yes |
? |
Monotone |
Yes |
Yes |
Yes |
No[13] |
Yes
[35] |
Yes, mandatory |
Yes |
No |
Yes |
? |
Perforce |
Yes |
Yes[14] |
Yes |
Yes |
Yes |
Yes |
Yes
[36] |
Yes |
Yes |
No[15] |
SourceHaven |
Yes |
Yes |
? |
Yes |
Yes |
No |
? |
? |
? |
? |
StarTeam |
Yes[16] |
Yes |
? |
Yes |
No |
No |
Yes |
? |
Yes |
? |
Subversion |
Yes |
Yes[17] |
No |
Yes |
Yes |
No |
No[18]. |
Yes |
Partial[19] |
Yes |
SVK |
Yes |
Yes |
No |
Yes |
Yes[20] |
? |
Yes |
Yes |
Yes |
? |
Vault |
Yes |
Yes |
Yes |
No |
Yes |
No |
No |
Yes |
Yes |
? |
Visual Source Safe |
No |
Yes |
? |
Yes (using shares) |
Yes |
No |
No |
? |
Yes |
? |
Team Foundation Server |
Yes |
Yes |
Yes |
? |
Yes |
? |
Yes |
? |
Yes |
? |
LibreSource Synchronizer |
Yes |
Yes |
Yes |
No |
limited support
[21] |
No |
Yes
[22] |
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.
-
^ SVK
allows Subversion to have distributed branches.
-
^ In Subversion, a file attribute enables the lock model on per-file
basis. This file attribute can be set automatically using file name wildcard
expressions.
-
^ A Bazaar bundle is a summary diff, with sufficient extra
information to preserve history.
-
^
Mercurial 0.5b vs git. overview of performance/scalability.
-
^ 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
-
^ Mercurial versions 0.9.4 and higher support symlinks.
-
^ It could be done via user level hooks
-
^
http://www.perforce.com/perforce/technotes/note007.html
-
^ p4 supports unicode files. Files marked as unicode are converted
to and from the user's local codepage unless that codepage cannot represent
every character in the file. Therefore a unicode file with Japanese in it
can not be checked out by a user not running a Japanese OS. Set the file
type to text and p4 will not accept non ascii characters. Set the file to
binary and perforce will not be able to do auto-merge, a required feature
for source code. Therefore, p4 cannot be used for international software
development.[2]
-
^ 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-with-history-and-delete sequence.
-
^ A separate tool "svnmerge" provides merge tracking, see
[3]. Merge tracking will be included in Subversion itself in the next
major release, see
[4]
-
^ In Subversion, tags are a special case of the more generic "cheap
copy" concept of Subversion. Per convention, a tag is a copy into a
directory named "tags". Because of this, even tags are versioned. See
[5] for more information. The reason for partial support in the table is
because Subversion's emulation of tags in this manner does not meet the
requirement that the tag name can be used in place of any revision
identifier wherever the user may be required to enter one. This column would
be meaningless if the definition were to be loosened enough to encompass
Subversion's approach as every version control system supports branching and
would therefore support tags as well.
-
^ 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. 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.
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,
loggerhead or
Trac |
Olive, 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,
ViewVC, others |
Windows (incl. explorer integration), Mac OS X, GTK, Qt available |
CVSNT |
cvsweb,
ViewVC, others |
Windows, Mac OS X, OS/400, GTK, Qt available |
darcs |
darcs.cgi included;
darcsweb |
under development; Windows, Mac OS X (alpha) available |
Git |
gitweb, wit, cgit |
gitk, git-vgui (Tcl/Tk), tig, qgit. GTK, (h)gct (Qt) available |
GNU
arch |
ArchZoom |
ArchWay (GTK2), TlaLog |
Mercurial |
included
[23] |
Hgk (Tcl/Tk), (h)gct (Qt), Mercurial Eclipse |
Monotone |
ViewMTN |
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,
ViewSVN,
ViewVC,
Trac |
Qt, Windows (incl. explorer integration), Java, Mac OS X
[37], Eclipse, Netbeans, IDEA, Nautilus available |
SVK |
? |
? |
Vault |
included |
Windows, Unix-like, Mac OS X |
Visual Source Safe |
none included;
SSWI,
VSS Remoting |
Windows included; Linux, Mac OS and Solaris using
SourceOffSite; any Java VM using
SourceAnyWhere |
Team Foundation Server |
included (Team System Web Access) |
Windows included; Java client for Eclipse IDE, MacOS, Unix available |
LibreSource Synchronizer |
LibreSource |
Windows, Linux, Unix, Mac OS X available
[24] |
Plastic SCM |
Not necessary since entire project is replicated locally |
Windows, Linux, Unix, Mac OS X available |
-
^ 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.
-
^ SVK
allows Subversion to have distributed branches.
-
^ In Subversion, a file attribute enables the lock model on per-file
basis. This file attribute can be set automatically using file name wildcard
expressions.
-
^ A Bazaar bundle is a summary diff, with sufficient extra
information to preserve history.
-
^
Mercurial 0.5b vs git. overview of performance/scalability.
-
^ 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[6]
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
-
^ Mercurial versions 0.9.4 and higher support symlinks.
-
^ It could be done via user level hooks
-
^
http://www.perforce.com/perforce/technotes/note007.html
-
^ p4 supports unicode files. Files marked as unicode are converted
to and from the user's local codepage unless that codepage cannot represent
every character in the file. Therefore a unicode file with Japanese in it
can not be checked out by a user not running a Japanese OS. Set the file
type to text and p4 will not accept non ascii characters. Set the file to
binary and perforce will not be able to do auto-merge, a required feature
for source code. Therefore, p4 cannot be used for international software
development.[7]
-
^ 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-with-history-and-delete sequence.
-
^ A separate tool "svnmerge" provides merge tracking, see
[8]. Merge tracking will be included in Subversion itself in the next
major release, see
[9]
-
^ In Subversion, tags are a special case of the more generic "cheap
copy" concept of Subversion. Per convention, a tag is a copy into a
directory named "tags". Because of this, even tags are versioned. See
[10] for more information. The reason for partial support in the table
is because Subversion's emulation of tags in this manner does not meet the
requirement that the tag name can be used in place of any revision
identifier wherever the user may be required to enter one. This column would
be meaningless if the definition were to be loosened enough to encompass
Subversion's approach as every version control system supports branching and
would therefore support tags as well.
-
^ Uses subversion server
-
^ Its possible to embed the action in a shell or Ant script.
-
^ A merged is tracked by its workspace origin.
-
^ hgweb for single-repository access and hgwebdir for multiple
repository access from a single HTTP address
-
^ Any OS that support a Java Virtual Machine 1.5
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 |
Ubuntu, Launchpad, Drupal (but for main repository CVS still used),
KatchTV
[38] |
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
[39], 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, Projects Using Darcs |
Git |
Started by
Linus Torvalds in April 2005, following the BitKeeper controversy |
Linux kernel, Cairo, ELinks, Wine, X.Org, XCB, XMMS2
[40] |
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.[25]
First released on
April 19, 2005 |
e2fsprogs, Mozilla, Xine, Xen, OpenJDK, OpenSolaris, wmii, MoinMoin
[41] |
Monotone |
First released in
April 2003 |
coLinux, CTWM, OpenEmbedded, Pidgin, Xaraya
[42] |
Perforce |
Developed by Perforce
Software, Inc which was founded in 1995 by Christopher Seiwald. |
many organizations
worldwide
[43], Perl
5[44],
FreeBSD[45]
,
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 organizations worldwide
[46] |
SVK |
? |
? |
Vault |
? |
? |
Visual Source Safe |
? |
? |
Team Foundation Server |
First publicly
released on March, 2006 |
Available on
CodePlex, Microsoft itself and other large organizations worldwide |
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 organizations |
- 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.
-
^ SVK
allows Subversion to have distributed branches.
-
^ In Subversion, a file attribute enables the lock model on per-file
basis. This file attribute can be set automatically using file name wildcard
expressions.
-
^ A Bazaar bundle is a summary diff, with sufficient extra
information to preserve history.
-
^
Mercurial 0.5b vs git. overview of performance/scalability.
-
^ 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[11]
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
-
^ Mercurial versions 0.9.4 and higher support symlinks.
-
^ It could be done via user level hooks
-
^
http://www.perforce.com/perforce/technotes/note007.html
-
^ p4 supports unicode files. Files marked as unicode are converted
to and from the user's local codepage unless that codepage cannot represent
every character in the file. Therefore a unicode file with Japanese in it
can not be checked out by a user not running a Japanese OS. Set the file
type to text and p4 will not accept non ascii characters. Set the file to
binary and perforce will not be able to do auto-merge, a required feature
for source code. Therefore, p4 cannot be used for international software
development.[12]
-
^ 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-with-history-and-delete sequence.
-
^ A separate tool "svnmerge" provides merge tracking, see
[13]. Merge tracking will be included in Subversion itself in the next
major release, see
[14]
-
^ In Subversion, tags are a special case of the more generic "cheap
copy" concept of Subversion. Per convention, a tag is a copy into a
directory named "tags". Because of this, even tags are versioned. See
[15] for more information. The reason for partial support in the table
is because Subversion's emulation of tags in this manner does not meet the
requirement that the tag name can be used in place of any revision
identifier wherever the user may be required to enter one. This column would
be meaningless if the definition were to be loosened enough to encompass
Subversion's approach as every version control system supports branching and
would therefore support tags as well.
-
^ Uses subversion server
-
^ Its possible to embed the action in a shell or Ant script.
-
^ A merged is tracked by its workspace origin.
-
^ hgweb for single-repository access and hgwebdir for multiple
repository access from a single HTTP address
-
^ 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
See also
External links
Home Up List of revision control software Comparison of revision control software
|