Version Control with Subversion - Login

Repository AdministrationIn short, transaction cleanup decisions need not be made unwisely. Various sources of information—includingApache's error and access logs, Subversion's operational logs, Subversionrevision history, and so on—can be employed in the decision-making process. Andof course, an administrator can often simply communicate with a seemingly dead transaction'sowner (via email, e.g.) to verify that the transaction is, in fact, in a zombie state.Purging unused Berkeley DB logfilesUntil recently, the largest offender of disk space usage with respect to BDB-backed Subversionrepositories were the logfiles in which Berkeley DB performs its prewrites beforemodifying the actual database files. These files capture all the actions taken along theroute of changing the database from one state to another—while the database files, at anygiven time, reflect a particular state, the logfiles contain all of the many changes along theway between states. Thus, they can grow and accumulate quite rapidly.Fortunately, beginning with the 4.2 release of Berkeley DB, the database environment hasthe ability to remove its own unused logfiles automatically. Any repositories created usingsvnadmin when compiled against Berkeley DB version 4.2 or later will be configured forthis automatic logfile removal. If you don't want this feature enabled, simply pass the --bdb-log-keep option to the svnadmin create command. If you forget to do this orchange your mind at a later time, simply edit the DB_CONFIG file found in your repository'sdb directory, comment out the line that contains the set_flags DB_LOG_AUTOREMOVEdirective, and then run svnadmin recover on your repository to force the configurationchanges to take effect. See the section called “Berkeley DB Configuration” for more informationabout database configuration.Without some sort of automatic logfile removal in place, logfiles will accumulate as you useyour repository. This is actually somewhat of a feature of the database system—youshould be able to recreate your entire database using nothing but the logfiles, so these filescan be useful for catastrophic database recovery. But typically, you'll want to archive thelogfiles that are no longer in use by Berkeley DB, and then remove them from disk to conservespace. Use the svnadmin list-unused-dblogs command to list the unused logfiles:$ svnadmin list-unused-dblogs /var/svn/repos/var/svn/repos/log.0000000031/var/svn/repos/log.0000000032/var/svn/repos/log.0000000033…$ rm `svnadmin list-unused-dblogs /var/svn/repos`## disk space reclaimed!Berkeley DB RecoveryBDB-backed repositories whose logfiles are used as part of a backup or disasterrecovery plan should not make use of the logfile autoremoval feature.Reconstruction of a repository's data from logfiles can only be accomplishedonly when all the logfiles are available. If some of the logfiles are removedfrom disk before the backup system has a chance to copy them elsewhere, theincomplete set of backed-up logfiles is essentially useless.As mentioned in the section called “Berkeley DB”, a Berkeley DB repository can sometimesbe left in a frozen state if not closed properly. When this happens, an administrator needsto rewind the database back into a consistent state. This is unique to BDB-backed repositories,though—if you are using FSFS-backed ones instead, this won't apply to you. And forthose of you using Subversion 1.4 with Berkeley DB 4.4 or later, you should find that Subversionhas become much more resilient in these types of situations. Still, wedged BerkeleyDB repositories do occur, and an administrator needs to know how to safely deal withthis circumstance.138