The goal of the Subversion project is to build a revision 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.

Features planned for Subversion 1.0:

• Most current CVS features.

  Subversion is meant to be a better CVS, so it will have most of CVS's features, with as many as possible in the 1.0 release. The main exception is "svn blame" (i.e., "cvs annotate"), which has been put off until after 1.0 for scheduling reasons. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise.

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

  Lack of these features is one of the most common complaints against CVS. Subversion versions not only file contents and file existence, but also directories, copies, and renames. It also allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files.

• 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; log messages are attached to the revision, not stored redundantly as in CVS.

• Apache as network server, WebDAV/DeltaV for protocol (separate standalone server also available)

  Subversion uses the HTTP-based WebDAV/DeltaV protocol for network communications, and uses the Apache web server to provide repository-side network service. This gives Subversion a big advantage in stability and interoperability, and provides various key features for free: authentication, basic authorization, wire compression, and repository browsing, for example. For people who simply want to tunnel a custom protocol over ssh, Subversion also has a basic standalone server process.

• 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 are both implemented in terms of an underlying "copy" operation. An copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it's a branch as well. (This does away with CVS's "branch-point tagging", by removing the distinction that made branch-point tags necessary in the first place.)

• Natively client/server, layered library design

  Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS. The code is structured as a set of modules with well-defined interfaces, designed to be called by other applications.

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

• Costs are proportional to change size, not data 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.

• Efficient handling of binary files

  Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions.

• Parseable output

  All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high priority.

Features planned for after 1.0:

• Support for symbolic links

  Subversion will handle symbolic links ("shortcuts"). It may also support multiple hard links and other special file types, as long as this can be done portably and with semantics that are compatible with version control.

• "svn blame" (cvs annotate)

  Subversion will have a counterpart to CVS's "annotate" feature, but it will most likely happen after the 1.0 release, due to prioritization and scheduling.

• Graceful handling of repeated merges

  Subversion will use its generic metadata mechanism as 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).

• Broader WebDAV compatibility

  Currently, the Subversion server only responds to a subset of WebDAV requests -- the subset necessary to support Subversion's own functionality. Increased support for WebDAV is a high priority after the 1.0 release, however.

• Support for plug-in client side diff programs

  Subversion knows how to show diffs for text files, and later will also give 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).

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

• 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 makes the same distinction, but will offer a more generous notion of what constitutes a text file: not only ASCII, but UTF-* encodings of Unicode too. UTF-8 is the first priority, with other encodings following if needed.