Version Control with Subversion - Login

Repository Administrationbase—not a database that is constantly changing at the hand of some other process—andcan make decisions based on that view. If the decision made happens to conflict with whatanother process is doing, the entire operation is rolled back as though it never happened,and Subversion gracefully retries the operation against a new, updated (and yet still static)view of the database.Another great feature of Berkeley DB is hot backups—the ability to back up the databaseenvironment without taking it “offline.” We'll discuss how to back up your repository later inthis chapter (in the section called “Repository Backup”), but the benefits of being able tomake fully functional copies of your repositories without any downtime should be obvious.Berkeley DB is also a very reliable database system when properly used. Subversion usesBerkeley DB's logging facilities, which means that the database first writes to on-disk logfilesa description of any modifications it is about to make, and then makes the modificationitself. This is to ensure that if anything goes wrong, the database system can back up to aprevious checkpoint—a location in the logfiles known not to be corrupt—and replay transactionsuntil the data is restored to a usable state. See the section called “Managing DiskSpace” 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 Berkeley DB.First, Berkeley DB environments are not portable. You cannot simply copy a Subversionrepository that was created on a Unix system onto a Windows system and expect it towork. While much of the Berkeley DB database format is architecture-independent, otheraspects of the environment are not. Second, Subversion uses Berkeley DB in a way thatwill not operate on Windows 95/98 systems—if you need to house a BDB-backed repositoryon a Windows machine, stick with Windows 2000 or later.While Berkeley DB promises to behave correctly on network shares that meet a particularset of specifications, 5 most networked filesystem types and appliances do not actuallymeet those requirements. And in no case can you allow a BDB-backed repository thatresides on a network share to be accessed by multiple clients of that share at once (whichquite often is the whole point of having the repository live on a network share in the firstplace).If you attempt to use Berkeley DB on a noncompliant remote filesystem, theresults are unpredictable—you may see mysterious errors right away, or it maybe months before you discover that your repository database is subtly corrupted.You should strongly consider using the FSFS data store for repositoriesthat need to live on a network share.Finally, because Berkeley DB is a library linked directly into Subversion, it's more sensitiveto interruptions than a typical relational database system. Most SQL systems, for example,have a dedicated server process that mediates all access to tables. If a program accessingthe database crashes for some reason, the database daemon notices the lost connectionand cleans up any mess left behind. And because the database daemon is the only processaccessing the tables, applications don't need to worry about permission conflicts.These things are not the case with Berkeley DB, however. Subversion (and programs usingSubversion libraries) access the database tables directly, which means that a programcrash can leave the database in a temporarily inconsistent, inaccessible state. When thishappens, an administrator needs to ask Berkeley DB to restore to a checkpoint, which is abit of an annoyance. Other things can cause a repository to “wedge” besides crashed processes,such as programs conflicting over ownership and permissions on the databasefiles.Berkeley DB 4.4 brings (to Subversion 1.4 and later) the ability for Subversionto automatically and transparently recover Berkeley DB environments in need5 Berkeley DB requires that the underlying filesystem implement strict POSIX locking semantics, and more importantly,the ability to map files directly into process memory.127