Version-Control Systems for Linux

(sometimes called Source-code management = SCM or revision-control systems = RCS)

Last updated: Sun Jan 6 01:50:25 PST 2008

This listing of Linux SCM tools concentrates on SCM as a category distinct from project management, process management, workflow management, build control, release management, trouble ticketing, CASE, and other useful but adjoining functions. I'll try to mention where such extended features are present.

Pointers ([notable]) highlight entries notable in the opinion of this page's maintainer (Rick Moen, rick@linuxmafia.com), to whom complaints^Wcomments can be sent.

Bias & Other Disclaimers:





Contents





AccuRev (AccuRev, Inc.) (link)

AccuRev is a client-server networked, transaction-based system. Automatically versions directories. Provides changeset/transaction-oriented (as opposed to file-based) pre and post triggers that can run on both the client and the server. AccuRev, Inc. (formerly Ede Development Enterprises) is coy about pricing, but in 1999 it was US $750 for a single licence, including a year of support and updates.

Binary-only. Proprietary.



Aegis (link)

Aegis is Peter Miller's transaction-based software configuration management system that enforces a development process requiring that change sets "work" before integration into the project baseline. It calls make and RCS (or similar) for software-building and repository functions. Aegis is local-oriented (non-network-aware).

Very mature. Atomic commits. Supports renames. Poor Win32 support. Heavy security focus and well-developed process integration.

Code is C. Open source (GNU GPL).



AllFusion Harvest Change Manager (Computer Associates, Inc.) (link)

AllFusion Harvest (formerly CCC/Harvest aka Change and Configuration Control/Harvest, which was published by Platinum Technology International, Inc.) is a multi-platform networked SCM that integrates with an optional build system and provides integrated problem tracking.

Binary-only. Proprietary.



Arch (link)

Arch is an advanced SCM specification with multiple, independent but compatible implementations, and several descendants/offshoots. Arch is widely considered more ambitious than Subversion, mainly on account of its support for decentralised repositories: In Arch, any branch or developer's private work area can be treated as a repository of its own, with a global name space for developers, repositories, and branches, which you then periodically merge with a central repository.

Please see also the individual entries for the several implementations and offshoots of this specification: ArX, Barch, Bazaar 1.x, Bazaar, Eva, GNU Arch/tla, Larch.

All the various Arch implementations used to be linked from Mat Kovach's Arch Wiki (formerly Michael Grubb's) — but recently (2005-04) the wiki seems to have dropped all but GNU Arch/tla and Bazaar 1.x.



[notable]ArX (link)

ArX is Walter Landry's (no longer data-compatible) 2003 C++ reimplementation of the decentralised, networked Arch SCM specification, originally inspired in part by dissatisfaction with poor portability and other problems in Tom Lord's original shell-script-based Larch implementation. As an Arch offshoot, ArX is based on tracking deltas (changesets). Archives, patches, and revisions are cryptographically signed using gnupg signatures and SHA-256 hashes. ArX can use ftp, ssh, sftp, http, and http w/WebDAV transport. Internationalised but not localised. Centralised development can be done via a patch queue. Program ports to MacOS X, and in an "embryonic" fashion (2005-01-23) to Win32 (via Cygwin). On Linux, note (large) dependency on gnome-vfs. Beta as of 2005-04. Possibly moribund (2008).

Code is C++. Open Source (GNU GPL).



Archipel (link)

A prototype distributed system coded on Python by "Sébastien". Repository is stored in a queryable RDF database. Extensible/modifiable using plug-in delta modules for different versioning models. Version information is stored as SHA-1 hashes.

It is unclear at this point (2005-04) whether this software is publicly available in any form, let alone open source.



Barch (link)

Barch (for "binary arch" — now defunct) was Robert Collins's (early) attempt at a compatible C++ implementation of the Arch SCM specification — inspired in part by the need to transcend technical and portability limitations in Tom Lord's then-current shell-script-based implementation, Larch. The project appears to have stalled as of Collins's 0.0.6-DEVEL code released on 2002-12-29. However, more recently, Collins created Bazaar 1.x (now defunct).

Code is C++. Open source (GNU GPL).



Bazaar 1.x (baz) (link)

Bazaar 1.x (executable name "baz") was Robert Collins's fork for Canonical, Ltd. of Tom Lord's GNU Arch ("tla") C-language implementation of the Arch SCM specification.

It aimed to combine the essential features of GNU Arch ("tla") with user interface improvements and Win32 support: Subversion-like diff, switch, import, export, and log commands. A single merge command allowed merging between arbitrary branches, daily builds, internationalisation, Python bindings, Win32 binaries and an MS-Windows GUI, an annotate/blame/praise command, comprehensive documentation, and UI simplification. History was stored separately from the working directory.

As of 2005-08, Canonical decided to de-emphasise work on Bazaar 1.x, put that codebase in maintenance mode, and concentrate on Bazaar ("bzr"), formerly Bazaar 2, as the true long-term successor for GNU Arch/tla. Then, some time during 2006, Bazaar 1.x was discontinued entirely.

Code is C. Open source (GNU GPL).



[notable]Bazaar (bzr) (link)

Bazaar (executable name "bzr"), initially called Bazaar-NG, later called Bazaar 2, is Martin Pool's networked, fully distributed, changeset-oriented variant implementation / offshoot, coded in Python for Canonical, Ltd., based on the Arch SCM specification.

It aims to combine the best feature of all the new SCMs (darcs, Subversion, GNU Arch/tla, Quilt, and BK/Pro) "into a single coherent and simple system", and has a simple CVS-like syntax for common operations like add, mv, diff, status, commit, log, merge, etc. Stores/checks SHA-1 hashes of all patches and hashes of the tree state in each revision. Hashes can optionally be signed. Stores changesets (deltas). Control files are stored inside the working directory tree. Changesets can be sent/received over e-mail, optionally gnupg-signed. Renames, deletions, binaries are versioned. Uses hashes for integrity checks, not for identity. Repository data are stored encoded in UTF-8. Partial trees and per-file histories are not supported.

Though there is no dedicated network server program module, there is built-in support for "pull" synchronisation over a variety of network mechanisms; by default, there is both "push" and "pull" support over sftp transport only, and sftp is supported only if you install the bzrtools extensions (plus Python modules paramiko and pyCrypto).

Bazaar is also the successor to the former Bazaar 1.x ("baz") project, and all baz repositories should by now (2006) have been converted.

Change history is append-only. Tool lets you "cherry-pick" changes from one branch to another. As a further advance on Bazaar 1.x, each checkout is fully usable as a repository. At this date (2005-04), bzr is not yet feature-complete. Modular design: library + command-line client, making feasible use via library call from any other client. All development takes place on branches, which are the highest-level grouping. Forking of branches is by intention frequent and has been made easy. Three-way merge algorithm. Allows merges within an arbitrary graph. History-sensitive merges allow safe repeated merges, merges across renames, and mutual merges between parallel lines. Checkouts default to the last archive you pulled from (as with darcs and BK/Pro).

Bazaar (v. 0.7) was one of three SCMs seriously considered for hosting the very large OpenSolaris Project, and was eliminated on grounds of slowness and high memory usage compared to git and (the winner) Mercurial.

Trent Buck published a comparison of darcs and Bazaar (bzr) in 2006.

Code is Python script: Tool should run anywhere that Python 2.4 and above runs (i.e., Unixes including MacOS X, Win32, etc.). Open source (GNU GPL).



[notable]BK/Pro, formerly BitKeeper (BitMover, Inc.) (link)

Networked, changeset-oriented system (executable name "bk"). Atomic commits. Supports renames. Supports file/directory copies that retain version history. Has some advanced merge methods, based on line identity. Uses time, rather than sequence, in some places. Repository, which uses weave storage, gets fully replicated onto each developer's system (multiple repositories / staging areas). History is stored with the working directory. Checked-out files must be marked before editing. Patches from others can retain their separate identity even after integration (are not collapsed/rolled up). Has default GUI. Emits lots of noise messages, and has lots of weird commands. Requires both per-file and per-changeset commands. Very space-efficient storage. Has fine-grained pre- and post-event triggers. Can remotely find status of a tree, e.g. parent, number of comitters, versioned files, extras, modified, etc. Binary-only in recent versions. Was used by the majority of core Linux kernel developers until 2005-04, although some declined for licensing and other reasons. See: analysis of architectural advantages over competitors.

[Maintainer's personal comment: The obvious comparison to BK/Pro is IBM / Rational's very high-priced ClearCase tool, which I've used in the software industry. Having tried BitKeeper for a bit, I found it technically superior in every way — and it's dramatically cheaper. (On the other hand, 2005 has seen the rise of the remarkable, fast, stable open-source SCM "Mercurial", which should certainly be considered strongly, having much the same strengths except paid technical handholding.)

This document's entry for BK/Pro / BitKeeper initially had several mis-statements of fact, unflattering to the company, that I'd picked up by repeating uncritically some Linux developers' on-line assertions. I regret those errors, and caution people to be skeptical of such claims.]



Bitsafe (Bitmanager-Media GmbH) (link)

Bitsafe is a networked SCM coded in Java (JRE/JDK in version 1.4.2 or later required) and back-ended into either Oracle RDBMS or SAP-DB for its repository.

Code is Java bytecode. Proprietary.



/BriefCase 3 Toolkit (Applied Computer Sciences, Inc.) (link)

/BriefCase 3 Toolkit is ACSi's enhanced networked variant on RCS wrapped inside a comprehensive development, release, and lifecycle toolkit. Network access is via rsh transport for coordination of client and server-side scripts, and NFS & pipes for data transport. NFS support has a well-developed locking structure. Administrative and private user tag mechanisms are provided. Client-side work areas can have multiple local replicas, to work on different releases and/or aspects of a project. Import tools are provided for SCCS, CVS, RCS and PVCS data.

Code is Korn shell and awk scripts. Open source (GNU GPL).



CBE (link)

CBE (Code Building Environment) is Thomas Neumann's SCM coded in pure Java with integrated software build functions. Functionality is roughly similar to that of CVS with some new features like renaming files (while still keeping the history) and using a database as backend (optional). Code is said to be alpha-stage (2005-04).

Code is Java. Open source (GNU GPL).



ChangeMan DS (Serena Software, Inc.) (link)

ChangeMan DS is a networked SCM integrated with build control, release management, a programmers' editor, software-distribution tools, and process control. It also integrates with SAP for packaged application management, and with various third-party IDEs. Serena Software is coy about pricing.

The product was formerly known as ChangeMan and before that as Diamond CM — because it was written by Diamond Optimum Systems, which was acquired by Serena Software. (Even earlier, during its origins as an HP-3000 / HP/UX tool, it was called VCS-UX.)

Binary-only. Proprietary.



ClearCase (IBM / Rational Software, Inc.) (link)

ClearCase is a networked SCM whose repository one accesses using a quasi-filesystem of its own design, with integration to external software-build tools and adding some of its own. Supports advanced 3-way merge, versioning of any object (including directories), parallel builds distributed over a network, and triggers for local site customising. Linux usage requires loading a proprietary kernel module, said to freeze up frequently (at least that was true around 2001, not confirmed recently), and compatible only with particular kernels: See the ClearCase Linux Installation Guide Whitepaper for compatibility details.

They're extremely coy about pricing; probably you have to haggle on site-wide terms with their sales team. One claim is that ClearCase licenses tend to cost around US $5000/seat plus 20% per year for support.

ClearCase's history goes back to 1984, when a team at Apollo Computer created DSEE (Domain Software Engineering Environment), an SCM/build system. At the time of HP's purchase of Apollo, they left and formed Atria Software, which then merged with Pure Software, to form PureAtria, which was then bought by Rational Software. In 2002-12, Rational Software was bought by IBM Corp.

Binary-only. Proprietary.



CM+ (Neuma Technology, Inc.) (link)

CM+ integrates networked SCM with process control, build control, configuration management, product management, document management, problem tracking, activity tracking, requirements tracking, and release control. Neuma Technology is coy about pricing.

Binary-only. Proprietary.



CMZ (CodeME S.A.R.L.) (link)

CMZ is a local-oriented (non-network-aware) system, supporting a wide range of SCM, coding, editing, and library-management functions. Linux binary is PPC-only (no x86).

Binary-only. Gratis non-commercial usage. Proprietary.



[notable]Codeville (link)

Codeville (executable name "cdv") is Bram and Ross Cohen's fully decentralised (networked) SCM with some advanced merge methods, based on line identity: two-way merge with history. (It allows you to update from or commit to any repository at any time, with no unnecessary re-merges. Supports offline commits: Supports a workflow model where the repository is centralized, but the working tree is used as a branch.)

Repository is stored in a binary BerkeleyDB database. History is stored in the form of changes from old hashed versions. Support for non-ASCII files and some metadata (e.g., execute bit) are still (2005-08) pending. SRP as authentication protocol, network access via (if I understand correctly) custom, built-in network transport to the "cdvserver" piece on TCP port 6601. File and directory renaming are supported. Code is now (2005-08) solid, with a small to-do list remaining. Still has nearly nil built-in documentation, and only a little more on the project Web site. Very well-designed but very unusual merge algorithm (aforementioned two-way merge with history).

Code is Python script (Python 2.3 and up, BerkeleyDB 4.1 and up). Open source (newer BSD licence).



Control-CS (Network Concepts, Inc.) (link)

Control-CS is a networked version-management system. (Earlier version was called Control.) Linux has server-end tool only; client-end software exists only for Win32.

Binary-only. Proprietary.



cscvs (1, 2) (link)

cscvs (now defunct) was a networked, decentralised SCM coded in Python, using CVS as a back-end storage repository, imposing on top of CVS atomic changeset semantics (and with easy migration to arch).

Code is Python script. Open source (BSD-style licence).



CSSC (Free Software Foundation) (link)

CSSC (Compatibly Stupid Source Control) is a simple local-oriented (non-network-aware) reimplementation of the old SCCS (Source Code Control System) system from early Unix (pre-RCS), mostly used for access to old repositories (being not recommended for new data repositories), and (for a while but reportedly not any more), with minor modification, to BitKeeper repositories. Uses weave storage, which makes it an excellent foundation for building advanced SCMs, despite CSSC/SCCS's antiquity. Fast, small, lightweight. Versions files (no changesets). Doesn't handle binary files. Does locking, uses a centralised (local) repository. No merging. Confusing command-line interface.

Code is C. Open source (GNU GPL).



CVS (link)

CVS (Concurrent Versions System) is the ubiquitous old-school default, but has serious flaws: No moves/renames, inefficient with binaries, no versioning of directories, no merge-history tracking (must be done manually through tagging), no atomic commits or retrievals (i.e., no atomic tree-wide operations), interacts badly with backup software, tends to leave stale locks, doesn't deal well with symlinks/special files, often gets into merging snarls, branching is often problematic and requires scrupulous attention to tagging, changes are tracked per-file instead of per-change, development is stagnant. Tagging and branching are expensive operations. No integrity checking: Prone to repository corruption. Derived from script wrappers by Prof. Dick Grune of the Free University of Amsterdam around the local-only RCS system (written in 1984-5 and rewritten in C two years later by Brian Berliner), it added concurrency control, annotations, and other enhancements. History is stored separately from the working directory (in the central repository), and can contain many modules. Working copies are separate and contain one module each. Able to transact data across network connections since 1994, making CVS the first practical network-capable SCM. Existing project history can be revised, but only through special mechanisms. Syncing of repositories is possible using add-on software CVSup.

Code is C. Open source (GNU GPL).

Maintainer's note: If you still use this thing, for heaven's sake upgrade to Subversion, or at least CVSNT.



CVSNT (link)

CVSNT started out to be an NT-only variant of CVS, but is now fully portable. It adds merge tracking, SSPI authentication, and a built-in copy of the PuTTY SSH code. Has per-branch ACLs, remote user administration using "cvs passwd" commands, a separate LockServer instead of filesystem-based locks, Unicode support, more-efficient storage of binary diffs, atomic checkouts, better handling of merges without tagging requirements, additional server triggers, etc. However, it retains many of CVS's disadvantages, including poor handling of renames, etc.

Code is C. Open source (GNU GPL).



[notable]darcs (link)

DARCS (David's Advanced Revision Control System), more often called "darcs", is David Roundy's CVS-replacement SCM, written in Haskell, handling all metadata, supporting fully decentralised repositories and advanced branching / patch-handling: Distributed merge is implemented via patch commutation. History is stored with the working directory. (Control files are stored inside the working directory tree.) Atomic commits. Supports renames. Existing project history can be revised (which is potentially a drawback: Interlopers can change what the history says). Patches from others can retain their separate identity even after integration (are not collapsed/rolled up) — and darcs also has the so-far unique advantage of being able to track inter-patch dependencies, and thus is the canonical example (and, really, the pioneer) of the concept of "cherry-picking" of patches and groups thereof. Based on tracking changesets (deltas). Fully functional (but slower) Win32 port; also works on MacOS X. Attempts to do all work entirely in RAM. Simple to use; easy to learn. Mature tool with active user community. No crypto checksum on the tree; no crypto signatures except on the transport. Does not guarantee than any past revision can be reproduced. Can be extremely slow when resolving merge conflicts.

The Haskell language is a rather obscure functional language, known to but few, and additionally is reported to characteristically suffer unpredictable but sometimes severe performance problems. Because of the language's obscurity, there have been relatively few third-party contributions to the codebase.

darcs also suffers from impenetrable, poorly designed error messages and diagnostics. Each repository can only hold a single branch of a single project: To create a new branch, you must create an entirely new repository.

As of 2005-08, darcs's development branch is now alternatively able to work with git repositories.

David A. Wheeler's 2004-03 SCM essay includes a brief description, and some thoughtful analysis, on darcs.

Trent Buck published a comparison of darcs and Bazaar (bzr) and some comments on darcs kludges in 2006.

Code is Haskell. Open source (GNU GPL).



DCVS (Distributed Concurrent Versions System) (elego Software Solutions GmbH) (link)

DCVS extends the CVS model, adding support for distributed repositories and local lines of development, using a variant of John D. Polstra's file distribution and synchronization program CVSup.

Code is C. Open source (GNU GPL).



Discipline 4GL (Saint Mavris Technology) (link)

Discipline 4GL is a networked SCM, software-development, build control, and release-control tool. Saint Mavris Technology is coy about pricing.

Binary-only. Proprietary.



Eva (link)

Eva (now defunct) was Federico Di Gregorio's compatible Python implementation of the decentralised, networked Arch SCM specification — inspired in part by the need to transcend technical and portability limitations in Tom Lord's then-current shell-script-based implementation, Larch. The project appears to have stalled as of Di Gregorio's 2003-04-13 snapshot code.

Code is Python script. Open source (GNU GPL).



FastCST (link)

FastCST (Fast Change Set Tool) is Zed Shaw's experimental, distributed, networked SCM, [re-]coded in Ruby, from Shaw's C original. (The Ruby version still lacks the original's revision control and encryption features, as of 2005-04.) Supports sending and receiving changesets via POP3 + SMTP; also works over http, http+ftp, or a built-in "serve" command (http access on port 3040). Merge command is (a/o 2005-04) only partially working: Basic merge is implemented, but without conflict resolution.

Code is Ruby. Open source (GNU GPL).



[notable] git / Cogito and kin: (link)



GNU Arch 1.x ("tla") (link)

GNU Arch 1.x (executable name "tla", for Tom Lord's Arch) is Tom Lord's second (compatible) implementation, this time in C, of his decentralised, networked Arch SCM specification. It is now (2006) maintained by Andy Tai. Very complex, arguably overfeatured system. Does star-merge. Patches from others can be collapsed/rolled up upon integration so as to lose their separate identities. Atomic commits. Supports renames. Commits are gnupg-signed. Parseable/scriptable shell interface; uses tar, gzip, and patch. Changelogs are autogenerated. Uses weird, often problematic filenames featuring (e.g.) leading "++", ",,", "=", and "{ ... }" sequences. Uses inode signatures to detect file modifications, leading to some false alarms, e.g., when copying a tree. Uses MD5 hashing (insecure) for archive verification; will eventually move to SHA-1: Only patches (not complete revisions) are signed. Uses sequence, rather than time, to determine precedence of changes. Can use ftp, sftp, WebDAV, and plain http transport. Relies on ssh for remote access, authentication, and confidentiality. Changesets can be also conveyed via e-mail. A dedicated arch-server component isn't really needed, but has been prototyped, or alternatively one could use Colin Walters's Python-based archd software and matching protocol (using TCP port 2420).

Interested parties will find Nick Moffitt's concise and focussed "Arch for CVS Users" tutorial an excellent place to start.

David A. Wheeler's SCM essay points out some of GNU Arch's current (2004-03) problems: (1) The Win32 port is currently missing quite a few features (symlinks, most file permissions, correct handling of newlines), and in general GNU Arch may never be fully functional on non-POSIX systems. (2) The repository's file-naming conventions use very badly chosen special characters that tend to break vi, more, the C shell, various scripting languages, and other primary tools. (3) Automated cache management is missing (making the program slow by default), and is badly needed. (4) Merging breaks if branches aren't either all commit-based or all tag-based, but the tool doesn't enforce that limitation. (5) "mv" and "move" do very different things, and in general the full command set is needlessly complex.

Wheeler considered almost all of these to be short-term problems.

Lord had released, working entirely by himself, three development betas of a GNU Arch 2.0 redesign (executable name "revc") incorporating ideas from Bazaar ("bzr"), git, and Monotone, including a belated switch from MD5 to SHA-1 checksums. However, my guess is that the 2.0 effort (at minimum) is now (2005-08) defunct.

The GNU Project adopted tla as "GNU Arch" in 2003-07.

Code is C. Open source (GNU GPL).

Maintainer's personal note: In my opinion, GNU Arch's implementation flaws are sufficiently grievous that people considering its use should hasten to substitute Canonical's compatible replacement, Bazaar ("bzr"), in its place.

It appears that I'm not alone in this perception: As of 2005-08-15, Tom Lord announced that he was resigning effective immediately as GNU Arch maintainer, endorsed Bazaar 1.x ("baz") as an immediate direct replacement, and expressed hope that Bazaar ("bzr") will eventually take its place, in turn. The main GNU Arch developers other than Lord had already left that project, by that point, and had become Bazaar 1.x coders.

2005-10 update: Developer Andy Tai has taken over the GNU Arch project lead, and it has resumed.



JRMS (link)

Java Revision Control System was a project for a lightweight Java non-changeset-oriented SCM that was to run over Java RMI (remote method invocation), abandoned by its author while still in late planning stages when he discovered Subversion.

Code is Java. Open source (GNU GPL).



Katie (link)

Katie (defunct) was a local-oriented (non-network-aware) system, where the repository is mounted as a filesystem, as with ClearCase. Abandoned in pre-alpha state.

Code is Perl script. Open source (GNU GPL).



Larch (link)

Larch (now defunct) was Tom Lord's initial "functional prototype" implementation of the fully decentralised, networked Arch SCM specification. It was initially named "arch", but was then renamed to Larch because of a naming conflict. (/bin/arch on a POSIX system returns its machine architecture type.) Larch's reliance on shell scripts caused it to be often pronounced less portable than alternatives. Could function over ftp, sftp, WebDAV, and plain http transport. Replaced by C-based GNU Arch/tla and numerous competitors inspired in part by Larch's drawbacks.

Code is shell scripts. Open source (GNU GPL).



[notable]Mercurial (link)

Mercurial (executable name "hg"), by Matt Mackall, is a distributed SCM inspired by certain of Monotone's design elements, and said to be similar in some ways to git/Cogito, but storing changes instead of whole files, saving storage and making some functions related to file history easier to perform. Very compressed storage, as a result. Note: Mercurial stores only one project per repository, but allows multiple branches within a repository. Control files are stored inside the working directory tree.

Uses SHA-1 hashes of changesets for integrity-checking, supports fully decentralised operation and arbitrary merging. Merging keeps all metadata on each changeset (committer, message, etc.). Everything is a branch. Provides command-line and Web interfaces. Uses http and ssh as network transport. Can also use e-mail as transport ("hg export" to export changesets, mail the changesets, then "hg import"). Changeset numbers are referred to by sequential numbers. "hg serve" starts a built-in Web server, and serves up the branch for "pull" access.

Renames, deletes, and permissions are versioned, but rename is implemented as copy and delete. (Fortunately, a file created with the same path as one deleted inherits the old file's history.) No support for partial trees. Per-file history is available by specifying the filename with "hg log". No direct support for "cherry-picking": However, an equivalent can be achieved by exporting specific patches from one repo (branch), and importing them into another repo.

Repositories are normally fully independent, but can be configured to have a de facto parent. Network access is supported via SSH, http (in "pull" mode) and of course network filesystems. There is no built-in facility for controlling access (via ACLs) to subtrees. Repository internal storage format is binary (hence, fast) but platform-neutral.

Offering repo access via plain http ("pull") access from commodity Web servers (a very desirable feature) is complicated (2005-09) by the fact that the "preferred method" for publishing such a repo requires uploaders to continually first create "bundles" to hold the contents, and for downloaders to know that things are bundled, and (apparently) even to know what the bundles are named.

Mercurial was one of three SCMs seriously considered (1, 2) for hosting the very large OpenSolaris Project, and was the final winner over git and Bazaar.

Code is a small Python script, and is fully cross-platform. Open source (GNU GPL).



Meta-CVS (link)

Meta-CVS (now defunct), by Kaz Kylheku, is an ambitious attempt to update CVS by embedding the standard CVS client in Lisp wrappers, which cause an enhanced data representation to be stored in the CVS repository. Adds directory versioning, renames/moves, support for symlinks and file metadata, simpler branching and merging, persistent memory of each file type being declared (and to be treated as) binary or text after it's been imported or added the first time. Commits are not atomic; the author's algorithm for atomic commits has been proposed but not yet adopted for both CVS and Meta-CVS.

Code is Lisp. Open source (GNU GPL).



[notable]Monotone (link)

Monotone (executable name "mtn") is Graydon Hoare's 2003 distributed (networked) SCM with a flat peer model, cryptographic (SHA-1) version naming and metadata certificates (SHA-1 identification of all files, directories and revisions), decentralized authority, atomic commits, versioned file and directory renames (unlike, say, Mercurial), and overlapping branches. Supports file/directory copies that retain version history. Distributed merging is implemented via 3-way merge. Tracks changesets (deltas). Identifies revisions using chained hashes, requiring only one signature to authenticate a line of development. Uses rename history instead of file-IDs to determine file identity. Monotone works out of a transactional version database stored in a regular file (using sqlite). Network communication is mediated via HTTP, netnews (NNTP), or SMTP transport. Code is C++ and Lua. Mechanisms such as cryptographic hashing are too exposed for many people's tastes. Nice graph tool. Good manual and Web pages. Project is now self-hosting, and while still being experimental now (2005-05) has a stable database schema and a reliable datastore.

Note: One of the reasons Linus Torvalds started the "git" project is that he tried Monotone, and liked many of its aspects, but found it unacceptably slow at the time (but not as slow as darcs). Monotone has gained performance considerably since that time, when the designer had not yet found and fixed a serious performance bug. It is reported (2005-08) that the "initial pull" initial repository clone still takes quite a long time, but that this is being worked on. (2008 update: That has now been addressed.)

David A. Wheeler's 2004-03 SCM essay includes a brief rundown on Monotone.

Tool works on Unixes including MacOS X, plus Win32. Beta as of 2005-04.

Code is Lua and C. Open source (GNU GPL).



OpenCM (link)

OpenCM (now defunct), by Jonathan Shapiro, was another intended CVS-replacement, supporting renames, access control on branches, cryptographic authentication (SHA-1 hashes), atomic commits, end-to-end integrity controls, and file-level ACLs. Directories are inferred by having files that exist under them; empty directories are a special case with an object of type DIR. It was still in early development when the project (apparently) stalled a/o 2004-10-24.

Code is C. Open source (2-clause BSD licence with some GNU GPL; aiming to move to Common Public Licence).



OurayCM (Ouray Software L.L.C.) (link)

OurayCM is a networked SCM supporting renames, branching including per-user branching with automatic merge tracking, built-in cache servers, tools to assist conflict resolution, and atomic commit operations. GUI and command-line tools are provided for the various platforms. The release-tagging feature is called "vrefs".

Binary-only. Proprietary.



Perforce (Perforce Software, Inc.) (link)

Perforce is a networked SCM with emphasis on high performance, using RCS files plus a database. Supports versioning of most objects (but notably not directories), change control, shared access, atomic commits, branching/merging, and auditing for software production teams. Renames not directly supported: you copy and then delete but it manages to keep track of the branch. Supports file/directory copies that retain version history. Costs US $750 for a single licence. Quantity discounts, and gratis licences to open-source developers upon request.

Binary-only. Proprietary.



PRCS (link)

PRCS (now defunct) was a promising project (particularly the 2.x development branch) that had been progressing slowly; source code tree is in anoncvs.gnome.org . Unfortunately, there has been no sign of progress towards release since 2001. It handled files and directories as an entity, preserving coherent versions of the entire set. Had named branches, custom keyword replacement. Best-parent three-way merge algorithm. Users were allowed to edit the manifest file, which also contains some system-maintained data. No network support; no Win32 or Mac support.

Code was C++. Open source (GNU GPL).



PVCS (Synergex International Corp., under licence from Merant, Inc.) (link)

PVCS is a local-oriented (non-network-aware) SCM and build-control system with client software for just about all OSes. Merant, which wrote the code, was formed by the merger of MicroFocus and Intersolv.

Binary-only. Proprietary.



QEF (QEF, Inc., formerly QEF Advanced Software, Inc.) (link)

QEF is a complete software-management/build system that includes a wrapper to use third-party SCMs such as RCS, SCCS, and CVS. (It is often listed as an SCM, but technically includes no SCM component of its own.)

Binary-only. Proprietary.



Razor (Visible Systems Corporation) (link)

Razor (developed by Tower Concepts, Inc., which was acquired in 1998-12 by Visible Systems Corporation) offers SCM integrated with trouble-ticketing and project and release management. The Linux version appears to work only on 2.0 and 2.2 kernels. Visible Systems is trying to extend this into a comprehensive IDE. Concurrent licences are available in blocks of 5 for US $3,700, with quantity discounts, and optional annual maintenance contracts (with upgrades) are about 15% additional.

Binary-only. Proprietary.



RCE (DuraSoft GmbH) (link)

RCE (Revision Control Engine) is a local-oriented (non-network-aware) SCM, designed to improve on RCS, with an optional graphical front-end (Visual RCE), created by Walter F. Tichy, creator of RCS. Supports any data format, parallel development, automatic history. There is a Java-based GUI front-end.

Binary-only. Proprietary.



RCS (1, 2) (Free Software Foundation) (link)

RCS (Revision Control System), originally written by Walter F. Tichy at Purdue University in the early 1980s, is a simple local-oriented (non-network-aware) SCM, often considered somewhat more advanced than CSSC/SCCS, and yet (as it turns out) much less useful as the foundation of an advanced system. Implements locking and a centralised (local) repository. Supports tags, and symbolic names for revisions. Supports versioning of binary files if you're careful to disable keyword expansion. Has a (primitive) merge function. History (implemented as a series of deltas backwards from the tip version of each file handled) is stored in the working directory.

Code is C. Open source (GNU GPL).



Sablime (Lucent Technologies, Inc.) (link)

Sablime appears to be a well-rounded networked system. Lucent Technologies is coy about pricing. Predecessor codebase: AT&T's internal CMS & ECMS SCM systems. Lucent Technologies was formerly AT&T Software Solutions.

Binary-only. Proprietary.



SCCS (link)

SCCS (Source Code Control System) is the oldest SCM, a local-oriented (non-network-aware) system developed in 1972 by Marc Rochkind at Bell Labs on an IBM System/370 running OS/MVT. It's the first change-management system to record a distinct identifier for each revision and keep a clear revision history. Version numbers are in format "major.minor". Uses weave storage, which makes it an excellent foundation for building advanced SCMs, despite SCCS's antiquity. Does locking, uses a central repository. Versions files (doesn't do changesets). Doesn't handle binary files. No merging. Confusing command-line interface.

Code is C. Open source (CDDL, GNU GPL, GNU LGPL).



SiVeCo (link)

SiVeCo (Simple Version Control) is Jens Wilhelm Wulf's basic SCM, designed for use by someone working alone on smaller projects. It is self-contained, but requires a filesystem supporting symbolic links (and therefore cannot run on Win32).

Code is C++. Open source (GNU GPL).



SnapshotCM (True Blue Software Company) (link)

SnapshotCM (formerly TrueCM) is a multi-platform, networked SCM with easy merging and branching, storing most files in RCS storage. Integrates with sundry IDE front-ends using Microsoft's SCC application interface.

Binary-only. Proprietary.



So6 (link)

So6 is a 100% Java networked SCM intended to be used as part of the LibreSource development environment, where diffs get checked in by various users into a message queue, which then generates an event and consequent messages to notify other users of their availability. Instead of branches, there are multiple message queues with which the user can elect to synchronise. Network access is mediated via Sun Java Web Start over generic http transport.

Code is Java. Open Source (QPL v. 1.0).



Source Integrity (Mortice Kern Systems, Inc.) (link)

MKS Source Integrity seems to be a local-oriented (non-network-aware) SCM designed to integrate with various MS-Windows IDEs and Mortice Kern Systems Inc.'s workflow management software. Does automatic merging, supports event triggers.

Binary-only. Proprietary.



SourceJammer (link)

SourceJammer is a 100% Java networked system with renames/moves, requiring Jakarta Tomcat or Apache / Resin, the proprietary Sun JDK / JavaBeans / JavaMail , Apache SOAP and Xerces. Does labels, but it's unclear from the docs whether it does branching. Said to be suitable for small-to-medium projects, in being simple and easy to understand.

Code is Java. Open source (GNU GPL and LGPL).



SourceOffSite Classic (SourceGear Corporation) (link)

SourceOffSite Classic is a networked tool for users of various operating systems to remotely use Microsoft Visual SourceSafe repositories. Linux client works on Linux 2.2.x kernels.

Binary-only. Proprietary.



StarTeam (Borland Software Corporation, formerly Starbase Corporation) (link)

StarTeam is a networked SCM with support for various MS-Windows IDEs via the Microsoft Source Code Control (SCC) application interface, and integrated defect tracking and threaded discussions. There's a Java-based Linux client piece.

Code is Java bytecode. Proprietary.



Stellation (link)

Stellation is an extensible system with project-oriented versioning and lightweight branching, which back-ends into common relational databases, such as PostgreSQL, Oracle, Firebird, and DB2 (with MySQL support in progress). It runs either standalone, or with an Eclipse plugin allowing it to be integrated into the Eclipse IDE. It fixes typical CVS problems, e.g., it handles moves and renames correctly, registers changes affecting multiple files as an atomic changeset, and maintains full project history through merges without manual measures.

Code is Java. Open source (Common Public Licence).



[notable]Subversion (link)

Subversion (aka SVN; executable name "svn") is specifically designed as a CVS replacement (developed starting 2000), fixing all of the long-known design flaws in CVS: It adds versioning of directories, intelligent handling of binary files, and handling of all file metadata including symlinks (missing: to be fixed post-1.0). Revision numbering is per-commit instead of per-file. Atomic commits. Supports file/directory copies that retain version history. The repository stores snapshots of works, not changesets (deltas). As with CVS, Subversion follows a centralised development model; this is not a distributed, decentralised SCM, though the SVK extensions adapt Subversion to create one. Designed-in network operations are over either WebDAV, or a lightweight custom protocol called svnserve, which runs on port 3690 and can be anonymous or authenticated by a svnserve-specific password file. Alternatively, svnserve can provide authentication through SSH. No history-sensitive merging (no merge history tracking) as in GNU Arch/tla: Trying to reapply a patch more than once can cause problems. Uses rename history instead of file-IDs to determine file identity. Existing project history can be revised, but only through special mechanisms. Original Subversion repository design used the BerkeleyDB database as a back-end store; in more recent versions, you can optionally use a filesystem/flatfile-based "fsfs" store if you prefer.

Despite ubiquitous claims to the contrary from its proponents and from the program's official features list, it has turned out (2005) that Subversion cannot handle file renames: Renames are implemented as deletion of the old file and separate copy to a new file, with the result that the file's version history gets broken. As Codeville's Bram Cohen points out, this "is even worse behavior than CVS has".

David A. Wheeler's 2004-03 SCM essay enumerates Subversion's virtues and limitations.

Code is C, with a fairly lengthy dependency tree. Open source (Apache Software Licence v. 1.1).



Superversion (link)

Superversion is Stefan Reich's networked, distributed, changeset-based SCM. Atomic commits. No rename support. Server access is mediated by Java RMI. GUIfied for all operations.

Code is Java: Program functions anywhere that Java does. Open source (GNU GPL).



Surround SCM (Seapine Software) (link)

Surround SCM is a multi-platform, networked SCM. Flexible branching model, with support for private branches. Integrates with sundry IDE front-ends using Microsoft's SCC application interface. Licences are US $600/user with quantity discounts.

Binary-only. Proprietary.



SVK (link)

SVK is a Perl-based, networked, (mostly) decentralised/disconnected SCM released by Chia-liang Kao in Sept. 2003, using the Subversion back-end storage repository but also adding distributed branches, lightweight checkout copy management, and more-advanced merging algorithms. Near future plans include cryptographic signing and verification of changesets, graphical merge manager, transparent VCP integration of alien-type SCM repositories (CVS, etc.) As of v. 8.08, 2004-02, SVK was described as being in "working prototype" stage; users are cautioned that all things are subject to change. As of 2005-04, it was still said to be a bit flaky, probably in part because the composite SVK/SVN system is fairly "heavyweight" (a tall software stack). Little documentation. Control files are not stored inside the working directory tree, similar to with Perforce. Requires CGI on server end. Fast. Good integration with external merge tools.

Code is Perl script. Open source (Perl Artistic Licence).



Synergy/CM (Telelogic AB) (link)

Telelogic Synergy/CM, (formerly CM Synergy, formerly Continuus/CM) appears to be a networked client-server system that back-ends into an SQL database (not included) and includes workgroup-management features. Atomic commits. Supports renames. Supports file/directory copies that retain version history. Telelogic (which acquired Continuus Software Corp., formerly CaseWare, Inc., formerly Amplify Control) is coy about pricing, but, in 2000-05, CM Synergy was US $25,000 for 10 users.

Binary-only. Proprietary.



TrueChange (McCabe & Associates) (link)

TrueChange is some sort of changeset-based SCM. Web site is vague: It seems respected, if obscure, and was formerly known as Aide-de-Camp. McCabe is very coy about pricing.

Binary-only. Proprietary.






VC/m (George James Software) (link)

VC/m appears to be a local-oriented (non-network-aware) SCM with process control. Most operations can be optionally performed from a Web browser.

Binary-only. Proprietary.



Vesta (link)

Vesta is a fairly robust configuration-control and software-building system developed by/for the Digital Equipment Corp. Alpha processor team, but does not yet include tools to implement merges. Atomic commits. Renames are supported: The unit of checkout/checkin is a directory tree. Files and directories can be added, deleted, and renamed between versions. Supports file/directory copies that retain version history: A new package/branch can be based on any existing version without affecting the past history.

David A. Wheeler's 2004-03 SCM essay includes a brief rundown on Vesta.

Code is C++. Open source (GNU LGPL).






More tools can be found at http://www.faqs.org/faqs/by-newsgroup/comp/comp.software.config-mgmt.html (comp.software.config-mgmt FAQ). I've attempted to include all options listed there that have a Linux presence.

Ross Cohen maintains the Revctrl Wiki, linking to the related Revctrl mailing list administered by Zooko (Bryce Wilson) and logs of the #revctrl IRC channel on freenode.net, all of which are the leading forums for discussion among developers of advanced open-source SCMs.

RCS Planet tracks the weblogs of SCM developers.

Version Control Blog houses Alexey Makhotkin's writings on the subject.

Further SCM information may be findable at the Open Directory CM category, Better SCM Initiative, including a comparison page, Zooko's (Bryce Wilson's) quick-reference comparison chart, CM Crossroads, INCOSE, Oy Laatukonsultointi P. Kantelinen Ab's SCM Tools page, Ovum, Ltd., or the comp.software.config-mgmt newsgroup.

See also David Wheeler's perceptive Comments on OSS/FS Software Configuration Management (SCM) Systems (updated once — maybe again?), Kevin Smith's blog's SCM category, and Bram Cohen's blog's SCM items (1, 2) and the OpenSolaris project's comparative SCM evaluations.

Also extremely worth reading is Martin Pool's essay, in which he compares and contrasts SCMs that capture snapshots (Subversion, CVS) with those that capture changesets (GNU Arch, darcs), and explains why the latter win as projects become more complex.