Comparison of version-control software

The following table contains relatively general attributes of version-control software systems, including: • Repository model, the relationship between copies of the source code repository • Client–server, 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. • Distributed, repositories act as peers, and users typically have a local repository with version history available, in addition to their working copies. • Concurrency model, how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository. • Lock, changes are disallowed until the user requests and receives an exclusive lock on the file from the master repository. • Merge, 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. Distributed version control systems usually use a merge concurrency model. == Technical information ==

The following table shows technical details of some well-known version-control software. These are classified based on the following headers: Table explanation • 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. == Features ==

The following table classifies some well-known software on the basis of its features and capabilities: Table explanation • Software: The name of the application that is described. • Supports Git data format: able to natively work on Git's repository formats • 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 to 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? == Advanced features ==

The following are some more advanced features and capabilities available in notable version-control systems: Table explanation • Keyword expansion: supports automatic expansion of keywords such as file revision number. • Interactive commits: interactive commits allow the user to cherrypick common lines of code used to anchor files (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 automatically substitute (wink-in) derived-objects that were built by other confederated clients that share exactly the same dependencies instead of rebuilding them locally == Basic commands ==

The following table provides further information about commands available in notable version-control systems. Table explanation • 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 • Note: 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. == Advanced commands ==

The following table shows the commands used to execute common tasks in notable version-control systems. Table explanation • 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 • Note: 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. == User interfaces ==

The following table gives Web, GUI and IDE Interface specifications for notable version-control systems. Table explanation • 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: functions are available through an integrated development environment. Minimum function should be to list the revision state of a file and check in/check out files. == History and adoption ==

The following table provides historic background notes on various version-control systems: Table explanation • Software: The name of the application that is described. • History: briefly describes the software's origins and development. • Notable current 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. == See also ==