Apache Subversion (often abbreviated SVN, after its command name svn) is a version control system. The software is distributed as open source software, under the Apache License. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Subversion is generally used to aid in the software lifecycle process, including code commits, binary releases, fault reporting and retraction, patch releases, and developer updates (including documentation). Subversion is an important tool in software development lifecycle tasks such as software versioning. It provides an easy command line or application-based way to commit, branch, revert, and release all sorts of files (not only source code), though it is most used by the software development community. Unlike Git, which it predates, SVN repositories are more often maintained on privately maintained servers. Subversion's goal is to be a mostly compatible successor to the previously more widely used Concurrent Versions System (CVS).

The open source community has used Subversion widely: for example, in projects such as Apache Software Foundation, FreeBSD, SourceForge, and from 2006 to 2019, GCC. CodePlex was previously a common host for Subversion repositories.

Subversion was created by CollabNet Inc., and first released in 2000. Subversion was a top-level Apache project being built and used by a global community of developers and contributors.

History

CollabNet founded the Subversion project in 2000 as an effort to write an open-source version-control system which operated much like CVS but which fixed the bugs and supplied some features missing in CVS. By 2001, Subversion had advanced sufficiently to host its own source code, and in February 2004, version 1.0 was released. In November 2009, Subversion was accepted into Apache Incubator: this marked the beginning of the process to become a standard top-level Apache project. It became a top-level Apache project on February 17, 2010.

Version Original release date Latest version Latest release date Status 2004-02-23 1.0.9 2004-10-13 No longer supported 2004-09-29 1.1.4 2005-04-01 No longer supported 2005-05-21 1.2.3 2005-08-19 No longer supported 2005-12-30 1.3.2 2006-05-23 No longer supported 2006-09-10 1.4.6 2007-12-21 No longer supported 2008-06-19 1.5.9 2010-12-06 No longer supported 2009-03-20 1.6.23 2013-05-30 No longer supported 2011-10-11 1.7.22 2015-08-12 No longer supported 2013-06-18 1.8.19 2017-08-10 No longer supported 2015-08-05 1.9.12 2019-07-24 No longer supported 2018-04-13 1.10.8 2022-04-12 No longer supported 2018-10-30 1.11.1 2019-01-11 No longer supported 2019-04-24 1.12.2 2019-07-24 No longer supported 2019-10-30 1.13.0 2019-10-30 No longer supported2020-05-271.14.52024-12-08Fully supported1.15.0-rc42026-09-11In development

Release dates are extracted from Apache Subversion's file, which records all release history.

Features Commits as true atomic operations (interrupted commit operations in CVS would cause repository inconsistency or corruption). The system maintains versioning for directories and some specific file metadata (see Properties). Users can move or copy files and entire directory-trees very quickly, while retaining full revision history (as being implemented by a reference to the original object). Versioning of symbolic links. Native support for binary files, with space-efficient binary-diff storage. Apache HTTP Server as network server, WebDAV/Delta-V for protocol. There is also an independent server process called svnserve that uses a custom protocol over TCP/IP. Branching is implemented by a copy of a directory, thus it is a cheap operation, independent of file size. Natively client–server, layered library design. Client/server protocol sends diffs in both directions. Parsable output, including XML log output. Open source licensed – Apache License since the 1.7 release; prior versions use a derivative of the Apache Software License 1.1. Internationalized program messages. File locking for unmergeable files ("reserved checkouts"). Path-based authorization. Language bindings for C#, PHP, Python, Perl, Ruby, and Java. Full MIME support – users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown. Merge tracking – merges between branches will be tracked, this allows automatic merging between branches without telling Subversion what does and does not need to be merged. Changelists to organize commits into commit groups.

Repository types Subversion offers two types of repository storage.

Berkeley DB (deprecated) The original development of Subversion used the Berkeley DB package. Subversion has some limitations with Berkeley DB usage when a program that accesses the database crashes or terminates forcibly. No data loss or corruption occurs, but the repository remains offline while Berkeley DB replays the journal and cleans up any outstanding locks. The safest way to use Subversion with a Berkeley DB repository involves a single server-process running as one user (instead of through a shared filesystem). The Berkeley DB backend was deprecated in version 1.8.

FSFS

In 2004, a new storage subsystem was developed and named FSFS. It works faster than the Berkeley DB backend on directories with a large number of files and takes less disk space, due to less logging.

Beginning with Subversion 1.2, FSFS became the default data store for new repositories.

The etymology of "FSFS" is based on Subversion's use of the term "filesystem" for its repository storage system. FSFS stores its contents directly within the operating system's filesystem, rather than a structured system like Berkeley DB. Thus, it is a "[Subversion] FileSystem atop the FileSystem".

FSX A new filesystem, called FSX, is under development to remove some limitations of FSFS. It was added in version 1.9 and not considered production-ready. As of version 1.14, it is still marked as experimental.

Repository access Access to Subversion repositories can take place by:

Local filesystem or network filesystem,Berkeley DB relies on file locking and thus should not be used on (network) filesystems which do not implement them accessed by client directly. This mode uses the access scheme. WebDAV/Delta-V (over http or https) using the module for Apache 2. This mode uses the access scheme or for secure connections using ssl. Custom "svn" protocol (default port 3690), using plain text or over TCP/IP. This mode uses either the access scheme for unencrypted transport or scheme for tunneling over ssh.

All three means can access both FSFS and Berkeley DB repositories.

Any 1.x version of a client can work with any 1.x server. Newer clients and servers have additional features and performance capabilities, but have fallback support for older clients/servers.SVN 1.5 release notes

Layers Internally, a Subversion system comprises several libraries arranged as layers. Each performs a specific task and allows developers to create their own tools at the desired level of complexity and specificity.

Fs The lowest level; it implements the versioned filesystem which stores the user data. Repos Concerned with the repository built up around the filesystem. It has many helper functions and handles the various "hooks" that a repository may have, e.g., scripts that run when an action is performed. Together, Fs and Repos constitute the "filesystem interface". mod_dav_svn Provides WebDAV/Delta-V access through Apache 2. Ra Handles "repository access", both local and remote. From this point on, repositories are referred to using URLs, e.g. for local access, or for WebDAV access, or or for the SVN protocol. Client, Wc The highest level. It abstracts repository access and provides common client tasks, such as authenticating users or comparing versions. Subversion clients use the Wc library to manage the local working copy.

Filesystem

One can view the Subversion filesystem as "two-dimensional".Basic Merging Two coordinates are used to unambiguously address filesystem items: Path (regular path of Unix-like OS filesystem) Revision Each revision in a Subversion filesystem has its own root, which is used to access contents at that revision. Files are stored as links to the most recent change; thus a Subversion repository is quite compact. The system consumes storage space proportional to the number of changes made, not to the number of revisions.

The Subversion filesystem uses transactions to keep changes atomic. A transaction operates on a specified revision of the filesystem, not necessarily the latest. The transaction has its own root, on which changes are made. It is then either committed and becomes the latest revision, or is aborted. The transaction is actually a long-lived filesystem object; a client does not need to commit or abort a transaction itself, rather it can also begin a transaction, exit, and then can re-open the transaction and continue using it. Potentially, multiple clients can access the same transaction and work together on an atomic change, though no existing clients expose this capability.

Properties One important feature of the Subversion filesystem is properties: simple name=value pairs of text. Most properties occur on filesystem entries (i.e., files and directories). These are versioned just like other changes to the filesystem. The Subversion client reserves the 'svn:' prefix for built-in properties, but other names can be used to define custom properties.

Makes a file on Unix-hosted working copies executable, when supported by the filesystem. Stores the Internet media type ("MIME type") of a file. Affects the handling of diffs and merging. A list of filename patterns to ignore in a directory. Similar to CVS's .cvsignore file. A list of keywords to substitute into a file when changes are made. The file itself must also reference the keywords as or . This is used to maintain certain information (e.g., author, date of last change, revision number) in a file without human intervention.The keyword substitution mechanism originates from RCS and from CVS. Makes the client convert end-of-line characters in text files. Used when the working copy is needed with a specific EOL style. "native" is commonly used, so that EOLs match the user's OS EOL style. Repositories may require this property on all files to prevent inconsistent line endings, which can cause a problem in itself. Allows parts of other repositories to be automatically checked out into a subdirectory. Specifies that a file is to be checked out with file permissions set to read-only. This is designed for use with the locking mechanism. The read-only permission reminds one to obtain a lock before modifying the file: obtaining a lock makes the file writable, and releasing the lock makes it read-only again. Locks are only enforced during a commit operation. Locks can be used without setting this property. However, that is not recommended, because it introduces the risk of someone modifying a locked file; they will only discover it has been locked when their commit fails. This property is not meant to be set or modified directly by users. it is only used for having symbolic links in the repository. When a symbolic link is added to the repository, a file containing the link target is created with this property set. When a Unix-like system checks out this file, the client converts it to a symbolic link. Used to track merge data (revision numbers) in Subversion 1.5 (or later). This property is automatically maintained by the command, and it is not recommended to change its value manually.Subversion Properties