# Architecture — How Subversion's components work together

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 .

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

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