WWW.WEBMASTER.XMC.PL

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]
  1. ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
  2. ^ 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.
  3. ^ SVK allows Subversion to have distributed branches.
  4. ^ 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
  1. ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
  2. ^ 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.
  3. ^ SVK allows Subversion to have distributed branches.
  4. ^ 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.
  5. ^ A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
  6. ^ Mercurial 0.5b vs git. overview of performance/scalability.
  7. ^ 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.
  8. ^ 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 ?
  1. ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
  2. ^ 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.
  3. ^ SVK allows Subversion to have distributed branches.
  4. ^ 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.
  5. ^ A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
  6. ^ Mercurial 0.5b vs git. overview of performance/scalability.
  7. ^ 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.
  8. ^ a b ssh tunneling is optional
  9. ^ They can be automatically generated[1] and manually verified, but verification is not automatic
  10. ^ Tags were introduced into Bazaar in version 0.15. Previous versions needed to use a plug in.
  11. ^ darcs' patches each bear a unique identifier, it's pretty much impossible to merge twice the same patch in a repository
  12. ^ Mercurial versions 0.9.4 and higher support symlinks.
  13. ^ It could be done via user level hooks
  14. ^ http://www.perforce.com/perforce/technotes/note007.html
  15. ^ 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]
  16. ^ StarTeam supports atomic commits as of version 2006
  17. ^ 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.
  18. ^ A separate tool "svnmerge" provides merge tracking, see [3]. Merge tracking will be included in Subversion itself in the next major release, see [4]
  19. ^ 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.
  20. ^ Uses subversion server
  21. ^ Its possible to embed the action in a shell or Ant script.
  22. ^ 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
  1. ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
  2. ^ 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.
  3. ^ SVK allows Subversion to have distributed branches.
  4. ^ 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.
  5. ^ A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
  6. ^ Mercurial 0.5b vs git. overview of performance/scalability.
  7. ^ 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.
  8. ^ a b ssh tunneling is optional
  9. ^ They can be automatically generated[6] and manually verified, but verification is not automatic
  10. ^ Tags were introduced into Bazaar in version 0.15. Previous versions needed to use a plug in.
  11. ^ darcs' patches each bear a unique identifier, it's pretty much impossible to merge twice the same patch in a repository
  12. ^ Mercurial versions 0.9.4 and higher support symlinks.
  13. ^ It could be done via user level hooks
  14. ^ http://www.perforce.com/perforce/technotes/note007.html
  15. ^ 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]
  16. ^ StarTeam supports atomic commits as of version 2006
  17. ^ 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.
  18. ^ A separate tool "svnmerge" provides merge tracking, see [8]. Merge tracking will be included in Subversion itself in the next major release, see [9]
  19. ^ 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.
  20. ^ Uses subversion server
  21. ^ Its possible to embed the action in a shell or Ant script.
  22. ^ A merged is tracked by its workspace origin.
  23. ^ hgweb for single-repository access and hgwebdir for multiple repository access from a single HTTP address
  24. ^ 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.
  1. ^ Although Bazaar is a distributed version control system it can also be used in a centralized manner using lock step development and checkouts.
  2. ^ 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.
  3. ^ SVK allows Subversion to have distributed branches.
  4. ^ 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.
  5. ^ A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
  6. ^ Mercurial 0.5b vs git. overview of performance/scalability.
  7. ^ 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.
  8. ^ a b ssh tunneling is optional
  9. ^ They can be automatically generated[11] and manually verified, but verification is not automatic
  10. ^ Tags were introduced into Bazaar in version 0.15. Previous versions needed to use a plug in.
  11. ^ darcs' patches each bear a unique identifier, it's pretty much impossible to merge twice the same patch in a repository
  12. ^ Mercurial versions 0.9.4 and higher support symlinks.
  13. ^ It could be done via user level hooks
  14. ^ http://www.perforce.com/perforce/technotes/note007.html
  15. ^ 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]
  16. ^ StarTeam supports atomic commits as of version 2006
  17. ^ 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.
  18. ^ A separate tool "svnmerge" provides merge tracking, see [13]. Merge tracking will be included in Subversion itself in the next major release, see [14]
  19. ^ 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.
  20. ^ Uses subversion server
  21. ^ Its possible to embed the action in a shell or Ant script.
  22. ^ A merged is tracked by its workspace origin.
  23. ^ hgweb for single-repository access and hgwebdir for multiple repository access from a single HTTP address
  24. ^ Any OS that support a Java Virtual Machine 1.5
  25. ^ 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



Page created in 0.369725 Seconds