This text is a work in progress—highly subject to change—and may not accurately describe any released version of the ApacheTM Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.
Before jumping into the broader topic of repository administration, let's further define what a repository is. How does it look? How does it feel? Does it take its tea hot or iced, sweetened, and with lemon? As an administrator, you'll be expected to understand the composition of a repository both from a literal, OS-level perspective—how a repository looks and acts with respect to non-Subversion tools—and from a logical perspective—dealing with how data is represented inside the repository.
Seen through the eyes of a typical file browser application (such as Windows Explorer) or command-line based filesystem navigation tools, the Subversion repository is just another directory full of stuff. There are some subdirectories with human-readable configuration files in them, some subdirectories with some not-so-human-readable data files, and so on. As in other areas of the Subversion design, modularity is given high regard, and hierarchical organization is preferred to cluttered chaos. So a shallow glance into a typical repository from a nuts-and-bolts perspective is sufficient to reveal the basic components of the repository:
$ ls repos conf/ db/ format hooks/ locks/ README.txt
Here's a quick fly-by overview of what exactly you're seeing in this directory listing. (Don't get bogged down in the terminology—detailed coverage of these components exists elsewhere in this and other chapters.)
This directory is a container for configuration files.
This directory contains the data store for all of your versioned data.[49]
This file describes the repository's internal
organizational scheme. (As it turns out,
the db/ subdirectory sometimes also
contains a format file which
describes only the contents of that subdirectory and which
is not to be confused with this file.)
This directory contains hook script templates and hook scripts, if any have been installed.
Subversion uses this directory to house repository lock files, used for managing concurrent access to the repository.
This is a brief text file containing merely a notice to readers that the directory they are looking in is a Subversion repository.
| [Note] | Note |
|---|---|
|
Prior to Subversion 1.5, the on-disk repository
structure also always contained a |
Of course, when accessed via the Subversion libraries, this otherwise unremarkable collection of files and directories suddenly becomes an implementation of a virtual, versioned filesystem, complete with customizable event triggers. This filesystem has its own notions of directories and files, very similar to the notions of such things held by real filesystems (such as NTFS, FAT32, ext3, etc.). But this is a special filesystem—it hangs these directories and files from revisions, keeping all the changes you've ever made to them safely stored and forever accessible. This is where the entirety of your versioned data lives.
Speaking of Filesystems...
When the initial design phase of Subversion was in progress, the developers decided to use Berkeley DB (BDB) as the storage mechanism behind the virtual versioned filesystem implementation. Berkeley DB was a logical choice for a variety of reasons, including its open source license, transaction support, reliability, performance, API simplicity, thread safety, support for cursors, and so on.
In the years since, the newer FSFS[50] backend was introduced. This so-called "filesystem filesystem" was a versioned filesystem implemented not within an opaque database container, but instead as a larger collection of more transparent files stored in the OS's filesystem. FSFS enjoyed continual development and improvement, and eventually earned the right to be the default Subversion backend. But improvements to that backend kept coming, and ultimately the FSFS storage layer surpassed the Berkeley DB one in nearly every meaningful metric, from performance to scalability to reliability and beyond.
These days, it is generally assumed that if you are using the open source Subversion product, you are using the FSFS backend for your repositories. In fact, beginning with Subversion 1.8, the Berkeley DB Subversion repository filesystem backend has been officially deprecated. Subversion repositories which still use this storage layer option will continue to function with newer Subversion 1.x releases, but no further development—including feature introduction or expansion—is planned for the Berkeley DB backend. Subversion effectively offers a single viable repository storage layer option. FSFS won.
This book will continue to provide information relevant to administrators of BDB-backed repositories where it makes sense to do so, but most of this chapter will assume what the rest of the world does: that FSFS is the Subversion storage backend implementation. Please refer to Appendix D, The Berkeley DB Legacy Filesystem or to older versions of this documentation for more complete information about administering such repositories.
[49] Strictly speaking, Subversion doesn't dictate that the versioned data live here, and there are known (albeit proprietary) alternative backend storage implementations which do not, in fact, store data in this directory.
[50] While it is often pronounced "fuzz-fuzz," per Jack Repenning's rendition, this book assumes that the reader is thinking "eff-ess-eff-ess."