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