Version Control with Subversion - Login

Repository Administrationof such recovery. When a Subversion process attaches to a repository'sBerkeley DB environment, it uses some process accounting mechanisms todetect any unclean disconnections by previous processes, performs any necessaryrecovery, and then continues on as though nothing happened. Thisdoesn't completely eliminate instances of repository wedging, but it doesdrastically reduce the amount of human interaction required to recover fromthem.So while a Berkeley DB repository is quite fast and scalable, it's best used by a single serverprocess running as one user—such as Apache's httpd or svnserve (see Chapter 6,Server Configuration)—rather than accessing it as many different users via file:// orsvn+ssh:// URLs. If you're accessing a Berkeley DB repository directly as multipleusers, be sure to read the section called “Supporting Multiple Repository Access Methods”later in this chapter.FSFSIn mid-2004, a second type of repository storage system—one that doesn't use a databaseat all—came into being. An FSFS repository stores the changes associated with a revisionin a single file, and so all of a repository's revisions can be found in a single subdirectoryfull of numbered files. Transactions are created in separate subdirectories as individualfiles. When complete, the transaction file is renamed and moved into the revisions directory,thus guaranteeing that commits are atomic. And because a revision file is permanentand unchanging, the repository also can be backed up while “hot,” just like a BDB-backedrepository.The FSFS revision files describe a revision's directory structure, file contents, and deltasagainst files in other revision trees. Unlike a Berkeley DB database, this storage format isportable across different operating systems and isn't sensitive to CPU architecture. Becauseno journaling or shared-memory files are being used, the repository can be safelyaccessed over a network filesystem and examined in a read-only environment. The lack ofdatabase overhead also means the overall repository size is a bit smaller.FSFS has different performance characteristics, too. When committing a directory with ahuge number of files, FSFS is able to more quickly append directory entries. On the otherhand, FSFS writes the latest version of a file as a delta against an earlier version, whichmeans that checking out the latest tree is a bit slower than fetching the full-texts stored in aBerkeley DB HEAD revision. FSFS also has a longer delay when finalizing a commit, whichcould in extreme cases cause clients to time out while waiting for a response.The most important distinction, however, is FSFS's imperviousness to wedging whensomething goes wrong. If a process using a Berkeley DB database runs into a permissionsproblem or suddenly crashes, the database can be left in an unusable state until an administratorrecovers it. If the same scenarios happen to a process using an FSFS repository,the repository isn't affected at all. At worst, some transaction data is left behind.The only real argument against FSFS is its relative immaturity compared to Berkeley DB.Unlike Berkeley DB, which has years of history, its own dedicated development team, and,now, Oracle's mighty name attached to it, 6 FSFS is a newer bit of engineering. Prior toSubversion 1.4, it was still shaking out some pretty serious data integrity bugs, which, whiletriggered in only very rare cases, nonetheless did occur. That said, FSFS has quickly becomethe backend of choice for some of the largest public and private Subversion repositories,and it promises a lower barrier to entry for Subversion across the board.Creating and Configuring Your Repository6 Oracle bought Sleepycat and its flagship software, Berkeley DB, on Valentine's Day in 2006.128