The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. The software is released under an Apache/BSD-style open source license. See the status page for current progress. Our goals are:

• All current CVS features.

  CVS is good, as far as it goes, so we want to keep feature-compatibility: versioning, folding of non-conflicting changes, detection of conflicting changes, branching, merging, historical diffs, log messages, line-by-line history (cvs annotate), etc.

  Generally, Subversion's conceptual interface to a particular feature will be as similar to CVS's as possible, except where there's a compelling reason to do otherwise.

• Directories, renames, and file meta-data are versioned.

  Lack of these features is the most common complaint against CVS -- basically, CVS only versions file contents. Subversion will handle directory changes, file renames, and permission and other meta-data changes as well.

• Symbolic links, etc, are supported

  Subversion will handle symbolic links ("shortcuts"), multiple hard links, and other special file types as long as their semantics are compatible with version control.

• Commits are truly atomic.

  No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file.

• Branching and tagging are cheap (constant time) operations

  There is no reason for these operations to be expensive, so they aren't.

  Branches and tags will both be implemented in terms of an underlying "clone" operation. A clone is just an alias, optionally within the project's namespace, pointing at a specific revision of an existing project. An clone takes up a small, constant amount of space. All clones are tags; if you start committing on one, then it's a branch as well.

  (This does away with CVS's "branch-point tagging", by removing the artificial distinction that made branch-point tags necessary in the first place.)

• Repeated merges are handled gracefully

  Subversion will have a way of remembering what has been merged, so that repeated merges from the same source do not require careful human calculation to avoid spurious conflicts (anyone who's done repeated CVS merges knows what we're talking about).

  (There are some theoretical problems with remembering merge sources -- knowing where the merged data came from implies some sort of universal repository registry. However, our first goal is to make sure that multiple merges from branches made in the same repository as the original project compound gracefully. Remembering merges from remote sources is more difficult, due to the difficulty of distinguishing remote sources, but there are good "90%" solutions that will work in practice).

• Support for plug-in client side diff programs

  Subversion knows how to show diffs for text files, and also gives the user the option to plug in external diff programs for any kind of file. The external program need merely conform to some simple invocation interface (i.e., "diffprog file1 file2 [file3...]", where the various files might be different revisions of the same file).

• Natively client/server

  Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS.

• Client/server protocol sends diffs in both directions

  The network protocol uses bandwidth efficiently by transmitting diffs in both directions whenever possible (CVS sends diffs from server to client, but not client to server). The protocol will support compression too, of course.

• Costs are proportional to change size, not project size

  In general, the time required for an Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place. This is a property of the Subversion repository model.

• Internationalization

  Subversion will have I18N support -- commands, user messages, and errors can be customized to the appropriate human language at build-time. Also, there will be I18N support for the names as well as the contents of versioned entities.

  NOTE: Internationalization is planned, but may not be present in the first release.

• Progressive multi-lingual support

  In order to support keyword expansion and platform-dependent line-ending conversion, CVS makes a distinction between text and binary files, and treats the text files specially.

  Subversion will make the same distinction, but with a more generous notion of what constitutes a text file: not only ASCII, but UTF-* encodings of Unicode too. Not all such encodings will be handled as text in the first release of Subversion, but the support will become more complete over time. UTF-8 is the first priority.

  NOTE:Multi-Lingual support is planned, but may not be present in the first release.