The following is a comparison of revision control software. The following tables include general and technical information on notable revision control and software configuration management (SCM) software. For SCM software not suitable for source code, see Perbandingan -- open source configuration management software.
Software: The name of the application, that is described.
Maintainer: The company or group that is currently taking responsibility for the software's maintenance or development
Development Status: The current status of the software project
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.
License: The license model under which the software is licensed. These can be both free and paid licenses
Platforms Supported: The operating systems that the software application currently supports.
Cost free license, available on application, for OSS or educational use; Also free for up to 20 users, 20 workspaces, and unlimited files;[6] Or free for unlimited users and up to 1,000 files; Else $740-$900 per seat in perpetuity, or $144-$300 per seat per year on a subscription model, both with volume discounts[7]
Server: Windows Server 2003 or later, Windows 7 or 8 (for Express edition only); Clients: Windows and Web included
Free for up to 5 users in the TFS 11 express edition or for open source projects through codeplex.com; else non-free, licensed through MSDN subscription or direct buy.
Software: The name of the application that is described.
Programming language: The coding language in which the application is being developed
Storage Method: Describes the form in which files are stored in the repository. A snapshot indicates that a committed file(s) is stored in its entirety—usually compressed. A changeset, in this context, indicates that a committed file(s) is stored in the form of a difference between either the previous version or the next.
Scope of change: Describes whether changes are recorded for individual files or for entire directory trees.
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). With Integrated Difference, revisions are based on the Changesets themselves, which can describe changes to more than one file.
Network protocols: lists the protocols used for synchronization of changes.
Source code size: Gives the size of the source code in megabytes.
Software: The name of the application that is described.
Atomic commits: refers to a guarantee that all changes are made, 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, regardless of whether these names are called tags or labels.
International Support: indicates if the software has support for multiple language environments and operating system
Unicode filename support: indicates if the software has support for interoperations under file systems using different character encodings.
Supports large repos: Can the system handle repositories of around a gigabyte or larger effectively?
keyword expansion: Supports automatic expansion of keywords such as file revision number.
interactive commits: Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit (leaving unselected changes as changes in the working copy), instead of having only a file-level granularity.
external references: embedding of foreign repositories in the source tree
partial checkout/clone: Ability to check out or clone only a specified subdirectory from a repository.
permissions: Tracks file permission bits in the revision history.
timestamp preservation: Overwrites the last modified filesystem attribute with the commit time upon checkout.
custom automatic merge tool: Automatic merging can be attempted by any tool of the user's choice (hopefully configurable on a per-file basis)
supported formats: either read/write support or read-only (conversion, potentially repeated)
shared build cache of derived objects: the ability to wink-in derived-objects that were built by other confederated clients that share exactly the same dependencies instead of rebuilding them locally
git, cvs, subversion, hg, any that has a fastexporter
No
Vesta
No
No
Yes via SDL
No
Unknown
Yes
No
Vesta
Yes
software
keyword expansion
interactive commits
external references
partial checkout/clone
permissions
timestamp preservation
custom automatic merge tool
supported formats
shared build cache of derived objects
Basic commands
Table explanation
Commands in green rectangles that are not surrounded by [square brackets] are at an interactive command-line prompt. Text in [square brackets] is an explanation of where to find equivalent functionality.
repository init: Create a new empty repository (i.e., version control database)
clone: Create an identical instance of a repository (in a safe transaction)
pull: Download revisions from a remote repository to a local repository
push: Upload revisions from a local repository to a remote repository
local branches: Create a local branch that does not exist in the original remote repository
checkout: Create a local working copy from a (remote) repository
update: Update the files in a working copy with the latest version from a repository
lock: Lock files in a repository from being changed by other users
add: Mark specified files to be added to repository at next commit
remove: Mark specified files to be removed at next commit (note: keeps cohesive revision history of before and at the remove.)
move: Mark specified files to be moved to a new location at next commit
copy: Mark specified files to be copied at next commit
merge: Apply the differences between two sources to a working copy path
commit: Record changes in the repository
revert: Restore working copy file from repository
generate bundle file: Create a file that contains a compressed set of changes to a given repository
rebase: Forward-port local commits to the updated upstream head
Commands in green rectangles that are not surrounded by [square brackets] are at an interactive command-line prompt. Text in [square brackets] is an explanation of where to find equivalent functionality.
command aliases: create custom aliases for specific commands or combination thereof
lock/unlock: exclusively lock a file to prevent others from editing it
shelve/unshelve: temporarily set aside part or all of the changes in the working directory
rollback: remove a patch/revision from history
cherry-picking: move only some revisions from a branch to another one (instead of merging the branches)
bisect: binary search of source history for a change that introduced or fixed a regression
incoming/outgoing: query the differences between the local repository and a remote one (the patches that would be fetched/sent on a pull/push)
grep: search repository for lines matching a pattern
record: include only some changes to a file in a commit and not others
Software: The name of the application that is described.
Web Interface: Describes whether the software application contains a web interface. A web interface could allow the software to post diagnostics data to a website, or could even allow remote control of the software application.
GUIs: A GUI is a graphical user interface. If a software product features a GUI its functionality can be accessed through application windows as opposed to accessing functionality based upon typing commands at the command prompt such as a DOS interface.
Plug-ins: functionality is available through an Integrated Development Environment. Minimum functionality should be to list the revision state of a file and check in/check out files.
Software: The name of the application that is described.
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.
Original company founded in 1977; CA SCM (then called CCC/Harvest) first released in 1995.
CA does not disclose customer lists without the companies' permission. CA SCM is used by companies with global development teams including 13 of the Fortune 100.
ClearCase
1990 Developed beginning in 1990 by Atria Software, following concepts developed by Apollo Computer in DSEE during the 1980s. The most recent version is 7.1.1, released in Dec 2009.
1998 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.
1972Started by Marc Rochkind in 1972 (binary history files, written in Snobol on IBM-370[citation needed]), SCCSv4 with text history files was published February 18, 1977.[citation needed] The same history file format is still used in SCCSv5.[original research?]
as the POSIX source-control tool, SCCS is widely available on UNIX platforms, but not included in many Linux distributions. Sun WorkShop TeamWare uses SCCS files.
2003 Authored by Chia-liang Kao with Audrey Tang. First version was on November 19, 2003. 1.00 on May 9, 2005. 2.0.0 on Dec 28th, 2006. SVK became a product of Best Practical on June 5, 2006.
1988 Developed beginning in 1988 by Caseware, as AmplifyControl. The company was renamed Continuus in 1994, where the product became better known as Continuus/CM. Continuus was acquired by Telelogic in 1999 shortly after going public; the product was renamed Telelogic Synergy. IBM acquired Telelogic in 2008 for integration into their Rational tool suite. The product is now known as IBM Rational Synergy.
General Motors, BMW, Chrysler, Nokia, Philips, Raytheon, Morgan Stanley, Friends Provident, Boeing, Lockheed Martin, Siemens and other small, medium and large organizations worldwide[citation needed]
Team Foundation Server
2006 First publicly released on March, 2006
Available on CodePlex, Microsoft itself and other large organizations worldwide[citation needed]
Vault
2003 First publicly released in February, 2003
Unknown
Vesta
1991 First publicly released under the LGPL in 2001
DEC Alpha team, Compaq Alpha team, Intel microprocessor development
Visual SourceSafe
1995 originally created by a company called One Tree Software, version 3.1. Company was bought by Microsoft which released version 4.0 of VSS around 1995
^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.
^"a workspace can be synchronized with more than one LibreSource Synchronizer. As a limitation, the network must have tree topology." says LibreSource Synchronizer.
^RTC is not a distributed revision control system; but has some distributed feature that can be configured
^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.
^Bazaar's critical modules are written in Pyrex. They are automatically translated to pure C; except for the patience sorting module, used in merge resolution, which is written directly in the C language.
^A Bazaar bundle is a summary diff, with sufficient extra information to preserve history.
^Mercurial revision numbers are local to a repository; they can differ from repository to repository depending on in which order merges are performed.
^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.
^Veracity revision numbers are local to a repository; they can differ from repository to repository depending on in which order merges are performed.
^darcs' patches each bear a unique identifier, impossible to merge twice the same patch in a repository (without destructively modifying history using "unsafe" commands).
^Git does not explicitly track renames, because by design it does not track individual files. Renames and split of source files are detected after the fact, if the file content does not change dramatically.
^Git has some issues with very large repositories. See Section Better big-file support and Section Designing a faster index format in SoC 2012 Ideas.
^Integrity enabled change packages provide complete workflow and 21 CFR Part 11 compliant digital signatures against the item controlling the change package.
^2009 SP5 added a feature to merge child development paths.
^Its possible to embed the action in a shell or Ant script.
^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.
^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 http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html 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.
^Through any of various means, place (to-be-immutable) file in an immutable directory prior to vcheckin.
^mv(1) or link(2) the immutable file from its origin immutable directory to its destination immutable directory prior to vcheckin.
^Through any of various means, copy the immutable file from its origin immutable directory to its destination immutable directory prior to vcheckin.
^You can also enable this as a central preference in the repository server control panel or configuration file
^Requires administrator privileges. You can 'rollback' a change using 'cvs update –e –j @commitid –j "@<commitid"' but the change and rollback evidence remains in the history
^yes - use TortoiseCVS or WinCVS to commit the change to the destination and select which specific files to keep
^bisect is also available for cvs which should work with CVSNT
^darcs operate on patches not revision, cherrypicking simply consists in pulling a given patch from one repository to another one as long as the dependencies are fulfilled
Years, where available, indicate the date of first stable release. Systems with names in italics are no longer maintained or have planned end-of-life dates.
Tags: Comparison of revision control software, Komputer Sains, 2243, Perbandingan revision control software The following is a comparison of revision control software, The following tables include general and technical information on notable revision control and software configuration management (SCM) software, For SCM software not suitable for source code see Perbandingan open source configuration management software, Contents General information 2 Technical, Comparison of revision control software, Bahasa Indonesia, Contoh Instruksi, Tutorial, Referensi, Buku, Petunjuk m.kelas karyawan ftumj, prestasi.web.id
