版本控制系统特色比较

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 259 2006-04-14 17:15:57Z shlomif $

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	No.
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-Ling Kao's SVN::Mirror add-on or Shlomi Fish' svn-push 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	Very poor at this moment.
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. WebCVS, ViewCVS, ,Chora and wwCVS.
Aegis	Yes.
Arch	There's ViewARCH, and ArchZoom 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.
Darcs	darcs.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. ViewCVS, SVN::Web, WebSVN, ViewSVN, mod_svn_view, Chora, Trac, SVN::RaWeb::Light, SVN Browser, Insurrection and perl_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 are tlator, Octopy, and ArchWay 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 had a 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.