[VCS - 2] Apache SVN - High Level Architecture
SVN 3 Tier Architecture overview
Overview
In the last post, we covered the basic architecture tenets behind VCS systems and briefly talked about Apache SVN. We covered a high level overview of the collaboration model of Apache SVN and described concepts like working copies, repositories etc. Based on this information, you should already have an idea about how to interact with Apache SVN and use it as your VCS tool. In this post, the focus would be more on how SVN is architected by looking at the high level moving parts of SVN architecture
Architecture Components
SVN has a 3-tier architecture consisting of three layers that interact with each other to provide the full suite of SVN functionalities. These layers have defined specifications and SVN offers out of the box implementations for them while leaving room for users to provide their own implementation if it suits their need. The three layers are
Client Layer: Deals with the client side functionalities like providing functionality to checkout SVN repository, pull diffs, apply patches, commit changes etc.
Network Layer: Deals with the transmission of client side commands to the SVN Repository. This layer also handles the receiving of the request on the server and routing it to the appropriate server module.
Server Layer: This is the layer that persists the central copy of the repository and exposes functionalities to interact with this central copy like committing changes, fetching revisions of files etc.
These layers serve both individual purposes as well as interacting with each other to handle complex operations. When working together, these layers provide a chain of delegation with each layer interpreting user requests and passing it to the next layer for further handling
The next few sections explore these layers in a little more detail.
Client
The SVN client offers the capabilities to do client side operations on user machines. These operations include checking out a working copy, pulling latest changes and applying them to the working copy, committing changes, viewing diffs from a different revision etc. The client layer broadly depends on three libraries internally
Working Copy Library
This library offers functionalities over the working copy only. It never interacts with the remote repository. In SVN, when you checkout a working copy, each directory in the working copy gets a
.svndirectory inside it. This directory contains the original copy of the files in the containing directory along with other meta information that helps SVN in tracking what has changed in a directory. The.svndirectory is present in all directories in the working copy, not only the root directory.
SVN Working Copy showing `.svn` folders in each sub folder Every directory in a working copy has a
.svndirectory to manage the changes to that directoryThe working copy library allows you to
modify the contents of the
.svndirectorymodify the contents of the files in the working copy, e.g. applying merges from repository etc.
Repository Access Library
This library is responsible for interacting with the remote repository. It never interacts with the working copy directly. This library internally delegates the job of calling the repository to the network layer. Since this library can interact with the remote repository, it is responsible for pushing commits, pulling changes from repository etc.
Client Ops Library
This library uses the working copy library and the repository access library to provide the full set of SVN command line operations that users generally use.
Network
The network layer interacts with both the client layer on the client side and the server layer on the server side. It is responsible for taking client requests, sending them over the network to the server and parsing and routing the request to the correct handler on the server side. As such, we can talk about the network layer from two different lenses.
The client side view
On the client side, the network layer offers libraries that can convert requests to the appropriate network protocol and send them to a subversion server. The network layer also receives the responses from the server and converts them to runtime code representation that is then used by the client layer.
The server side view
On the server side, the network layer receives the request from the client, parses it into an appropriate runtime representation and finally translates it into a call to the appropriate server method.
Server
The server in case of SVN is not a network layer server as you would commonly expect. It is just a set of libraries that expose the functionalities that can be invoked by clients. These functionalities are invoked by the network layer itself which is running on the same machine so no networking is involved at this point.
The server internally consists of two broad components
Filesystem
This layer is the heart of SVN. It offers a fully functional filesystem with added versioning capabilities. It uses certain data models (which we will explore in the next post) to store the raw files in a way that any past versions can be retrieved on demand. It also offers functionalities like concurrency handling and user access management
The filesystem layer uses Berkeley DB or FSFS to store data model objects. Which one is used is dependent upon the configuration of your SVN repository. Since they both offer different performance characteristics, you should refer to SVN docs to understand which one to use in your case.Repository
Repository is a wrapper over the filesystem library mentioned above. It offers additional capabilities like exposing common filesystem operations as VCS functionalities. e.g. committing files, creating branches and tags etc.
Repositories also offer other maintenance procedures as well as hooks that can be configured to be run depending on common repository operations.
What next?
This short post offered an overview of the SVN Architecture at a high level. The next post will be the last in the SVN series for now and will offer a deep dive into the internals of the filesystem library of the server layer. This will focus on an overview of the data model used by SVN to store the actual directory tree and the different revisions of the same!