Version Control Systems Comparison

Version Control System Comparison
This is a comparison of version-control systems. It is split into several categories and sub-categories under which the systems are checked.
Timestamp: $Id: scm-comparison.xml 262 2006-05-20 10:12:11Z shlomif $
Version Control System ComparisonRepository OperationsAtomic CommitsFiles and Directories Moves or RenamesFile and Directories CopiesRemote Repository ReplicationPropagating Changes to Parent RepositoriesRepository PermissionsChangesets‘ SupportTracking Line-wise File History
FeaturesAbility to Work only on One Directory of the RepositoryTracking Uncommited ChangesPer-File Commit Messages
Technical StatusDocumentationEase of DeploymentCommand SetNetworking SupportPortability
User InterfacesWeb InterfaceAvailability of Graphical User-Interfaces.
License
Repository Operations
Atomic Commits
Support for atomic commits means that if an operation on the repository is interrupted in the middle, the repository will not be left in an inconsistant state. Are the check-in operations atomic? Are the check-in operations atomic, or can interrupting an operation leave the repository in an intermediate state?
CVS No. CVS commits are not atomic.
Aegis Commits are atomic.
Arch Yes. Commits are atomic.
BitKeeper Yes (but need to verify)
ClearCase Yes. Commits (checkins) are atomic.
CMSynergy Yes. Commits are atomic.
Co-Op Yes. Commits are atomic.
Darcs Yes. Commits are atomic.
Mercurial Yes.
Monotone Yes.
OpenCM Yes. Commits are atomic.
Perforce Yes. Commits are atomic.
PureCM Yes. Commits are atomic.
Subversion Commits are atomic.
Superversion Commits are atomic.
svk Commits are atomic.
Vesta Yes. Commits are atomic.
Visual SourceSafe No. VSS commits are not atomic.
Files and Directories Moves or Renames
Does the system support moving a file or directory to a different location while still retaining the history of the file?
CVS No. Renames are not supported and a manual one may break history in two.
Aegis Yes. Renames are supported.
Arch Yes. Renames are supported.
BitKeeper Yes. Renames are supported.
ClearCase Yes. Directories are first-class controlled entities in Clearcase. Even supports controlling of symbolic/hard links.
CMSynergy Yes. Renames are supported.
Co-Op Renames of files are supported. Renaming a directory requires creating a new one, moving the files and deleting the old one. Moved file histories are preserved.
Darcs Yes. Renames are supported.
Mercurial Yes. Renames are supported.
Monotone Yes. Renames are supported.
OpenCM Yes. Renames are supported
Perforce Not directly (you copy and then delete but it manages to keep track of the branch; the item below allows for this very feature)
PureCM Yes. File renames are directly supported. File and folder moves require creating a new one and deleting the old one. Moved file histories are preserved.
Subversion Yes. Renames are supported.
Superversion No. Renames are not supported.
svk Yes. Renames are supported.
Vesta Yes. The unit of checkout/checkin is a directory tree. Files and directories can be added, deleted, and renamed between versions.
Visual SourceSafe Affects the whole history, it‘s like renaming a file in the CVS repository. There is a kludgy workaround using "share-rename,move,delete" that gets what you want.
File and Directories Copies
Does the version control system supports copying files or directories to a different location at the repository level, while retaining the history?
CVS No. Copies are not supported.
Aegis No. Copies are not supported.
Arch No. Copies of files and directory structures are not supported.
BitKeeper Yes. Copies are supported.
ClearCase Yes, through use of hard links. (But some limitations in Windows environments)
CMSynergy Yes, and it‘s a very cheap operation (update the target directory to include the new file/directory).
Co-Op Copying doesn‘t retain history, moving does.
Darcs No. Copies of files and directory structures are not supported.
Mercurial Yes. Copies are supported
Monotone Yes. Copies are supported
OpenCM No. Copies are not supported.
Perforce Copies are supported (though, because of its architecture, I don‘t know how well)
PureCM Yes. Copies are supported.
Subversion Yes. And it‘s a very cheap operation (O(1)) that is also utilized for branching
Superversion No. Copies are not supported.
svk Yes. Same as subversion.
Vesta Yes. A new package/branch can be based on any existing version without affecting the past history. (This is also an O(1) operation.)
Visual SourceSafe Yes. Copies are supported up to a point.
Remote Repository Replication
Does the system support cloning a remote repository to get a functionally equivalent copy in the local system? That should be done without any special access to the remote server except for normal repository access.
CVS Indirectly, by usingCVSup by John Polstra (which requires running the cvsupd daemon on the server)
Aegis Yes.
Arch Yes.
BitKeeper Yes.
ClearCase Not really applicable for clearcase, but see next point.
CMSynergy Yes, as long as you have the (more expensive) Distributed package.
Co-Op Repositories are always replicated on local machines. There is no central server.
Darcs Yes.
Mercurial Yes.
Monotone Yes.
OpenCM No.
Perforce Yes. Via the Perforce Proxy (P4P) tool.
PureCM No.
Subversion Indirectly, by using Chia-liang Kao‘sSVN::Mirror add-on or Shlomi Fish‘SVN-Pusher utility.
Superversion Yes.
svk Yes.
Vesta Yes. Replication is a fundamental part of the design.
Visual SourceSafe Not directly possible with the included GUI or command line tools; ssarc and ssrestor might be useable
Propagating Changes to Parent Repositories
Can the system propagate changes from one repository to another?
CVS No.
Aegis Yes.
Arch Yes.
BitKeeper Yes.
ClearCase Yes, using Clearcase Multisite.
CMSynergy Yes, as long as you have the (more expensive) Distributed package.
Co-Op It‘s a peer-to-peer system, which keeps all replicas of the repository in sync.
Darcs Yes.
Mercurial Yes.
Monotone Yes.
OpenCM No.
Perforce Unknown. Probably Not.
PureCM No.
Subversion Yes, using either Chia-Ling Kao‘s SVN::Mirror script or the svn-push utility by Shlomi Fish.
Superversion No.
svk Yes.
Vesta Yes.
Visual SourceSafe Not directly possible with the included GUI or command line tools; ssarc and ssrestor might be useable
Repository Permissions
Is it possible to define permissions on access to different parts of a remote repository? Or is access open for all?
CVS Limited. "pre-commit hook scripts" can be used to implement various permissions systems.
Aegis Yes. Aegis relies on the UNIX permissions system to implement permissions for files in the repository.
Arch Yes. It is possible to define permissions on access to different parts of a remote repository based on the permission systems of the underlying protocol.
BitKeeper FILL IN
ClearCase Yes, a unix-like permissions model is used, which maps onto Windows domain-based authentication in multi-platform environments.
CMSynergy No, though a single server can serve many repositories.
Co-Op First access (joining the project) requires administrator‘s approval. Subsequent access to that project is not controlled.
Darcs No.
Mercurial Yes. It is possible to lock down repositories, subdirectories, or files using hooks.
Monotone Yes. It is possible to restrict incoming changes from certain sources to be performed only in certain parts of the repository.
OpenCM Permissions are defined on a per-branch basis.
Perforce Yes. (more than half a dozen of permission levels that can be set in a file by file basis)
PureCM Yes. (more than half a dozen of permission levels that can be set in a file by file basis)
Subversion Yes. The WebDAV-based service supports defining HTTP permissions for various directories of the repository.
Superversion No.
svk Same as subversion.
Vesta Yes. Access permissions for each package (the unit of checkout/checkin) can be different. Access permissions for a branch can be different from the basis package.
Visual SourceSafe Project specific permissions (read, write, delete, destroy) can be set per user; but see "Networking Support": this makes "Repository Permissions" a hindrance to accidental damage but cannot prevent intentional damage.
Changesets‘ Support
Does the repository supports changesets? Changesets are a way to group a number of modifications that are relevant to each other in one atomic package, that can be cancelled or propagated as needed.
CVS No. Changes are file-specific.
Aegis Yes. Changesets are supported.
Arch Yes. Changesets are supported.
BitKeeper Yes. Changesets are supported.
ClearCase Not supported in this way. Extensive branching support gives similar benefits. (eg each changeset can be given a branch). Also optional UCM feature gives something like this (each changeset is a "stream").
CMSynergy Yes. Changesets (or tasks) are fundamental to the way Synergy works.
Co-Op Yes. Changesets are the default.
Darcs Yes. Changesets are supported.
Mercurial Yes. Changesets are supported.
Monotone Yes. Changesets are supported.
OpenCM Yes. Changesets are supported.
Perforce Yes. Changesets are supported.
PureCM Yes. Changesets are supported.
Subversion Partial support. There are implicit changeset that are generated on each commit.
Superversion Partial support. Changes are grouped into changesets, but cannot be cancelled invididually yet.
svk Same as subversion.
Vesta Not exactly. Vesta uses a related concept of configurations instead, which some has similar properties.
Visual SourceSafe No. Changes are file-specific.
Tracking Line-wise File History
Does the version control system has an option to track the history of the file line-by-line? I.e: for each line show at which revision it was most recently changed, and by whom?
CVS Yes. cvs annotate
Aegis Yes. aeannotate
Arch Not in the command line client, but ViewARCH, a web-interface for Arch, has it.
BitKeeper Yes. (bk annotate)
ClearCase Yes, "cleartool annotate"
CMSynergy Probably, if you‘re a sufficiently proficient hacker with their scripting language.
Co-Op Not directly, but it‘s possible to compare any two versions using a visual differ.
Darcs Yes. (darcs annotate)
Mercurial Yes. (hg annotate)
Monotone Yes, as of version 0.19.
OpenCM Unknown. Probably not.
Perforce Yes, an annotation feature is present.
PureCM No.
Subversion Yes. (svn blame)
Superversion No.
svk Yes. (svk blame)
Vesta No, but it would be easy to implement a tool that did this, as the Vesta repository provides direct filesystem access to all versions.
Visual SourceSafe Not directly, but it‘s possible to compare any two versions using a visual differ.
Features
Ability to Work only on One Directory of the Repository
Can the version control system checkout only one directory of the repository? Or restrict the check-ins to only one directory?
CVS Yes.
Aegis No. All changes are made repository-wide.
Arch It is possible to commit only a certain directory. However, one must check out the entire repository as a whole.
BitKeeper No. All changes are made repository-wide.
ClearCase Yes, using snapshot view load rules.
CMSynergy Yes and no. Files and directories are checked out and in individually, however you have to work in the context of a project, which consists of one or more directories.
Co-Op No. All changes are made to a project as a unit, but it‘s possible to access each file‘s history separately.
Darcs It is possible to commit only a certain directory. However, one must check out the entire repository as a whole.
Mercurial It is possible to commit changes only in a subset of the tree. There are plans for partial checkouts.
Monotone It is possible to commit changes only in a subset of the tree. However, one must extract the entire tree to work on it.
OpenCM No. All changes are made to a project as a unit
Perforce Yes. Changes to a sub-directory of the repository are supported.
PureCM Yes.
Subversion Yes.
Superversion No.
svk Yes.
Vesta Yes and no. The unit of checkout/checkin (called a package) is a directory tree. Most projects use more than one. Once created, a package must be checked out/in as a unit.
Visual SourceSafe Yes.
Tracking Uncommited Changes
Does the software has an ability to track the changes in the working copy that were not yet commited to the repository?
CVS Yes. Using cvs diff
Aegis Yes. Using aediff.
Arch Yes, using "tla changes".
BitKeeper Yes. Using bk diff.
ClearCase Yes, "cleartool diff"
CMSynergy Yes, either using integrated diff tool or user-configured external diff tool
Co-Op Yes, using built-in visual differ/editor.
Darcs Yes, using "darcs whatsnew".
Mercurial Yes. Using hg diff.
Monotone Yes. In a similar fashion to CVS.
OpenCM Yes. Using cm diff
Perforce Yes.
PureCM Yes.
Subversion Yes. Using svn diff
Superversion Yes. Local changes are detected and shown immediately. Changes can be collected in a local buffer before being committed to the repository.
svk Yes. Using svk diff
Vesta Yes. Intermediate immutable snapshots can be taken during an active checkout (with vadvance). These intermediate versions can be treated just like checked in versions: they can be replicated to other repositories and used as the basis for branches.
Visual SourceSafe Yes, using integrated diff tool.
Per-File Commit Messages
Does the system has a way to assign a per-file commit message to the changeset, as well as a per-changeset message?
CVS No. Commit messages are per change.
Arch No.
BitKeeper Yes. It is possible to have a per-file commit message
ClearCase Yes, assuming a comment on the branch is sufficient for a per-changeset message.
CMSynergy Yes.
Co-Op No. Commit messages are per change. They go to all project members and update their repositories.
Darcs No.
Mercurial No.
Monotone Yes. It is possible to attach a comment to a certain file at a certain revision.
OpenCM Unknown.
Perforce No. Commit messages are per change.
PureCM No. Commit messages are per change.
Subversion No. There is no such feature.
Superversion Yes.
svk No. There is no such feature.
Vesta Not exactly. The unit of checkin is a directory, and commit messages are assigned at that level, not to individual files. Since configurations are also versioned, they also have commit messages.
Visual SourceSafe Since changesets are not supported, yes.
Technical Status
Documentation
How well is the system documented? How easy it is to get started using it?
CVS Excellent. There are many online tutorials and resources and an online book. The command line client also provides an online comprehensive help system.
Aegis Medium. The documentation is given in several large scope troff documents, that are only usable as not-so-PDFish PDF documents, and as text documents that lack any formatting. It is very hard to get started using it with the online resources. The content is of good quality, but otherwise not made very accessible.
Arch Medium. There are two online tutorials and a comprehensive online documentation. The command line client also supplies a reference page. However, some of the documentation is out of date or incomplete.
BitKeeper Very good. There is a comprehensive help at the BitKeeper site. Each command is documented in its own man page, and the client contains a help tool that offers an integrated help system.
ClearCase Extensive online help in Windows Help / UNIX manpage format, also PDF-based documentation. However the complexity of the tool can mean a lengthy ramp-up time.
CMSynergy Medium. Lots of books, plus somewhat clunky set of HTML pages, but has some radical concepts which can cause real problems really quickly. They recommend a day‘s training for basic users, more for more advanced users. Took a while to become fluent.
Co-Op Very good. Step-by-step tutorial and HTML help is included.
Darcs Good. The manual contains a brief tutorial and a solid reference. Every sub-command can print its usage. Because the command-set is small and the model is simple, many users find it easy to get started.
Mercurial Very good. There‘s an overview and tutorial on the web site, and integrated help for every command.
Monotone Good. There‘s an overview and tutorial written in Texi, and a man page. The client supplies documentation for every command.
OpenCM Well documented.
Perforce Very Good (html and command line help)
PureCM Very Good (html and command line help)
Subversion Very good. There is a free online book and some online tutorials and resources. The book is written in DocBook/XML and so is convertible to many different formats. The command-line client also provides a good online help system that can be used as a reference.
Superversion Fairly poor. There are two tutorials, but there is no reference. Installing and getting started with the GUI is very easy though.
svk Relatively poor, but improving. There‘sa work-in-progress book as well asthe Wiki and some external Articles and Tutorials.
Vesta Quite thoroughly (HTML, man pages, published papers, a book-length research report).
Visual SourceSafe Medium. Help file which is sometimes useful. However, the interface is reasonably intuitive so documentation isn‘t needed as much.
Ease of Deployment
How easy it is to deploy the software? What are the depenedencies and how can they be satisfied?
CVS Good. Out of being the de-facto standard, CVS is available on most systems and is easy to deploy.
Aegis The Aegis binary should be installed as SUID-root, and so requires root privileges to install. It also not very portable to Win32 systems. Other than that, Aegis supports an easy autoconf or RPM/apt-based installation process.
Arch Excellent. An arch service is nothing but a filesystem-space hosted by any of its supported protocols (FTP, SFTP, WebDAV, etc.). The arch client is written in C, and is portable across UNIX systems (and on Win32 only with a UNIX emulation layer).
BitKeeper Good. All that is required is downloading a binary for the system and installing it using the installation script. The package is self-contained and is easy to set up.
ClearCase Poor. Clearcase is very difficult to install in general. At least, setup for a new site is quite complex. Installing additional servers (eg repository servers) is less so.
CMSynergy Medium. There is a detailed install guide for setting it up using a binary kit and a set of scripts. However it still took several tries to get it properly installed and configured. The Windows client has a slightly clunky Windows installer.
Co-Op Very easy to deploy, since there is no central server. Can be configured to use e-mail or LAN (or both) for synchronization. For e-mail, requires MAPI-compliant e-mail client.
Darcs Very good. darcs requires few external libraries, however you need the Glasgow Haskell Compiler if you cannot find a binary. To start working, just "darcs init".
Mercurial Excellent. Binary packages are available for all popular platforms. Building from source requires only Python 2.3 (or later) and a C compiler.
Monotone Excellent. It is possible to copy or compile the executable to the user‘s machine, without any configuration or external dependencies.
OpenCM Very good. Install the RPM, or build from tarball and install the init script.
Perforce Very good. Perforce is very easy to deploy.
PureCM Very good. PureCM is very easy to deploy.
Subversion A Subversion service requires installing an Apache 2 module (if one wishes to use HTTP as the underlying protocol) or its own proprietary server. The client requires only the Subversion-specific logic and the Neon WebDAV library (for HTTP). Installation of the components is quite straightforward, but will require some work, assuming Subversion does not come prepackaged for one‘s system.
Superversion If Java 1.4 is installed, deployment of Superversion usually takes two clicks.
svk In addition to installing subversion, users are required to install the subversion perl bindings and a few modules from CPAN.
Vesta Medium to Good. There is a detailed installation guide for setting it up using a binary kit. RPMs and Debian packages have been recently released. There are no dependencies on other software. There is a bootstrap package available to build Vesta from using "make".
Visual SourceSafe Very good - an installation package which does the work. When you create a repository it installs the exe‘s in a directory and you can run them from there if you need to.
Command Set
What is the command set? How compatible it is with the commands of CVS (the current open-source defacto standard)?
CVS A simple command set that includes three most commonly used commands (cvs commit, cvs update and cvs checkout) and several others.
Aegis A complex command set that involves many operations just to get started. Not CVS-compatible. (albeit support for such basic operations was contemplated) Note that Aegis is a Software Configuration Management system and not just a simple version control system, which may justify this extra complexity.
Arch Many commands are compatible with CVS or BitKeeper. However, there are many other commands for it for different uses. Aliasing of commands is possible so it it may be possible to make it more compatible.
BitKeeper A CVS-like command set with some easy-to-get-used-to complications due to its different way of work and philosophy.
ClearCase Excellent. All tools are available through the command-line. Not very compatible with CVS though.
CMSynergy An extensive and powerful command set, which has some CVS similarity, though the architecture is so different that it quickly moves away for anything but the basics.
Co-Op Basic commands are compatible with CVS.
Darcs The command set is fairly compact and the core commands are easy to understand. Follows CVS in a few places, but since the model is different most commands are unique.
Mercurial Tries to follow CVS conventions, but deviates where there is a different design.
Monotone Tries to follow CVS conventions, but deviates where there is a different design.
OpenCM A CVS-like command set that is familiar to existing CVS users.
Perforce Very extensive but not compatible with CVS.
PureCM A CVS-like command set which is easy to get used to for CVS-users.
Subversion A CVS-like command set which is easy to get used to for CVS-users.
Superversion There is little need to memorize a command set because all actions take place in a GUI. A part of the terminology used in the application is borrowed from CVS.
svk A CVS-like command set which is easy to get used to for CVS-users.
Vesta The command set is unrelated to CVS. Most of the time, users use about 5 commands. Few ever need to know more than about 20 commands.
Visual SourceSafe A bit of an afterthought. It‘s possible to do basic things, but it‘s really geared up for using the GUI.
Networking Support
How well is the networking integration in the system? How compliant it with existing protocols and infra-structure.
CVS Good. CVS uses a proprietary protocol with various variations for its client/server protocol. This protocol can be tunneled over an SSH-connection to support encryption.
Aegis Poor. Aegis is filesystem-oriented and so can be networked only via NFS (network file-system) or a similar protocol. There exists some HTTP-functionality, but it is quite limited.
Arch Excellent. Arch can utilize a multitude of protocols for its service, which is nothing but a dumb remote filesystem server. Currently supported protocols include FTP, SFTP, WebDAV (remote file access over HTTP), as well as any remote filesystem protocol (NFS, SMB).
BitKeeper Good. Repositories can be checked out from remote over HTTP, and BitKeeper also sports its own proprietary protocol for communicating between one repository and the other.
ClearCase Poor. Uses an *extremely* chatty RPC protocol for most clearcase operations, plus NFS or SMB for accessing the files themselves. Typically servers should be deployed locally (ie on the same LAN) as the client workstations for acceptable performance.
CMSynergy Good (single TCP/IP socket)
Co-Op Uses the simplest LAN interface: copying files between shared directories.
Darcs Good. Darcs supports getting patches over HTTP, and getting and sending patches over SSH and email.
Mercurial Excellent. Uses HTTP or ssh. Remote access also works safely without locks over read-only network filesystems.
Monotone Good. Uses a custom protocol called "netsync".
OpenCM Good. Uses its own proprietary client/server protocol.
Perforce Good. (single TCP/IP socket)
PureCM Good. (single TCP/IP socket)
Subversion Very good. The Subversion service can use either WebDAV+DeltaV (which is HTTP or HTTPS based) as its underylying protocol, or its own proprietary protocol that can be channeled over an SSH connection.
Superversion Good. Network support based on RMI is integrated seamlessly. Encryption and HTTP tunnelling are planned for the near future.
svk Very good. svk uses SVN::Mirror to retrieve remote repository. There has been plans to add VCP support to SVN::Mirror so it will be able to mirror from arbitary remote version control systems.
Vesta Networking is inherent to the system. The repository exports both an NFS interface and an RPC interface. The checkout and checkin tools automatically contact a remote repository when required to perform an operation.
Visual SourceSafe VSS uses a Windows network share which has to be writable for the VSS users (since this means doubling maintenance for new users). Add user in VSS and to share permissions. the share is most often world-writable, as is the default when creating a share) It does not perform well over a slow network connection.
Portability
How portable is the version-control system to various operating systems, computer architectures, and other types of systems?
CVS Good. Client works on UNIX, Windows and Mac OS. Server works on UNIXes and on Windows with a UNIX emulation layer.
Aegis Medium. The source is portable across all UNIXes, but the Windows version work only using cygwin, and even then not entirely natively.
Arch Good. The source is portable across all UNIXes, but requires a UNIX emulation layer on Windows. (need to verify). A service can be hosted on any platform that sports a suitable Internet service.
BitKeeper Very good. Binaries are available for most common UNIX systems and for Windows 98 and above.
ClearCase Medium. Available on Windows, and several selected flavours of UNIX (not including MacOS X, or any other Linux other than Red Hat).
CMSynergy Very good - various flavours of Unix, Windows (only NT family for the server), VMS, and possibly other systems.
Co-Op Windows only: starting with Win95.
Darcs Very good. Supports many UNIXes, Mac OS X, and Windows, and is written in a portable language.
Mercurial Excellent. Runs on all platforms supported by Python. Repositories are portable across CPU architectures and endian conventions.
Monotone Excellent. Executable is portable across all UNIXes and Win32.
OpenCM Good. Portable across all UNIX systems.
Perforce Excellent. Runs on UNIX, Mac OS, BeOS and Windows.
PureCM Good. Server and gui run on Windows. Command line also runs on UNIX and Mac OS.
Subversion Excellent. Clients and Servers work on UNIX, Windows and Mac OS X.
Superversion Excellent. Clients and servers work on any Java 1.4-compatible platform. There is official support for Windows, Linux and OS/2.
svk Good. Clients requires subversion and its perl bindings.
Vesta Good. It should be portable to any UNIX system. Currently it runs on Digital/Compaq/HP Tru64 UNIX and Linux on several different CPU architectures. Ports to Solaris and FreeBSD are planned but haven‘t begun yet.
Visual SourceSafe The Microsoft Product is Windows only.MainSoft ships a version of it for some UNIX platforms.
User Interfaces
Web Interface
Does the system have a WWW-based interface that can be used to browse the tree and the various revisions of the files, perform arbitrary diffs, etc?
CVS Yes.CVSweb,ViewVC,Chora, andwwCVS.
Aegis Yes.
Arch There‘sViewARCH, andArchZoom which are works in progress.
BitKeeper Yes. Its own built-in web-interface.
ClearCase Yes. Web views are supported.
CMSynergy Possibly.
Co-Op Since this functionality is always available locally, there is no need for web interface.
Darcsdarcs.cgi is included in the distribution.
Mercurial Yes. The web interface is a bundled component.
Monotone No.
OpenCM No.
Perforce Yes, P4Web.
PureCM No.
Subversion Yes.ViewVC,SVN::Web,WebSVN,ViewSVN,mod_svn_view,Chora,Trac,SVN::RaWeb::Light,SVN Browser,Insurrection andperl_svn. Aside from that, the Subversion Apache service provides a rudimentary web-interface.
Superversion No.
svk Yes. Same as Subversion.
Vesta Yes:Vestaweb.
Visual SourceSafe It is possible to code one using the API, but no official or third-party one exists.
Availability of Graphical User-Interfaces.
What is the availability of graphical user-interfaces for the system? How many GUI clients are present for it?
CVS Very good. There are many available GUIs: WinCVS, Cervisia (for KDE), TortoiseCVS (Windows Explorer plug-in).
Aegis There is tkaegis.
Arch There aretlator,Octopy, andArchWay and possibly others under development.
BitKeeper Good. BitKeeper ships with several GUIs for performing common tasks. I‘m not aware of any third-part GUIs.
ClearCase Supplied for both Windows and UNIX. GUI tools are typically not as solid as the command-line tools though.
CMSynergy A couple of GUIs. A motif-based one (even on Windows) allows most functionality but is clunky. A nicer Java one allows developer work but not much administrative stuff. Has an SCCI plug-in, though it doesn‘t handle network problems well.
Co-Op The system is GUI-based by design.
Darcs None to speak of. (There is a modest graphical interface to a few commands in the distribution, but it is not being developed currently.)
Mercurial History viewing available with hgit extension; check-in extension (hgct) makes committing easier. Some third-party IDEs and GUI tools (e.g. eric3, meld) have integrated Mercurial support.
Monotone No GUIs are available.
OpenCM No GUIs are available.
Perforce Yes, P4Win and others based on the available libp4 library.
PureCM Windows has a very user friendly gui.
Subversion Very good. There are many available GUIs: RapidSVN (cross-platform), TortoiseSVN (Windows Explorer plug-in), Jsvn (Java), etc. Most of them are still under development.
Superversion A GUI is integrated.
svk No GUIs are available.
Vesta No GUIs are available, but the repository has a C++ API, and it is not hard to write one. (At least three different project-specific ones have been written by users at Compaq and Intel.)
Visual SourceSafe Standalone GUI comes with it, plus SCCI plug-in for MS Visual Developer Studio. There is an Eclipse plug-in.
License
What are the licensing terms for the software?
CVS GNU GPL (open source)
Aegis GNU GPL (open source)
Arch GNU GPL (open source)
BitKeeper Proprietary, binary only license. Pay per use license, with an option for a costless license for developers of open-source software. Used to have a gratis, downloadable license, which was intended for the develpoment of open source software. It hada problematic license, and was discontinued starting at April 2005.
ClearCase Proprietary, with floating license supported. License server contacted for each clearcase operation, which obtains a license to be used for the next 30-60 mins. Prices are several $k per license plus yearly maintenance fee. Typically 1-3 users per license required, depending on activity. Multisite requires additional licensing.
CMSynergy Prices negotiable with salesman. Server is typically roughly 20,000 British Pounds. Clients are 4,000 British Pounds. Per-year costs of 18% of original.
Co-Op Proprietary, short text key. 30-day full-featured trial. Free to "observers" (members who don‘t make changes). $159 per workstation.
Darcs GNU GPL (open source)
Mercurial GNU GPL (open source)
Monotone GNU GPL (open source)
OpenCM GNU GPL (open source), but moving soon to BSD or CPL (also open source).
Perforce A proprietary, binary only, commercial license.Price starting at $800 per seat for the first year and then $160 for continuing support for the subsequent years. Free for Open Source projects (no support in this case).
PureCM A proprietary, binary only, commercial license.Price starting at $600 for 5 users
Subversion Apache/BSD-style license. (open-source)
Superversion GNU GPL (open-source)
svk Perl License. (open source)
Vesta GNU LGPL (open source)
Visual SourceSafe VSS Ships with MSDN, and can also be purchased standalone or with other tools.