Architecture
************

Subversion is conceptually divided into a number of separable layers.

Assuming that the programmatic interface of each layer is well-defined, it is easy to customize the different parts of the system.  Contributors can write new client apps, new network protocols, new server processes, new server features, and new storage back-ends.

The following diagram illustrates the "layered" architecture, and where each particular interface lies.

                         +--------------------+
                         | commandline or GUI |
                         |    client app      |
              +----------+--------------------+----------+ <=== Client interface
              |              Client Library              |
              |                                          |
              |        +----+                            |
              |        |    |                            |
      +-------+--------+    +--------------+--+----------+ <=== Network interface
      | Working Copy   |    |    Remote    |  | Local    |
      | Management lib |    | Repos Access |  | Repos    |
      +----------------+    +--------------+  | Access   |
                            |     neon     |  |          |
                            +--------------+  |          |
                               ^              |          |
                              /               |          |
                        DAV  /                |          |
                            /                 |          |
                           v                  |          |
                   +---------+                |          |
                   |         |                |          |
                   | Apache  |                |          |
                   |         |                |          |
                   +---------+                |          |
                   | mod_DAV |                |          |
                 +-------------+              |          |
                 | mod_DAV_SVN |              |          |
      +----------+-------------+--------------+----------+ <=== Filesystem interface
      |                                                  |
      |               Subversion Filesystem              |
      |                                                  |
      +--------------------------------------------------+

Client Layer
============

The Subversion client, which may be either command-line or GUI, draws on three libraries.

The working copy library, libsvn_wc, provides an API for managing the client's working copy of a project.  This includes operations like renaming or removal of files, patching files, extracting local diffs, and routines for maintaining administrative files in the .svn/ directory.

The repository_access library, libsvn_ra, provides an API for exchanging information with a Subversion repository.  This includes the ability to read files, write new revisions of files, and ask the repository to compare a working copy against its latest revision. Note that there are two implementations of this interface: one designed to talk to a repository over a network, and one designed to work with a repository on local disk.  Any number of interface implementations can exist.

The client library, libsvn_client provides general client functions such as update() and commit(), which may involve one or both of the other two client libraries. libsvn_client should, in theory, provide an API that allows anyone to write a Subversion client application.

For details, see Client.

Network Layer
=============

The network layer's job is to move the repository API requests over a wire.

On the client side, a network library (libneon) translates these requests into a set of HTTP WebDAV/DeltaV requests.  The information is sent over TCP/IP to an Apache server.  Apache is used for the following reasons:

  * it is time-tested and extremely stable;

  * it has built-in load-balancing;

  * it has built-in proxy and firewall support;

  * it has authentication and encryption features;

  * it allows client-side caching;

  * it has an extensible module system

Our rationale is that any attempt to write a dedicated "Subversion server" (with a "Subversion protocol") would inevitably end up evolving towards Apache's already-existing feature set.  (However, Subversion's layered architecture certainly doesn't prevent anyone from writing a totally new network access implementation.)

An Apache module (mod_dav_svn) translates the DAV requests into API calls against a particular repository.

For details, see Protocol.

Filesystem Layer
================

When the requests reach a particular repository, they are interpreted by the Subversion Filesystem library, libsvn_fs.  The Subversion Filesystem is a custom Unix-like filesystem, with a twist: writes are revisioned and atomic, and no data is ever deleted!  This filesystem is currently implemented on top of a normal filesystem, using Berkeley DB files.

For a more detailed explanation: see Server.