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.
- Most current CVS features.
Subversion is meant to be a better CVS, so it has most of
CVS's features. 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 network server option, with WebDAV/DeltaV
protocol.
Subversion can use the HTTP-based WebDAV/DeltaV protocol for network
communications, and the Apache web server to provide
repository-side network service. This gives Subversion an
advantage over CVS in interoperability, and provides various key
features for free: authentication, path-based authorization, wire
compression, and basic repository browsing.
- Standalone server option.
Subversion also offers a standalone server option using a
custom protocol (not everyone wants to run Apache 2.x). The
standalone server can run as an inetd service, or in daemon mode,
and offers basic authentication and authorization. It can also be
tunnelled over ssh.
- 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. A 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 a 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.
- Choice of database or plain-file repository implementations
Repositories can be created with either an embedded database
back-end (BerkeleyDB) or with normal flat-file back-end, which
uses a custom format.
- Versioning of symbolic links
Unix users can place symbolic links under version control. The
links are recreated in Unix working copies, but not in win32
working copies.
- 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.
- Localized messages
Subversion uses gettext() to display translated error,
informational, and help messages, based on current locale
settings.
