General information

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.
• 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

• Comparison of source-code-hosting facilities
• List of version-control software

Notes

References

1. 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. ↩

2. "CVS team member list", Non-GNU Savannah, The GNU Project http://savannah.nongnu.org/project/memberlist.php?detailed=1&group=cvs ↩

3. CVS Pro, March Hare http://march-hare.com/cvspro/ ↩

4. "How To Buy". perforce.com. Retrieved 2018-01-18. https://www.perforce.com/how-buy ↩

5. Licesing and pricing, PlasticSCM https://www.plasticscm.com/pricing ↩

6. RTC is not a distributed revision control system; but has some distributed feature that can be configured ↩

7. "What is a distributed version control system". GitLab. https://about.gitlab.com/topics/version-control/benefits-distributed-version-control-system/ ↩

8. Jean-Michel Lemieux, Countdown to the next Rational Team Concert: Part II – Source control enhancements, Jazz Community, archived from the original on 2015-09-10, retrieved 2010-12-28 https://web.archive.org/web/20150910141242/https://jazz.net/blog/index.php/2010/11/05/countdown-to-the-next-rational-team-concert-part-ii-source-control-enhancements/ ↩

9. Various forks of the original Unix sources exist, only one of which is actively maintained ↩

10. While it is possible for multiple users to edit the same version of a file concurrently, only one of them can write back the changes. ↩

11. While some forks of SCCS are free software, others remain closed as parts of commercial Unix distributions. ↩

12. Apache Software Foundation https://www.apache.org/ ↩

13. 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. ↩

14. Rational Synergy, IBM, 9 November 2020 http://www.ibm.com/software/awdtools/synergy ↩

15. Vesta Configuration Management System, Sourceforge, 5 June 2013 http://sourceforge.net/projects/vesta ↩

16. Vesta Configuration Management System, Vesta http://www.vestasys.org ↩

17. 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. /wiki/Pyrex_(programming_language) ↩

18. A Bazaar bundle is a summary diff, with sufficient extra information to preserve history. ↩

19. IBM – Rational ClearCase – United States, 9 November 2020, archived from the original on November 11, 2013 https://web.archive.org/web/20131111164925/http://www-03.ibm.com/software/products/en/clearcase/ ↩

20. "Changesets". March Hare Software Ltd. Retrieved 8 May 2012. http://march-hare.com/cvsnt/features/changesets/ ↩

21. Snapshots with binary files. It's discussed to have binary changesets in future (darcs 3) ↩

22. Fossil Technical Overview http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki ↩

23. Fossil Hash Policy http://fossil-scm.org/index.html/doc/trunk/www/hashpolicy.wiki ↩

24. 4 MB of which are sqlite3.c ↩

25. Git Server Protocol https://www.samba.org/~jelmer/dulwich/docs/protocol.html ↩

26. "Git - fast, scalable, distributed revision control system". GitHub. 2 November 2021. https://github.com/git/git ↩

27. Mercurial revision numbers are local to a repository; they can differ from repository to repository depending on in which order merges are performed. ↩

28. 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. ↩

29. Evil twins are common.Evil Twins in SCM, Not Hollywood Archived 2013-10-16 at the Wayback Machine http://accurev.com/blog/2008/01/24/evil-twins-in-scm-not-hollywood/ ↩

30. "Archived copy" (PDF). Archived from the original (PDF) on 2011-11-13. Retrieved 2012-01-12.{{cite web}}: CS1 maint: archived copy as title (link) https://web.archive.org/web/20111113040629/http://www.accurev.com/download/docs/5.3.0_books/AccuRev_5_3_0_Install_Release_Notes.pdf ↩

31. "SCM News – Kronos Turns to AccuRev for Software Configuration Management". AccuRev. 2004-04-26. Archived from the original on 2014-02-02. Retrieved 2014-01-26. https://web.archive.org/web/20140202091954/http://www.accurev.com/press-releases/20040426-AccuRev-Kronos.html ↩

32. "Enhanced Performance and Scalability for Cross-Platform Geographically Distributed Teams". AccuRev. 2008-09-23. Archived from the original on 2014-02-02. Retrieved 2014-01-26. https://web.archive.org/web/20140202092247/http://www.accurev.com/press-releases/092308-avid-selects-accurev.html ↩

33. "EOL conversions are supported since bzr 1.14". Doc.bazaar-vcs.org. Archived from the original on 2009-04-13. Retrieved 2014-01-26. https://web.archive.org/web/20090413040914/http://doc.bazaar-vcs.org/bzr.1.14/en/release-notes/NEWS.html#bzr-1-14 ↩

34. Atomic commit can be enabled for individual checkin's ClearCase 7.1.1 release notes. https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.relnotes.doc/topics/c_cc_relnotes_features.htm ↩

35. Support Policy for National Languages and ClearCase from IBM Support http://www.ibm.com/support/docview.wss?uid=swg21229688 ↩

36. See FAQ http://darcs.net/FAQ#can-darcs-handle-symlinks ↩

37. darcs' patches each bear a unique identifier, impossible to merge twice the same patch in a repository (without destructively modifying history using "unsafe" commands). ↩

38. Although it stores (and shows by default) 8-bit filename. See FAQ http://darcs.net/FAQ#can-i-version-control-files-with-characters-in-the-full-unicode-spectrum ↩

39. Using Item Revision Attributes ("Working with Items" demo, covering user define attributes Archived 2016-03-04 at the Wayback Machine). http://help.serena.com/doc_center/demos/CM_Essentials_items_1.html ↩

40. In the sense that its messages and graphic interfaces have English only localization, though the software is certified running fine on various language operating systems. ↩

41. https://fossil-scm.org/home/doc/tip/www/hooks.md https://fossil-scm.org/home/doc/tip/www/hooks.md ↩

42. Controlled by the 'crnl-glob' setting ([1]) http://fossil-scm.org/index.html/help/setting ↩

43. https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#scale https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#scale ↩

44. 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. ↩

45. Since git-1.7.9 (see release notes Archived 2013-04-15 at archive.today). Older versions do not sign commits, only tags (see the -s option in git-tag(1) Manual page) http://git.kernel.org/?p=git/git.git;a=blob_plain;f=Documentation/RelNotes/1.7.9.txt;hb=HEAD ↩

46. UTF-8 filenames are supported as of version 1.7.10 (MSysGit release notes). https://raw.github.com/msysgit/msysgit/f45b8ee0ef75c03c210a476db9184824ffcb33c1/share/WinGit/ReleaseNotes.rtf ↩

47. 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. https://github.com/peff/git/wiki/SoC-2012-Ideas ↩

48. Integrity enabled change packages provide complete workflow and 21 CFR Part 11 compliant digital signatures against the item controlling the change package. ↩

49. 2009 SP5 added a feature to merge child development paths. ↩

50. Mercurial includes internationalization for more than 10 languages as of 2017. https://www.mercurial-scm.org/repo/hg/file/3c3066367d72/i18n ↩

51. Support depends upon host OS and is well supported under Unix, but not Windows OSs, due to lack of host support. See [2] https://www.mercurial-scm.org/wiki/EncodingStrategy ↩

52. With the Largefiles Extension in core since Hg Rev.:2.0 (2011), the remotefilelog extension (2014), the fsmonitor extension in core since Hg Rev.:3.8 (2016) and the experimental sparse extension in core since Hg Rev.:4.3 (2017). https://www.mercurial-scm.org/wiki/LargefilesExtension ↩

53. It could be done via user level hooks ↩

54. [4] Archived 2014-02-10 at the Wayback Machine from the Perforce User's Guide http://www.perforce.com/perforce/doc.current/manuals/p4guide/04_files.html#1060858 ↩

55. [5] Archived 2014-02-09 at the Wayback Machine from the Perforce User's Guide http://www.perforce.com/perforce/doc.current/manuals/p4guide/05_resolve.html#1068311 ↩

56. Perforce will version-control symbolic links themselves, but will not recognise its own version-controlled views (local file trees), if you access them via symbolic links. ↩

57. "Perforce Public Knowledge Base – Home". Perforce.com. Archived from the original on 2007-08-14. Retrieved 2014-01-26. https://web.archive.org/web/20070814143752/http://www.perforce.com/perforce/technotes/note009.html ↩

58. "Perforce Knowledge Base: Internationalization and Localization". Kb.perforce.com. 2010-10-21. Archived from the original on 2012-02-08. Retrieved 2014-01-26. https://web.archive.org/web/20120208133709/http://kb.perforce.com/?article=66 ↩

59. "Perforce Knowledge Base: Internationalization and Localization". Kb.perforce.com. 2010-10-21. Archived from the original on 2013-01-30. Retrieved 2014-01-26. https://web.archive.org/web/20130130095324/http://kb.perforce.com/article/66/internationalization-and-localization#i18n ↩

60. Through the process behaviour components: Operation advisors and Operation participants. http://jazz.net/library/article/292 http://jazz.net/library/article/292 ↩

61. While the source code of SCCS has been written to support internationalisation, only English message texts exist. ↩

62. StarTeam supports atomic commits as of version 2006 ↩

63. 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. ↩

64. Since SVN 1.8 subversion supports improved move-tracking on the client side. On the server-side it's not supported yet. ↩

65. "Changeset Signing". Apache Subversion Mailing Lists. Retrieved 2016-08-05. http://svn.haxx.se/dev/archive-2015-06/0052.shtml ↩

66. New to SVN 1.5 . A separate tool "svnmerge" <[3]> provides merge tracking for older versions. https://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking ↩

67. 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. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html ↩

68. [6] – Seapine Software Releases Surround SCM 2009 http://www.seapine.com/pr.php?id=147&title=Seapine_Software_Releases_Surround_SCM_2009 ↩

69. in Asian releases (v6.6a to v7.1a) and since version 7.2 in general ↩

70. Version change history is removed upon rename; old name not referenced. ↩

71. "GitCentric | AccuRevGit for the Enterprise". Accurev.com. Archived from the original on 2012-10-17. Retrieved 2014-01-26. https://web.archive.org/web/20121017043025/http://www.accurev.com/kando ↩

72. "Bazaar keywords plugin". Wiki.bazaar.canonical.com. 2005-09-05. Archived from the original on 2014-02-01. Retrieved 2014-01-26. https://web.archive.org/web/20140201213944/http://wiki.bazaar.canonical.com/KeywordExpansion ↩

73. "Bazaar interactive plugin". Launchpad.net. 7 March 2008. Retrieved 2014-01-26. https://launchpad.net/bzr-interactive ↩

74. "Bazaar Externals plugin". Launchpad.net. 9 November 2009. Retrieved 2014-01-26. http://launchpad.net/bzr-externals ↩

75. not implemented yet https://bugs.launchpad.net/bzr/+bug/245170 ↩

76. "Ignore merge operation for given extension". 4 March 2010. https://answers.launchpad.net/bzr/+question/103163 ↩

77. "bzr-svn". Launchpad.net. 8 May 2006. Retrieved 2014-01-26. http://launchpad.net/bzr-svn ↩

78. "bzr-git". Launchpad.net. 15 July 2006. Retrieved 2014-01-26. http://launchpad.net/bzr-git ↩

79. "bzr-hg". Launchpad.net. 13 June 2006. Retrieved 2014-01-26. http://launchpad.net/bzr-hg ↩

80. IBM Rational ClearCase: The ten best triggers from IBM DeveloperWorks http://www.ibm.com/developerworks/rational/library/4311.html#N10496 ↩

81. Can not be disabled in dynamic views. ↩

82. Using alias of the CVSROOT/modules file. ↩

83. CVS records executable bit when a file is added, but does not allow changing it later on. ↩

84. This is a GUI feature supported by TortoiseCVS and WinCVS both of which include/use CVSNT. ↩

85. Same as CVS, plus also the ability to have replicated repositories including 'shadow' repositories. ↩

86. Use the module/directory name or an alias created using CVSROOT/modules or CVSROOT/modules2 administration file. ↩

87. CVSNT supports this when the make/build tool used also supports it. ↩

88. Darcs can do sparse checkouts from explicit checkpoints on darcs-1 repositories, but not from darcs-2 ones[citation needed] /wiki/Wikipedia:Citation_needed ↩

89. Darcs can automatically detect #! scripts and make them executable on checkout. ↩

90. Using Sub Project functionality (Documentation Portfolio | User's Guide | Relating a Project or Stream to Other Objects). http://help.serena.com/doc_center/doc_center.html#dcm ↩

91. Checkouts can be nested with "fossil open –nested" ↩

92. The manifest, Fossil file formats http://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#manifest ↩

93. "Fossil import and export". Fossil-scm.org. 2014-01-22. Archived from the original on 2014-02-02. Retrieved 2014-01-26. https://web.archive.org/web/20140202093934/http://www.fossil-scm.org/index.html/doc/trunk/www/inout.wiki ↩

94. "FossilHelp: import" https://fossil-scm.org/home/help/import ↩

95. The Git FAQ states that keyword expansion is not a good thing https://git.wiki.kernel.org/index.php/GitFaq#Does_Git_have_keyword_expansion.3F ↩

96. add -i and add -p, see git-add(1) Manual Page http://www.kernel.org/pub/software/scm/git/docs/git-add.html ↩

97. "git-submodule(1) Manual Page". Kernel.org. 2013-02-15. Retrieved 2014-01-26. http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html ↩

98. "git-read-tree(1) Manual Page". kernel.org. 2014-08-24. Retrieved 2014-10-24. http://git-scm.com/docs/git-read-tree#_sparse_checkout ↩

99. The Git FAQ explains why preserving modification time is considered harmful https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F ↩

100. "Mercurial KeywordExtension page". Mercurial-scm.org. Retrieved 2014-01-26. https://www.mercurial-scm.org/wiki/KeywordExtension ↩

101. "Mercurial RecordExtension page". Mercurial-scm.org. 2013-08-27. Retrieved 2014-01-26. https://www.mercurial-scm.org/wiki/RecordExtension ↩

102. "Subrepository – Mercurial". Mercurial-scm.org. Retrieved 2016-04-22. https://www.mercurial-scm.org/wiki/Subrepository?action=show&redirect=Subrepositories ↩

103. With the sparse extension included in core since Hg Rev.:4.3. https://www.mercurial-scm.org/wiki/Release4.3 ↩

104. "Mercurial Timestamp Extension". Mercurial-scm.org. 2012-04-24. Retrieved 2014-01-26. https://www.mercurial-scm.org/wiki/TimestampExtension ↩

105. "Merge Tool Configuration". Mercurial-scm.org. 2017-03-14. Retrieved 2017-09-05. https://www.mercurial-scm.org/wiki/MergeToolConfiguration ↩

106. "hgsubversion page". Mercurial-scm.org. 2013-08-28. Retrieved 2014-01-26. https://www.mercurial-scm.org/wiki/HgSubversion ↩

107. "Hg-Git Mercurial Plugin". Hg-git.github.com. Retrieved 2014-01-26. https://hg-git.github.io/ ↩

108. "Mercurial ConvertExtension page". Mercurial-scm.org. 2013-11-29. Retrieved 2014-01-26. https://www.mercurial-scm.org/wiki/ConvertExtension ↩

109. "Mercurial: the definitive guide: Appendix: Migrating to Mercurial" https://book.mercurial-scm.org/read/app-svn.html ↩

110. "P4 User's Guide". Perforce. Retrieved 19 January 2018. https://www.perforce.com/perforce/doc.current/manuals/p4guide/ ↩

111. "P4 User's Guide". Perforce. Retrieved 19 January 2018. https://www.perforce.com/perforce/doc.current/manuals/p4guide/ ↩

112. "P4 User's Guide". Perforce. Retrieved 19 January 2018. https://www.perforce.com/perforce/doc.current/manuals/p4guide/ ↩

113. Configurable on server as a Project Option and on the client as a User Option. ↩

114. "Keyword Substitution". Svnbook.red-bean.com. Retrieved 2014-01-26. http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html ↩

115. Through third-party tools such as Tortoise SVN. /wiki/Tortoise_SVN ↩

116. "Externals Definitions". Svnbook.red-bean.com. Retrieved 2014-01-26. http://svnbook.red-bean.com/en/1.0/ch07s03.html ↩

117. SVN can not preserve file modification times. On request by the client, it can restore check-in time as last-modified time. Disabled by default. ↩

118. MIME type of the file must be detected as a "human-readable" MIME type, even if the merge tool can work with non-human-readable files ↩

119. Standalone Branch, archived from the original on 2016-03-04, retrieved 2014-11-06 https://web.archive.org/web/20160304051444/http://wiki.bazaar.canonical.com/StandaloneBranch ↩

120. Shared Repository, archived from the original on 2016-03-04, retrieved 2014-11-06 https://web.archive.org/web/20160304051558/http://wiki.bazaar.canonical.com/SharedRepository ↩

121. Standalone Branch, archived from the original on 2016-03-04, retrieved 2014-11-06 https://web.archive.org/web/20160304051444/http://wiki.bazaar.canonical.com/StandaloneBranch ↩

122. Heavyweight Checkout and Lightweight Checkout, archived from the original on 2016-06-30, retrieved 2014-11-06 https://web.archive.org/web/20160630164203/http://wiki.bazaar.canonical.com/Checkout ↩

123. rebase plugin ↩

124. darcs's default pull command is interactive, allowing the user to choose which patches to apply (merge) in realtime ↩

125. darcs doesn't have named branches, local or not, branching is handled solely through repository cloning ↩

126. darcs's default pull command is interactive, allowing the user to choose which patches to apply (merge) in realtime ↩

127. darcs send prepares a bundle of patches, defaults to sending it by mail but can send it to a file instead ↩

128. copies are detected after the fact, much like renames ↩

129. Mercurial Bookmarks are similar to local branches. https://www.mercurial-scm.org/wiki/Bookmarks ↩

130. "Mercurial Rebase Extension". Mercurial-scm.org. 2012-10-25. Retrieved 2014-04-23. https://www.mercurial-scm.org/wiki/RebaseExtension ↩

131. SCCS has implicit locks, applied when checking out via edit, removed when creating a delta. ↩

132. Through any of various means, place (to-be-immutable) file in an immutable directory prior to vcheckin. ↩

133. mv(1) or link(2) the immutable file from its origin immutable directory to its destination immutable directory prior to vcheckin. ↩

134. Through any of various means, copy the immutable file from its origin immutable directory to its destination immutable directory prior to vcheckin. ↩

135. One can also enable this as a central preference in the repository server control panel or configuration file. ↩

136. Requires administrator privileges. One can 'roll back' a change using 'cvs update -e -j @commitid -j "@↩

137. yes - use TortoiseCVS or WinCVS to commit the change to the destination and select which specific files to keep ↩

138. bisect is also available for cvs which should work with CVSNT ↩

139. "bug 6463 - enh: search repository". Retrieved 8 May 2012. http://customer.march-hare.com/webtools/bugzilla/ttshow_bug.cgi?id=6463&tt=1 ↩

140. 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 ↩

141. fossil stash supports multiple shelves with comments. ↩

142. git stash is a multi-level shelve, it's possible to shelve several change groups at the same time ↩

143. "Mercurial Shelve extension page". Mercurial-scm.org. 2013-11-07. Retrieved 2014-01-26. https://www.mercurial-scm.org/wiki/ShelveExtension ↩

144. "Mercurial Strip extension page". Mercurial-scm.org. Retrieved 11 May 2016. https://www.mercurial-scm.org/wiki/StripExtension ↩

145. "graft -core command (since Hg Rev.2.0)". Selenic.com. Retrieved 2014-01-26. http://www.selenic.com/mercurial/hg.1.html#graft ↩

146. "Mercurial Transplant extension page". Mercurial-scm.org. 2012-05-12. Retrieved 2014-01-26. https://www.mercurial-scm.org/wiki/TransplantExtension ↩

147. Only works on a local repository and only on revisions without children. The disapprove command might be an alternative. ↩

148. "The Perforce Broker". Perforce.com. Archived from the original on 2013-11-16. Retrieved 2014-01-26. https://web.archive.org/web/20131116041152/http://www.perforce.com/perforce/r10.2/manuals/p4sag/11_broker.html ↩

149. "Perforce Knowledge Base: "Cherry Picking" Integrations". Kb.perforce.com. 1990-01-01. Archived from the original on 2012-03-09. Retrieved 2014-01-26. https://web.archive.org/web/20120309215524/http://kb.perforce.com/article/567 ↩

150. experimental in SVN 1.10 (release notes) https://subversion.apache.org/docs/release-notes/1.10#shelving ↩

151. SVN Bisect tool svn-bisect https://search.cpan.org/dist/App-SVN-Bisect/bin/svn-bisect ↩

152. svn status lists differences between working copy and repository, not differences between two repositories ↩

153. "Supported Integrations – PTC Integrity". Mks.com. 2012-09-10. Archived from the original on 2012-07-25. Retrieved 2014-01-26. https://web.archive.org/web/20120725110643/http://www.mks.com/customer-service/supported-versions-platforms-integrations/supported-integrations ↩

154. hgweb for single-repository access and hgwebdir for multiple repository access from a single HTTP address ↩

155. "La Chose : web agency and software maker – agence web et développement de logiciels". Archived from the original on 2016-06-18. Retrieved 2006-09-20. https://web.archive.org/web/20160618161540/http://www.lachoseinteractive.net/en/community/subversion/svnx/features/ ↩

156. Distributed Source Control System. Portal.acm.org. 1997-05-18. pp. 98–107. ISBN 9783540630142. Retrieved 2014-01-26. 9783540630142 ↩

157. Towards A Better SCM: Revlogs and Mercurial, presented by Matt Mackall to the Ottawa Linux Symposium, July 2006 https://www.mercurial-scm.org/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial.pdf ↩

158. "GCC: Anonymous read-only Git access". Retrieved 24 October 2023. https://gcc.gnu.org/git.html ↩

159. "A Hacker's Guide to GnuPG". 11 March 2021. Retrieved 24 October 2023. https://www.gnupg.org/faq/HACKING.html ↩

160. "Getting and Working With the Perl Source". dev.perl.org. Retrieved 2014-01-26. http://dev.perl.org/perl5/source.html ↩

161. "Setup and building". Python.org. Retrieved 2023-10-24. https://devguide.python.org/getting-started/setup-building/ ↩

162. "Git". MediaWiki. Retrieved 1 August 2012. https://www.mediawiki.org/wiki/Git ↩

163. "The largest Git repo on the planet". May 24, 2017. https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/ ↩

164. "PTC Sets New Standard for Managing Hardware and Software Development Lifecycles with MKS Integrity Acquisition – PTC Integrity". Mks.com. Archived from the original on 2014-07-22. Retrieved 2014-01-26. https://web.archive.org/web/20140722103846/http://www.mks.com/about-MKS/press/press-releases/ptc-sets-new-standard-for-managing-hardware-and-software-development-lifecycles-with-mks-integrity-acquisition ↩

165. Towards A Better SCM: Revlogs and Mercurial, presented by Matt Mackall to the Ottawa Linux Symposium, July 2006 https://www.mercurial-scm.org/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial.pdf ↩

166. "Some projects that use Mercurial", Mercurial (wiki), Mercurial-scm.org. https://www.mercurial-scm.org/wiki/ProjectsUsingMercurial ↩

167. Rochkind, Marc J. (December 1975), "The Source Code Control System" (PDF), IEEE Transactions on Software Engineering, vol. SE-1, no. 4, pp. 364–370, doi:10.1109/tse.1975.6312866, S2CID 10006076, archived from the original (PDF) on 2011-05-25, retrieved 2014-07-31 https://web.archive.org/web/20110525193926/http://basepath.com/aup/talks/SCCS-Slideshow.pdf ↩

168. http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/news/pibs PWB UNIX product announcement http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/news/pibs ↩

169. Compare the SCCS 4 file format with the SCCS 5.0 Archived 2014-08-19 at the Wayback Machine file format (as manpage sccsfile(4) in "Archived copy". Archived from the original on 2014-08-19. Retrieved 2014-08-17.{{cite web}}: CS1 maint: archived copy as title (link) http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/usr/man/man5/sccsfile.5 ↩

170. Starteam® https://web.archive.org/web/19980507011804/http://demo.starbase.com/WebDraw%2BOld%2BWeb%2BSite/StarTeam/StarTeam.htm ↩