Version Control with Subversion

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

76

|

Chapter 5: Repository Administration

tion itself. This is to ensure that if anything goes wrong, the database system can

back up to a previous checkpoint—a location in the logfiles known not to be cor-

rupt—and replay transactions until the data is restored to a usable state. See “Man-

aging Disk Space” later in this chapter for more about Berkeley DB logfiles.

But every rose has its thorn, and so we must note some known limitations of Berke-

ley DB. First, Berkeley DB environments are not portable. You cannot simply copy a

Subversion repository that was created on a Unix system onto a Windows system

and expect it to work. While much of the Berkeley DB database format is architec-

ture independent, there are other aspects of the environment that are not. Secondly,

Subversion uses Berkeley DB in a way that will not operate on Windows 95/98 sys-

tems—if you need to house a repository on a Windows machine, stick with Win-

dows 2000 or Windows XP. Finally, you should never keep a Subversion repository

on a network share. While Berkeley DB promises to behave correctly on network

shares that meet a particular set of specifications, almost no known shares actually

meet all those specifications.

Repository Creation and Configuration

Creating a Subversion repository is an incredibly simple