Version Control with Subversion - Login

Repository Administrationwhere the thing is going to live. This is strongly connected to myriad other questions involvinghow the repository will be accessed (via a Subversion server or directly), by whom(users behind your corporate firewall or the whole world out on the open Internet), whatother services you'll be providing around Subversion (repository browsing interfaces, emailbasedcommit notification, etc.), your data backup strategy, and so on.We cover server choice and configuration in Chapter 6, Server Configuration, but the pointwe'd like to briefly make here is simply that the answers to some of these other questionsmight have implications that force your hand when deciding where your repository will live.For example, certain deployment scenarios might require accessing the repository via a remotefilesystem from multiple computers, in which case (as you'll read in the next section)your choice of a repository backend data store turns out not to be a choice at all becauseonly one of the available backends will work in this scenario.Addressing each possible way to deploy Subversion is both impossible and outside thescope of this book. We simply encourage you to evaluate your options using these pagesand other sources as your reference material and to plan ahead.Choosing a Data StoreAs of version 1.1, Subversion provides two options for the type of underlying datastore—often referred to as “the backend” or, somewhat confusingly, “the (versioned)filesystem”—that each repository uses. One type of data store keeps everything in aBerkeley DB (or BDB) database environment; repositories that use this type are often referredto as being “BDB-backed.” The other type stores data in ordinary flat files, using acustom format. Subversion developers have adopted the habit of referring to this latter datastorage mechanism as FSFS 4 —a versioned filesystem implementation that uses the nativeOS filesystem directly—rather than via a database library or some other abstraction layer—tostore data.Table 5.1, “Repository data store comparison” gives a comparative overview of BerkeleyDB and FSFS repositories.Table 5.1. Repository data store comparisonCategory Feature Berkeley DB FSFSReliability Data integrity When properly deployed,extremely reliable;Berkeley DB4.4 brings autorecoverySensitivity to interruptionsOlder versions hadsome rarely demonstrated,but datadestroyingbugsVery; crashes and Quite insensitivepermission problemscan leave the database“wedged,” requiringjournaled recoveryprocedures4 Often pronounced “fuzz-fuzz,” if Jack Repenning has anything to say about it. (This book, however, assumes thatthe reader is thinking “eff-ess-eff-ess.”)125