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/ dav/ 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.)
A directory containing configuration files
A directory ...